Re: glibc release branch procedures
You've talked a lot about detailed concrete criteria for what to include
on a release branch and how to operate it. That's a lovely discussion,
but I think it may have a bit missed the point of what I'm trying to start.
With the special exception of copyright rules, the sum of what I intended
to propose and ask is:
Each release branch would be operated by the consensus of distro glibc
maintainers participating with that particular branch, constrained by
veto of a particular release manager designated for the branch. This
is in aid of making official GNU C Library releases, so each release
manager would be charged with representing the standards and interests
of the GNU Project and the overall GNU C Library community.
Would distro glibc maintainers be interested in trying to collaborate
centrally on that basis?
It sounds like the answer to that is, "Yes." That question and that
answer don't say anything about which distros will participate in any
particular release branch, nor who any particular branch's release
manager might be, nor anything about what concrete details would
constitute the consensus between those distro maintainers and that
release manager.
The mainstay of my plan is delegation. So now I'd like to get started
on being just organized enough that we can actually have a future of
regular cycles where different releases will have different release
managers but each branch keeps some coherent process. Constraints,
styles, preferences, and priorities will vary among different managers
and for different releases. That is well and good, and it's what the
plan (i.e. my vague hope) has always been. The bottom line is that
for each cycle we want to choose a person well and delegate, and if a
release manager's judgment and choices deeply violate the expectations
of the trunk maintainers, GNU officialdom, or old grumps, we should
have a fresh exciting crisis of hand-wringing and mutual immolation as
we are deservedly known for. So, on to the attractive but fetchingly
sheer fig leaf of organization.
I hereby solicit somebody to make sure the results of these discussions
get wikiized. Don't all fall over yourselves rushing to volunteer.
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?
As I said at least twice, all the concrete details and workflow
examples I gave were just that: *examples* of how some particular
release branch's conventions and its manager's workflow one day might
work. For any actual release branch, the specific details will depend
entirely on its manager, the participating package maintainers, and
their particular priorities and constraints for that one release stream.
I had not thought about using reverting commits (i.e. 'git revert')
instead of just conservative choices about which commits to merge.
That level of detail of how to go about things is certainly something
that should be up to the given release manager.
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.)
Thanks,
Roland
Reply to: