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 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org