This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> I agree with these stability issues. To have a stable version (ABI > wise) every two weeks restrains us. [...] > That could be done, I agree. We should put the date in the installed > glibc, e.g. as above. But what's the difference between a version > number and a date in this regard? The difference between a date and a version number is what convention we associate with them. Basically, the de facto convention is that version numbers are associated with firm APIs and ABIs. The reason I suggested snapshot dates as a nomenclature is to have something that is clearly not a deliberate stable point of API/ABI development. That makes quite distinct the meaning of the next assigned version number, which can correspond to symbol version set names denoting newly-firmed ABIs. My motivation is to have agreement that is clear amongst ourselves, and clear to users, when ABIs are firm and when they are not. I am open to whatever details get us there. > What might work is a release branch. I would make a branch point and > port all bugfixes from mainline to this branch and then release a > glibc version - let's say a few weeks (2-4) after the branch. The > next distributor would do the same at some point of time - and we > might even see several release branches at one time :-(. My suggestion about retroactively declaring releases from prior snapshots was simply motivated by the idea of formalizing existing communal practice. I didn't suggest branches because we have not (as a community project) been using them in a meaningful way before now. I think doing so might well be a mighty fine thing. I am only looking for whatever solutions will in fact be a useful formalization of how people do now work, or would prefer to be able to work, together on glibc. The reality is that each distribution maintainer does have a release branch. There is no shame in having several such release branches--if they are actively maintained branches representing the releases major distributions are actually using. These forks exist already in the world and in the daily work of the people who participate here in communal glibc development. Each distribution's glibc maintenance operates similarly to what you described for SuSE. Jakub does that for Fedora/Red Hat. Others on this list do the same for Debian. This has always been done separate from the community glibc source repository. If those maintainers would like to use branches in the shared public repository for this, I think that would be great. Jakub maintains Red Hat's branch of GCC this way, and that seems to be working out well. I think keeping the different branches in a shared repository is a great way to facilitate everyone's tracking of development and maintenance. I figure anything that streamlines the process of sharing code is a boon to overall efficiency of maintenance. But this can only be worthwhile if the distribution maintainers want to do it. I do not speak for any of them. If people don't want to do it, it's moot. An important component of Ulrich's original notion was the need to recognize the way glibc release, distribution, and maintenance is in fact taking place. We don't need bureaucracy to help the communal effort catch up. We need to start with the separate efforts that have been doing the job in the real world, leverage those, formalize what really does take place already, and collectively improve it from there. There will probably always be differences between the glibc release branches used by different distributions. Each has its own compatibility obligations, usage circumstances, and policy decisions that may well never be agreed as appropriate for the official community standard glibc code base. That is fine. What we are concerned with here is that which can be shared. An official release branch is only useful if the distribution maintainers find it of practical aid to their productivity and effectiveness. It's not to anyone's benefit if maintaining the release branch per se is an extra chore with no inherent utility. If there are multiple distribution release branches, then I would hope that it would be natural and easy to maintain a communal release branch that contains exactly the fixes that everyone is going to use in their own releases. If the forks keep in synch this way so that when code is taken into a branch, its text matches exactly with the shared release branch, the diffs between a distribution's glibc and the canonical release branch will be just the minimum that they have to be. Then the tip of the shared branch can be named an official release yielding canonical tarball contents, and each different flavor of glibc source package will need only that and a small distribution-specific amount of patching. I think it would be great to do this in the future. But there is no point in me specifying how it would be. The distribution maintainers have to say what they want to do. I am eager to hear. We have not really had "release freezes" (at least lately). But there are "quiet" periods where ABIs are not being perturbed and everyone is focussed on stabilizing changes. For example, since version.h was bumped to 2.3.3, there were no ABI additions and there were lots of necessary bug fixes in recent weeks. Only in the last few days have 2.3.4 symbols been added. Up until then, the trunk could have been said to have been in release freeze for 2.3.3 (if we had such a formal process, which we don't). If we did make release branches, we might not want to have made one before 2004-1-13 or so. That is, the way branches are done should follow what development is doing at any given time, not try to be rigid. OTOH, if we had a formal process of freezing ABI changes to version sets, we'd better have done that earlier, since OS distributions shipped with GLIBC_2.3.3 version sets before then. To me that emphasizes the need to better formalize what is going on now, without trying to slow it down. I've written a lot. But I think we really just need to do a few straightforward things to cooperate in a more efficient way that helps all of our work. If everyone is committed, I think making it happen will come easily, and I look forward to facilitating that. Thanks, Roland
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |