Why not do the opposite and provide the old one as a copr? Splitting up the release in the premiere os distribution of gnome seems very wrong. It'd be like serving a chef's signature dish but swapping out one of her planned sides by default. Present the chefs vision on the menu and allow diners to arrange for substitutions as needed with their waiter. Mmm yum as a waiter.
Sent from my phone, which is not an iphone.
-------- Original message -------- From: Adam Williamson awilliam@redhat.com Date:01/25/2014 6:54 PM (GMT-05:00) To: Michael Catanzaro mcatanzaro@gnome.org Cc: Discussions about development for the Fedora desktop desktop@lists.fedoraproject.org Subject: Re: So are we skipping a gnome release?
On Sat, 2014-01-25 at 16:42 -0600, Michael Catanzaro wrote:
On Sat, 2014-01-25 at 21:02 +0200, Elad Alfassa wrote:
For the reference, here's the feature list https://wiki.gnome.org/ThreePointEleven/Features
In addition to that from what I've seen in blogs there are more headerbar improvements, new gedit design, new nautilus design, and probably more things I forgot to mention or aren't there yet but might be added by the time it releases.
Hm, Nautilus hasn't seen much more than bugfixes since 3.6. There's indeed a bold new design, but it has not been implemented and surely won't be in 3.12. Nobody's going to care about the Nautilus update.
gedit will be a very major change, though. A lot of GNOME users will love it. Many will not.
How tied-in is gedit? Could we keep it at 3.10 and bump everything else to 3.12, and maybe provide gedit 3.12 in a COPR for those who want it (if we don't go with the all-of-3.12 in a COPR plan)?
On Sat, 2014-01-25 at 19:07 -0500, Máirín Duffy wrote:
Why not do the opposite and provide the old one as a copr?
That's a possibility too, but it doesn't seem to quite fit as well. It'd be a good thing to diverge from the update policy as minimally as possible, and the high-level intent of the update policy is 'don't change things unexpectedly'. It sounds like gedit is the one change in 3.12 that might catch people by surprise, so I think it's worth considering making that part of 3.12 'opt-in' - by putting it in a COPR - if we can achieve that cleanly.
Splitting up the release in the premiere os distribution of gnome seems very wrong. It'd be like serving a chef's signature dish but swapping out one of her planned sides by default. Present the chefs vision on the menu and allow diners to arrange for substitutions as needed with their waiter. Mmm yum as a waiter.
Obviously that's the right thing to do when it's part of a new release, but now we're talking about updating an existing Fedora release, we have competing imperatives - 'keep GNOME as a glorious whole!' is one imperative, but 'follow the Fedora policy (i.e. respect the principle that updates shouldn't drastically change how things work)' is a competing imperative. It seems reasonable to try and consider the best balance of the two.
Having gedit 3.12 as 'opt-in' rather than 'opt-out' just seems to fit a bit nicer to me - my instinct is that people will find "We're providing GNOME 3.12 as an update, but gedit's behaviour is drastically changed, so to be safe, we're leaving the old version of gedit by default so you don't see an unexpected change - if you want the new version, grab it here!" a better 'story' (I threw that one in just for you memo-list readers ;>) than "We're providing GNOME 3.12 as an update, along with the heavily changed gedit experience which may surprise you, if you are unpleasantly surprised by the new gedit experience, once you're done cursing at us as a bunch of morons who don't understand the concept of a stable release, you can downgrade back to the old experience here!"
And, on a purely practical level, it's much cleaner from a packaging POV to provide an older version in the repos and a newer version in COPR than vice versa. If we put the older one in COPR, we'd have to do some icky stuff with epochs to let you install it to 'supersede' the newer version from the repos, I think.
On Sat, 2014-01-25 at 16:29 -0800, Adam Williamson wrote:
It sounds like gedit is the one change in 3.12 that might catch people by surprise, so I think it's worth considering making that part of 3.12 'opt-in' - by putting it in a COPR
- if we can achieve that cleanly.
It'll be the most user-visible, but there are lots of other applications that will feature significant changes. gitg, several games, File Roller, and GNOME Software all come to mind.
All apps will notice changes from the GTK+ and Adwaita upgrade. A good amount (probably a majority) of the complaints about the new gedit were actually only about the design of the tabs (which I think look excellent, but there's no denying they're very unpopular). Well, that wasn't a gedit change: it's going to happen during this update even if you hold gedit at 3.10.
I really do want to see this update happen: I think Fedora users will appreciate it, and I think it's justified by the exceptional change to the normal release schedule. But it'd be silly to pretend there won't be significant UI changes all over the place.
On Sat, 2014-01-25 at 19:14 -0600, Michael Catanzaro wrote:
On Sat, 2014-01-25 at 16:29 -0800, Adam Williamson wrote:
It sounds like gedit is the one change in 3.12 that might catch people by surprise, so I think it's worth considering making that part of 3.12 'opt-in' - by putting it in a COPR
- if we can achieve that cleanly.
It'll be the most user-visible, but there are lots of other applications that will feature significant changes. gitg, several games, File Roller, and GNOME Software all come to mind.
Given the user audience of gitg I wouldn't be _too_ worried about it (and I think it's pretty inarguable that the new version is massively better, right?). File-roller has basically just been converted to the new style of menus, right? We already have a mix between converted and not-converted apps in F20, and have for several releases, so I wouldn't _expect_ one app being converted as part of an update to throw anyone for a huge loop. I think Software is probably in the same bucket as gitg, right, I don't think any of the changes are particularly controversial/surprising, they just make things *better*, right? Still, Software would be a component we should test very thoroughly and carefully if we're going to go for a version bump.
All apps will notice changes from the GTK+ and Adwaita upgrade. A good amount (probably a majority) of the complaints about the new gedit were actually only about the design of the tabs (which I think look excellent, but there's no denying they're very unpopular). Well, that wasn't a gedit change: it's going to happen during this update even if you hold gedit at 3.10.
I really do want to see this update happen: I think Fedora users will appreciate it, and I think it's justified by the exceptional change to the normal release schedule. But it'd be silly to pretend there won't be significant UI changes all over the place.
Thanks for highlighting the issues. I think the way forward would be to take a proposal to FESCo - a really *good faith* proposal, highlighting all the user-visible changes to to experience that it would involve, and including a justification / consideration of the issues with changing the user experience in unexpected ways with updates to stable releases - and see where that goes. If FESCo signs off on the idea, we can take a look at whatever restrictions/caveats they impose, and then deal with the practical implementation questions: how should we do it, what if anything should be hold back, if we hold anything back should we have it optionally available in a COPR, how should we test it, and what should the 'release criteria' be...
On Sat, 2014-01-25 at 17:46 -0800, Adam Williamson wrote:
Still, Software would be a component we should test very thoroughly and carefully if we're going to go for a version bump.
Software already crashes fairly often in Fedora 20. Hopefully 3.12 will be more stable.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Michael Catanzaro -
Máirín Duffy