On Tue, Dec 6, 2016 at 9:11 AM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Mon, Dec 05, 2016 at 06:41:27PM -0700, Chris Murphy wrote: >> On Mon, Dec 5, 2016 at 5:03 PM, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: >> > On Mon, 2016-12-05 at 16:10 -0500, Matthew Miller wrote: >> >> It was by design, though — for a while, when a schedule slipped, we >> >> planned the next schedule as 6 or 7 months from the actual release. >> >> This time, we tried to keep it to October even though the previous >> >> release had slipped, resulting in the short schedule. I'm the person >> >> who pushed for that (because of the value of calendar consistency), >> >> and >> >> I'm now saying it was a mistake. >> > >> > I still think it's a good idea for Workstation. We really need to be >> > seen as the leading GNOME distro: that's what gets GNOME people using >> > Workstation and recommending that other people install it, then those >> > people recommend it... I think it's part of the story behind our recent >> > rise in popularity. Right now we are that leading GNOME distro because >> > we usually follow about 1-2 months behind a GNOME release. It's a huge >> > advantage over, say, Ubuntu, where people complain about needing PPAs >> > to get the latest software and upstream has already moved on to newer >> > versions half a year ago. Right now this is one of our biggest >> > strengths as a distro, and your proposal would throw that away. So >> > there is real serious risk of changing this. >> > >> > Also, if we do one release per year, then I expect most of the Red Hat >> > developers who work on GNOME would start using some unstable copr to >> > get the latest GNOME; this means way fewer developers using and testing >> > the latest release, since it's too stale. (I dunno what I'd do myself, >> > stick around and use a GNOME copr, or try to go improve Tumbleweed...?) >> >> I'd expect .1 or +1 would rebase on the most recent GNOME. > > I expect we'd also rebase the virtualization stack in any .1 release, > or even in the middle of a release if Fedora switched to a yearly > major release cycle. 6+ months is already a long time to wait to push > out new features to users, so making it longer is really not helpful > from KVM virt stack pov. > > If we get lots of stuff rebasing in a .1 release though, it seems that > the result is not dramatically different from what we're doing today > with 6 monthly releases. Completely agree here, there's also the same risk of instability without the advantage of being able to add features that require toolchain/mass rebuild changes. Peter _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
