This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Glibc stable release process (Glibc 2.26.1)


"Yann E. MORIN" <yann.morin.1998@free.fr> writes:

> Let's say that we decide to use today's last commit on the branch, which
> is d37c951fde57e8acb320a9a7d437ba50a1fc3c8a. That's all good. But then
> tomorrow, new commits get pushed to the maintenance branch, and now the
> head of the same branch is 548cc83c38a91852b1e44045ead3d20ccd5db4cf
> (it is now fdf58ebc60ce0eb459fd616241b52872b3571ac1; writing this mail
> took much longer than I anticipated ;-] ).
>
> So in three days time, our "choice" would look no better as if we had
> randomly choosen a commit on the tree. There is nothing that makes that
> one stand out more than the ones before or after. Except that at some
> point in time, it was the latest. But that is useless past that very
> moment.

Tarballs and tags will have the same problem.

IMHO, the only solution to this is to streamline the process of distributing
the source from upstream to downstream.

> The alternative, that only guarantees the former, but does not help on
> the latter, is to cary the now-42 patches from the branch locally.
>
> This is ugly, because it is very easily prone to bitrot, and like
> explained above, would be missing later patches, so the set of patch
> would look no less randomly chosen that chosing a sha1 would be.

Agreed, although I still believe that carrying a tarball without extra patches
will cause the same issues.

> On 2017-09-29 18:38 -0300, Tulio Magno Quites Machado Filho spake thusly:
>> I'm not opposing to a point release, but considering how the glibc community
>> has been working, I don't think it helps to make it more stable, reviewed or
>> officially sanctioned.
>> 
>> [1] https://sourceware.org/glibc/wiki/Release/#General_policy
>
> So, lemme quote this:
>
>     Each branch has so-called interested parties, usually glibc maintainers
>     in distributions where the particular branch is being used; tagging
>     revisions on the release branches should result of consensus between the
>     maintainer and interested parties - one workable model is that the
>     maintainer suggests that he wants to release and other people check if
>     they are happy with the set of patches included and the timing is
>     fine-tuned; if a release is important for one of the parties (e.g.
>     distribution nearing a release), they can suggest a release of new
>     revision as well if it is meaningful. 
>
> Is there a way to register the Buildroot project as an interested party?

https://sourceware.org/glibc/wiki/Release/#Distribution_Branch_Mapping

But I also suggest to subscribe to https://sourceware.org/ml/libc-stable/ 

-- 
Tulio Magno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]