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)


On 03 Oct 2017, Siddhesh Poyarekar wrote:

>On Tuesday 03 October 2017 12:52 AM, Florian Weimer wrote:
>>
>> I still don't understand why you need tarballs for releases, though.  or
>> put differently, the difference between glibc 2.26.5 and glibc 2.26-40
>> seems rather minor to me, and producing the tarballs is quite a bit of
>> work for us.  
>
>Right.  To be clear, even if I agree to do one now, it should not be
>binding on any future release managers to do the same for their release
>branch.  Maybe it makes sense to have a targeted discussion like this
>with the final decision being that of the release manager for that release.

If you actually agree to do one now, are we going to have something
similar to a code freeze?  I'm asking because I believe some patches
should probably be considered release blockers, such as those in these
threads:

  - https://sourceware.org/ml/libc-alpha/2017-09/msg00486.html
    (already committed on the master branch)
  - https://sourceware.org/ml/libc-alpha/2017-10/msg00102.html
    (not yet on master, but probably relevant to the point-release)

Maybe there are more, and eventually others will emerge, so I have no idea
what criteria should be used to decide what goes in and what stays out of
this point release.

I agree that a targeted discussion about the need for a point release (as
you suggested) makes sense, but then it probably would also make sense to
discuss the relevance of particular patches as release blockers, which adds
to the work required for the release.


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