On Wed, Mar 26, 2014 at 11:46 AM, Ludovic Courtès <l...@gnu.org> wrote: > I've just merged core-updates in master, and Hydra has already built > most of it. So that brings glibc 2.19, grep 2.18, libgc 7.4, guile > 2.0.11, bash 6.3, the ability to use directories as package sources > (instead of tarballs), and a bunch of other updates and improvements.
bash 6.3? Is this a typo or have I missed something? > > It's been more than 3 months between this merge and the previous one, > which is probably too much. > > To avoid lingering branches, I think we should have a more formal, > time-based process. For instance, we would let the branch live for N > months exactly, and freeze it at N months minus one week. > > GCC and glibc are released roughly every 6 months, but typically with a > 3 month offset. So I would go for N = 2 or N = 3. Maybe N = 2 is > better as it would allow us to make core improvements and small upgrades > more often. > > Thoughts? > > Thanks, > Ludo'. > Merging core-updates every 2 months sounds reasonable to me, fwiw. What are the potential downsides to frequently merging core-updates? Too much package rebuilding? Unstable software? Just curious if there are any good reasons for a more conservative approach. - Dave
