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 2.24 -- Release blockers


I forgot to add in the previous email my initial idea for the dates
regarding 2.24 release.

I would like to start hard freeze by July 12th (Tue), it will give
us some time to settle (either commit or drop) the remaining release
blockers.

Based on previous releases, I would like to follow with 4 weeks for
testing and set the release date to Aug 2th.  Depending of testing
discussion I think it might be feasible to short it to just 3 weeks.

On 07/07/2016 16:50, Adhemerval Zanella wrote:
> Hi all,
> 
> Now that we proposed and defined current release blockers, I would like
> to move forward and either commit them or move to 2.25.  The idea is, as
> in previous releases, to have a somewhat large time window to allow 
> multiple arch and distro maintainers to test the upcoming release.
> 
> I plan to announce hard freeze by the start of next week, so we have a
> quite narrow time window to sort out all the current release blockers.
> The idea is to have all of them either committed or postponed to 2.25.
> 
> The current release blockers are listed in release wiki [1] below and I am
> listing them with some comments:
> 
>   * [BZ #20139] Don't allow configure with not supporting AVX512 assembler 
>     w/o --disable-avx512 [2]
> 
>     This seems to fix possible broken build depending of binutils and target
>     hardware. I tend to see this a arch specific issue where the arch 
>     maintainer should have the final answer.
> 
>   * [BZ #20309] X86-64: Properly align stack in _dl_tlsdesc_dynamic [3]
> 
>     This seems to be an important ABI fix and look ok to me.  I think also
>     the arch maintainer have the final word.
> 
>   * Revised^2: deprecate major/minor/makedev in sys/types.h [4]
> 
>     This is a 4 patch set.  I see from previous iterations that some
>     developers would like to include it in 2.24. 
> 
>     First patch is already commit. 
> 
>     Second patch seems ok with just the version inclusion and abifiles update
>     seems to be wrong.  There is not compat symbol being added and both old
>     an new version seems to be produce the same output.  I will reply to
>     original thread.
> 
>     Patch 3 also seems most straightforward and I think is ok for upstream.
> 
>     Patch 4 also seems ok. 
> 
>     I am plan to check all the patches (with second one being adjusted to
>     not add any version in Version or abilist).
> 
>   * Refactor Linux raise implementation (BZ#15368) [5]
> 
>     I think I addressed all the issue from previous revisions and I would like
>     to commit it before hard release.
> 
>   * Remove __ASSUME_OFF_DIFF_OFF64 definition [6]
> 
>     This is another cleanup that I would like to push on 2.24 mainly to get rid
>     of superfluous __ASSUME_OFF_DIFF_OFF64 define.  I see it is mostly safe, since
>     the __OFF_T_MATCHES_OFF64_T have the same meaning.
> 
>     I would also like to push it before hard freeze.
> 
>   * Add pretty printers for the NPTL lock types [7]
> 
>     I do not have a strong opinion about this one, but I do see some developers
>     would like to push this forward on 2.24.  Since it is not a non-intrusive
>     and tests are already returning UNSUPPORTED, so I think it is safe for testing.
>     I will let the reviewers of the thread device or not if the patch is ok for
>     inclusion.
> 
>   * [BZ #13165] New condition variable [9]
> 
>     I would like to move forward on this one.  Based on Torvald feedback is has been
>     tested on fedora rawride I think it is ok for inclusion.
> 
>     I will also check on the architectures I have access.
> 
>   * [BZ #20024] Fixed vector sincos/sincosf ABI [10]
> 
>     This is another ABI fix that I think should be up to arch maintainer the final
>     word.
>     
>   * malloc: Remove malloc_get_state, malloc_set_state [11]
> 
>     I plan to test and review this patch as well, but I think is should be safe
>     due its limited usage by programs.
>     
> 
> So I would like for inputs of current blocker and if should move any of them to
> 2.25 (I see we have a narrow window for hard freeze).
> 
> Florian, could you also handle the security bugs (NEWS addition, CVE identifiers,
> etc.) since you already have some experience from previous releases?
> 
> 
> [1] https://sourceware.org/glibc/wiki/Release/2.24
> [2] https://sourceware.org/ml/libc-alpha/2016-06/msg01280.html
> [3] https://sourceware.org/ml/libc-alpha/2016-06/msg01209.html
> [4] https://sourceware.org/ml/libc-alpha/2016-05/msg00274.html
> [5] http://patchwork.sourceware.org/patch/13220/
> [6] http://patchwork.sourceware.org/patch/13448/
> [7] https://sourceware.org/ml/libc-alpha/2016-06/msg01126.html
> [8] https://sourceware.org/ml/libc-alpha/2016-05/msg00605.html
> [9] https://sourceware.org/ml/libc-alpha/2016-05/msg00605.html
> [10] https://sourceware.org/ml/libc-alpha/2016-07/msg00008.html
> [11] https://sourceware.org/ml/libc-alpha/2016-06/msg00905.html
> 


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