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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
