Re: glibc release branch procedures
On Wed, Jun 3, 2009 at 11:18 PM, Roland McGrathrol...@redhat.com wrote: 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? No. I think they are exactly what I would have suggested. You mention it earlier in your email, but it should be made a separate point. 8. The release manager has veto. Enshrined in our fast growing GlibcGit wiki page. http://sourceware.org/glibc/wiki/GlibcGit Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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
Re: glibc release branch procedures
On Sun, 24 May 2009, Petr Baudis wrote: Hi, I added glibc maintainers of several major Linux distributions to Cc list to gather their opinions on what kind of patches should be included in the glibc-2.10-branch if they were to use that instead of the current practice (the only release and variously large patchball of backported fixes). I included Debian, they just switched to eglibc, but its 2.10 branch is likely to track glibc-2.10 in the future (is it, jsm?). Yes, if a glibc-2.10 branch starts receiving commits then EGLIBC 2.10 will follow it (possibly with other backports specific to EGLIBC as well). There is an important proviso that release-branch changes that require corresponding release-branch changes to ports are problematic and cannot be merged until the corresponding ports changes are on a corresponding ports release branch. There were such problematic changes on the glibc-2.5 and glibc-2.6 release branches, but in general it's probably best to avoid backporting such internal interface changes that need all targets to change, even if they do fix bugs without affecting the external interface. As a ports maintainer I am happy to create a 2.10 branch for ports if one for libc starts being used and merge selected fixes there (generally following similar procedures to whatever may be followed for libc) - but if the internal interface change situation arises, the changes obviously can't go on the release branch for ports until they are first ready for mainline development. I would generally favour being liberal as to what bug fixes are accepted for a release branch (given that they are in mainline first, do not involve ABI/API changes and do not require other target-specific changes). -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: glibc release branch procedures
On Sunday 24 May 2009 07:44:40 Petr Baudis wrote: I'm full-quoting the mail. Summary of previous discussion: Me and Roland agree that (up to exceptions) only cherry-picked commits from master will appear on the branch, they will be only bugfixes and API/ABI will never be changed. What we agree about less is the degree of strictness on what patches to include. i think a pretty good rule is that if most distros are going to be including this anyways, it should be in the branch. not sure if that helps guide the strictness aspect at all. -mike signature.asc Description: This is a digitally signed message part.
Re: glibc release branch procedures
Hi, I added glibc maintainers of several major Linux distributions to Cc list to gather their opinions on what kind of patches should be included in the glibc-2.10-branch if they were to use that instead of the current practice (the only release and variously large patchball of backported fixes). I included Debian, they just switched to eglibc, but its 2.10 branch is likely to track glibc-2.10 in the future (is it, jsm?). I'm full-quoting the mail. Summary of previous discussion: Me and Roland agree that (up to exceptions) only cherry-picked commits from master will appear on the branch, they will be only bugfixes and API/ABI will never be changed. What we agree about less is the degree of strictness on what patches to include. (I could also plug in that I triggered this by starting an effort to maintain an unofficial glibc-2.10 branch at http://repo.or.cz/w/glibc/pb-stable.git.) On Fri, May 22, 2009 at 09:25:52PM -0700, Roland McGrath wrote: Like I said, that old message was just a starting point for discussion. Reading it alone lacks the context of the even earlier discussion about this (sorry, pointers not handy). That gist of that context is that community release branches are only really useful at all if they are in fact a convenient means of collaboration for distro glibc maintainers. All my intents about release management are based on that premise. The proposals about strict rules for bugzilla and so forth presupposed also actually working out and implementing procedures for bugzilla workflow that keep it all convenient and well-tracked for everyone, which never happened either. That is another discussion I hope we might be able to jump-start again soon and tie it into the release management ideas as we hash it all out. But certainly any new branch conventions relating to bugzilla don't make sense until we work out what to do with bugzilla to make it not such a mess. The core idea about a conservative filter on what goes into a release branch is to make sure it stays something that is a common baseline for update releases acceptable to all distro maintainers and to official GNU maintainers. To keep GNU maintainers happy, it needs to be all cherry-picks (or manual backports when needed) from mainline. To keep distro maintainers happy, it needs to be patches that they would include in their glibc update packages anyway. So the gate-keeping role of a branch's release manager is to ascertain a true consensus among different distro maintainers each actively working on a distro stream based on this branch, and then apply a smell test from a pure community/GNU perspective. (Every distro will always carry some patches, and there may well be a patch that every distro agrees on but that we won't ever think is appropriate for a GNU release.) Note that this does not have to be absolute consensus, though - a distribution can also include a patch to back out a change (like when we re-disabled gethostbyname4() for glibc-2.9). Not that this should happen regularly. That consensus comes from each maintainer's judgment of tested and right enough for this maintenance stream. The character of that judgment will vary for different maintenance streams and over different periods of the lifetime of a release stream. That's as it should be. The tested in production rules in that old message of mine was just a vague attempt to codify what we know every serious distro maintainer will be doing anyway (i.e. having tested your new stable distro builds with the patches before submitting them). The official GNU bug-fix releases (if they were ever to happen) would be far less frequent than new distro stable builds being distributed for testing. The latter often happens on a daily basis. But that also means that we should be conservative about when do we tag a bug-fix release, but we can be liberal on what we _commit_. If we commit liberally, _then_ let distribution packagers to test that and tag if it stays stable for reasonable period of time, the workflow is much simpler and the overhead is a lot less than what you outline below. The point being, we can revert patches on the stable branch too. The workflow I envision is something like this: 1. distro maintainer chooses a patch to include in a distro glibc update. (This step might implicitly include fixing the bug, submitting the fix for mainline, etc.) First puts it in a distro branch, private topic branch then merged into distro branch, or just package-build patch, builds new distro package, tests it, decides it is good. (For any nontrivial fix, the it is good decision presumably follows some users/testers using that build.) For open-collaboration distros, doing that inherently includes publishing the build, somewhere at least known to the distro's developer/tester community. 2. distro maintainer puts patch on a could be merged branch (i.e. one that forks
