Merging to the release_1_6 branch

[Rainer Müller]

Jordan K. Hubbard wrote:
> That's either truly one-dimensional thinking at work or you are now  
> merely working overtime try and invent reasons to branch. :-)

No, I still try to understand how your proposal should be useful.

> Who says that the only way to fix bugs is to branch?  You might just  
> as well decide to create 3 tags in a row on trunk, during a code  
> slush, or even declare it a release and fix the bugs in the next  
> release (which, hopefully, would also happen MORE OFTEN than they do  
> now because there would be less work involved).  That is what  
> "convergence" means.  You fix the bugs in trunk until things are  
> "release ready" and then you release it.  If you want to create  
> "release candidate" tags, then fine, create them on trunk also.

If you don't branch, you need a code freeze to avoid other changes 
happen on trunk which you don't want to have in your release. So, again 
you need a release engineer to announce code freezes.

Code freezes make your development slower as you can't implement new 
stuff as it flows to your mind. While the code is freezed you would have 
to branch in order to work on something which is not suited for the 
release for which the code is freezed. In my opinion it is easier to 
branch a release than do this on-deman branching. Which also means 
people have to watch where they make their changes etc.

You can disagree on me again, but I simply don't see how code freezes 
should be useful for this project.

> It may seem like a minor point of order we're arguing to everyone else  
> who is undoubtedly bored sick by the topic by now, but one process is  
> a lot more light-weight than the other and minimizes confusion (like  
> features being on the 1.6 branch that someone forgot to merge to  
> trunk, as was just noticed) since the default scenario is always to be  
> on one linear path, with branches being the specialized exception  
> rather than the constant-expense rule.  But hey, maybe Rainer here  
> wants to volunteer to be release engineer for the next 5 years or so  
> (it takes at least 2 years to figure out how to do everything right,  
> so it's a long-term commitment) and win the argument by default since  
> if he's signing up to do all the extra merge work, I will stop arguing  
> and get out of his way immediately. :-)

I am primal interested in getting 1.6.1 out of the door eventually. It 
should have already have happened to address the postflight bug which 
was fixed only weeks after the release. Now we are in months after the 
release, nearly half a year. As our port managers do not seem to push 
the release, so I am asking what we can do to make this release process 
faster.

For example, we could nominate revisions for backport to 1.6.x, so 
nobody has to look through hundreds of revisions (see the output of 
'svnmerge.py avail' in branches/release_1_6/base). This was just a 
suggestion. If finally nobody objects or says anything different on this 
topic I will just start to merge revisions to the release_1_6 which I 
think should be included in 1.6.1 (especially the stuff from the tickets 
in the 1.6.1 milestone which was already committed to trunk).

And I didn't want to start a discussion about how and if creating 
release branches for MacPorts is useful, this was introduced by you.

Rainer