On Mon, Feb 16, 2015 at 10:59 AM, Joshua Kinard <ku...@gentoo.org> wrote: > > Keep the core git tree constantly rolling forward, have a dedicated branch get > cut say, once a year (or less -- Debian is ~18mo?), another group of devs > works > on stabilizing that (and periodically cherrypicking from the master branch), > and when the time comes, totally freeze that for security revs only by a > smaller group of devs?
That might actually make sense for the minor archs. I'm not sure how popular it would be though for amd64. I doubt I'd use it. I think one of the big benefits of Gentoo stable is that you can have a fairly mature core system, but still track bleeding-edge for specific packages you're interested in. You can't really do that with almost any other distro. I might want to use a live version of chromium if I contribute to it, but I don't want that new release of KDE that everybody says is buggy, etc (contrived example - I've almost forgotten about 4.0 now). If we were going to be more release-based it might make more sense to do it in the sense of CI. Maybe have a daily release and a live branch, with the former being the intended target for a typical user. The daily release would be tested automatically before it was actually released (obviously this can only be done to a limited extent). The overall experience wouldn't change much, but at least the daily emerge-webrsync user would be assured to not have glaring keyword errors and such in their tree that repoman would catch. -- Rich
