[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc release branch procedures



On Wed, Jun 03, 2009 at 08:18:30PM -0700, Roland McGrath wrote:
> I hereby solicit somebody to make sure the results of these discussions
> get wikiized.  Don't all fall over yourselves rushing to volunteer.

I can do it after it becomes clear whatever we reached is the final
consensus for now.

> I propose these as recommended guidelines for all release branch managers:
> 
> 1. Don't talk about recommended guidelines for all release branch managers.
>    No, wait, do talk about them.  
>    Don't suspect your neighbor.  Discuss him on libc-alpha.
> 2. Remember GNU copyright discipline, even for private branches.
> 3. Use git branch "release/x.y/master" as "the usual place to look"
>    (whatever that means in your process).  The x.y release manager
>    should choose and specify conventions for "release/x.y/*" branches.
> 4. When a commit backports a change from the trunk (or another proper
>    release branch), use "git cherry-pick -x" or otherwise clearly indicate
>    the original commit id in the backport commit's log entry, and
>    always aim for one separate backport commit per corresponding trunk commit.
> 5. When a commit is not a backport of a clearly identifiable single
>    commit from the trunk or another release branch, then there should
>    be some voluminous controversy or communal agonized consternation
>    on the mailing lists about whatever it is.  i.e., this should always
>    be an automatic red flag for a release manager and all participants,
>    so that it merits explicit discussion more than the usual routine.
> 6. Try to pay attention to what your past (or concurrent) predecessor
>    release managers have done, and learn from their examples and mistakes.
> 7. Do not taunt Happy Fun Drepper.
> 
> Too strict for you?

I think this is fine! :-)

> If this baseline level of plan and constraint is something we all
> concur can be useful and have us each involved in a collaboration for
> more than one release cycle as time goes on (each not necessarily
> always being involved in each consecutive release cycle, just involved
> again and again over time, more than once for today's one version),
> then we can move on to designating release managers for particular
> release branches and hashing out what fits for a given cycle.
> 
> I hope that we will now start the first cycle of what will become a
> regular procedure over the years and releases to come, with each cycle
> easily handed off to new release managers.  The first cycle will set
> the precedents in the community that people newly coming into the
> process will refer to, so I'd like that release manager to be closely
> guided by people who have shepherded GNU releases of glibc before.
> 
> I had imagined doing it myself for 2.10, though preferably handing off
> that release stream to someone else after a point release or two (if
> its active maintenance life will go on much longer than that).
> However, I recognize the value to the community of encouraging new
> blood with the trust and faith of responsibility up front.  My sole
> priority is to build a process that will last and that will bring new
> contributors into maintaining the health of the project and renewing
> its processes.  (I think the consensus alignment of priorities is
> sufficient in this cycle that whoever this release manager is, they
> will not have much occasion to exercise concrete judgments on details.)
> 
> So I stand ready to do the pro forma work as facilitator and shepherd,
> or to stand aside if somebody is particularly gung ho to be the first
> executive of this new utopia.  (Either way, you can surely expect in
> future not to be left wondering long what my opinions are about how to
> go about things as they come up.)

I understand your position much better now, thanks for explaining it.
This seems to provide fine foundation for the actual processes.

I'm not sure what the way forward is now, though, aside of probably
waiting for further feedback a little longer. I'm willing to document
the process for release/2.10/master in the wiki and continue maintaining
the branch based on my glibc/pb-stable fork. However, I don't insist on
the position, so if you wish to do it yourself, I will not protest.

Perhaps a possible step now to clarify/confirm the policies for my fork
of the 2.10 branch in particular (to decide if it can be adopted for the
official 2.10 branch) could be for people to skim over

	http://repo.or.cz/w/glibc/pb-stable.git?a=log;h=refs/heads/glibc-2.10-branch

and suggest what patches they think might be inappropriate for the
stable branch, or which patches are missing.

I have chosen not to backport any multiarch-related changes, since that
was a work-in-progress for 2.10 and is not even listed in NEWS file.

The fixes for cancellation and nscd that I took are a bit risky;
I cherry-picked them only since it was very early in the branch and
there would be plenty testing opportunities yet; I would probably skip
them when deeper in the release branch.

-- 
				Petr "Pasky" Baudis
The lyf so short, the craft so long to lerne. -- Chaucer


Reply to: