Re: [Ethereal-dev] Managing updates from /trunk to /trunk-1.0

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

On Tue, 2 May 2006, Gerald Combs wrote:

> We're currently tracking updates from the development to the 1.0 trunk
> using my inbox, which is probably the worst way to do this.  I've added
> a list of checkins that need to be copied over to the Roadmap page on
> the wiki (http://wiki.ethereal.com/Development/Roadmap).  If you'd like
> to nominate code to be copied to the 1.0 trunk, please add an entry there.
>
> BTW, should we manage this in the bug database instead?  It might
> provide a better historical record.

Hi,

We're facing a new situation here. Up till now we've all been happy coding
away on a single development line, of which Gerald occasionally took a
branch which, with some 'private' additions, became the next release. This
branch then became frozen, no further work was done on it and any problems
found on that release were solved in the development line, which happily
continued. The automatic builds of the development line gave the option of
'releasing' fixes, although all other development changes were
incorporated as well.

Then came the 1.0 branch. Unlike the previous branches, which would
lead to a single release and then become frozen, this branch is very much
alive. It serves as baseline for a number of releases (0.99.0, 0.99.1,
0.99.2 through 1.0.0 to 1.0.1, 1.0.2 etc.). In essence this branch mimics
the development line in that every release (0.99.0 etc.) is made off of it
while bug fixes and other changes accumulate in the branch. In the mean
time development continues in the development line, both lines diverge.

Now, shouldn't we treat the 1.0 branch as a live branch, as we do with the
developement line? That means automatic quality checks (buildbot),
buildbot releases, and checkins by people other than Gerald? For that to
work we have to recognize the different status the 1.0 branch has to have.
We must realize that this is the path to a final product, not our
'playground' as the development line is. We must ask ourselves do we trust
ourselves to keep the 1.0 branch clean?

As Gerald notes above, email isn't a collaboration tool (see also
http://it.slashdot.org/article.pl?sid=06/05/02/1322240) so we shouldn't
rely on that. Also Gerald (like Linus) doesn't scale. We can produce more
patches for the 1.0 branch than he can be expected to consume (patch
manangement is not his dayjob as I understand it). Filing a bug report on
it could be a way to keep track of patches which should go from
development line to 1.0 branch, even though working and testing on the 1.0
branch would be better.

Just my $0.02,
Jaap