Merging to the release_1_6 branch (was: Re: Fwd:

Jordan K. Hubbard jkh at
Tue May 27 10:52:08 PDT 2008

This is why I think that releases should be tags on trunk, with a  
convergence period before each release.  This project is not big  
enough and does not have the manpower or written guidelines and a  
release engineer driving the process on a daily basis which are  
necessary to really do a two-branch model.  That is merely my opinion,  
of course, but it's driven by some experience in this area.

- Jordan

On May 27, 2008, at 4:29 AM, Rainer Müller wrote:

> Randall Wood wrote:
>> SO when are we planning on getting a macports (1.6.1, 1.7.0) out that
>> addresses this issue?
> There were a lot of changes to trunk. But not all of them are suited  
> for
> inclusion in a 1.6.1 release.
> To make a 1.6.1 release a lot of revisions still need to get merged to
> the release_1_6 branch, but currently we don't have any guidelines who
> should do the merge. See the 1.6.1 milestone, all tickets are still  
> open
> because nothing was merged to release_1_6 yet. This makes it difficult
> to track the progress for this release.
> Should the base developers just merge back what should be included in
> 1.6.1 judged by themselves? Or should we put up some system for
> nominating revisions for merging and let the release manager do it?
> There is no mention how the merging should be done in our  
> ReleaseProcess
> documentation at [1]. I think the approach until now was to review the
> svn log of trunk and merge back what is needed, but this is a long  
> list.
> The ChangeLog can be a good hint, but not all revisions which need to
> get merged might be noted down there. So I am in favor of nominating
> revisions by everyone and merging by one person (or a small group)
> coordinating the release.
> As I said before, some features have already been merged to  
> release_1_6,
> see [2] for reference.
> Rainer
> [1]
> [2]
> _______________________________________________
> macports-dev mailing list
> macports-dev at

More information about the macports-dev mailing list