Ludovic Courtès <address@hidden> writes: > Heya Marius! > > Marius Bakke <address@hidden> skribis: > >> There are actually not a lot of high severity fixes in 2.27 yet. I >> opted for this mostly as a proof-of-concept for a couple of reasons. > > Good. :-) > >> The question is which do we pick? Portability fixes for arches we don't >> (yet) support? Some of the locale fixes seem genuine, and not just >> typos, e.g.: >> >> * https://sourceware.org/bugzilla/show_bug.cgi?id=22517 >> * https://sourceware.org/bugzilla/show_bug.cgi?id=22848 > > [...] > >> But, we risk missing important commits this way, and may cause headaches >> for people wanting to port Guix to a new architecture. And the approach >> doesn't really scale for branches approaching ~100 commits. >> >> Regardless, here is a patch with just the above commits. Let me know if >> you spot others in the history that look important. WDYT? > > “Which ones do we pick” summarizes the problem, I think. It’s > upstream’s job to pick a set of changes and declare a new release. It > seems to me that we’re kinda doing the glibc release manager’s job here, > except we lack insight compared to them: it’s harder for us to judge > which changes are critical, which changes are just the beginning of > broader modifications/fixes, etc. > > I’d be willing to just use upstream’s release. It has bugs, no doubts, > but the next release will have its own bugs too. :-) Furthermore, > SONAMEs and symbol versioning is quite critical, but it’s usually done > under the assumption that people use releases, not intermediate > snapshots. > > I understand that glibc’s 2.27 branch is stable, contains nothing but > bug fixes, and in that sense is rather safe. Still… > > WDYT? I pushed the patch with the cherry-picked fixes. I'd rather not knowingly break "date" on some locales, or introduce runtime issues on i686. But I do agree that these things should really be upstreams job. All the distros I've checked take the entire branch, so we are the "odd kid out". But I guess that's nothing new. ;-) > BTW, what about emailing the libc people to add you to the list of > distro maintainers at <https://sourceware.org/glibc/wiki/MAINTAINERS>? > I think it could be useful. That might be useful indeed. I'll look into it. I think we're getting ready to build core-updates now. Should we try starting the 'core' subset on Hydra? Maybe also set a 'freeze' date?
signature.asc
Description: PGP signature
--- End Message ---