Re: Alpha Criterion Discussion: Desktop Backgrounds
On Mon, Aug 10, 2015 at 9:19 PM, Adam Williamson adamw...@fedoraproject.org wrote: On Mon, 2015-08-10 at 14:43 +0200, Jaroslav Reznik wrote: Also for KDE theming, final wallpapers packages has to exist before (it's not that important these days, as we do not change design too much and it's more like sed-version of Fn package but still causes delays). It seems rather bizarre that KDE needs a new source package for its theme for every distro release. Is there any reason why this is actually *necessary*? In reality, it's even more complicated :). But it should be possible to alter fxx-backgrounds to install everything in place, create symlink that could be used by other themes to pick up current default wallpaper. And there would be only one master theme, so it would no require even any changes in kde-settings (to make it all default). This all comes from times, when I was young and I had a lot of time to really play with theming. Aka times of Solar wp where KSplash theme had small micro-comets, UI was inspired by wp etc. So let's take a look how to change it - as currently creating new theme is more sed-like task instead of anything else. Jaroslav -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- -- Jaroslav Řezník jrez...@redhat.com Engineering Program Manager Office: +420 532 294 645 Mobile: +420 602 797 774 PIN: REZZABBM Red Hat, Inc. http://www.redhat.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Mon, Aug 10, 2015 at 5:27 PM, Paul W. Frields sticks...@gmail.com wrote: On Fri, Aug 07, 2015 at 01:23:10PM -0400, Matthew Miller wrote: On Fri, Aug 07, 2015 at 10:03:34AM -0700, Adam Williamson wrote: The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation [...] * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. Yeah; if this wasn't clear in my last message, I think that it does, unfortunately, seem to work that way by default for lack of any better/stronger schedule reminder system. I think in any case where we *do* hit something which slipped off whichever non-QA schedule, we should fix _that_ side first. Now, maybe it is also the case that the wallpaper is not really an appropriate blocker. I'm pretty sympathetic to that point on its own, too. So, I think the appropriate thing to do here is to drop this particular blocker, but add it to something else that serves as a that reminder system — ideally, with some form of teeth. Since this seems like a program management function, I'm going to talk to Jan Kurik — Fedora Program Manager — about it. This sounds like a very good idea to me, Matthew. That's actually the way how we did it :). At some point, I checked what's the status of backgrounds, very often Design team was already on it (as always, great job). But sometimes it was stuck and that was my job to unstuck it. Yes, I could leverage the blocker to push on Desing team but I don't think it's really that necessary as great guys on board. Jaroslav -- -- Jaroslav Řezník jrez...@redhat.com Engineering Program Manager Office: +420 532 294 645 Mobile: +420 602 797 774 PIN: REZZABBM Red Hat, Inc. http://www.redhat.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 01:23:10PM -0400, Matthew Miller wrote: On Fri, Aug 07, 2015 at 10:03:34AM -0700, Adam Williamson wrote: The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation [...] * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. Yeah; if this wasn't clear in my last message, I think that it does, unfortunately, seem to work that way by default for lack of any better/stronger schedule reminder system. I think in any case where we *do* hit something which slipped off whichever non-QA schedule, we should fix _that_ side first. Now, maybe it is also the case that the wallpaper is not really an appropriate blocker. I'm pretty sympathetic to that point on its own, too. So, I think the appropriate thing to do here is to drop this particular blocker, but add it to something else that serves as a that reminder system — ideally, with some form of teeth. Since this seems like a program management function, I'm going to talk to Jan Kurik — Fedora Program Manager — about it. This sounds like a very good idea to me, Matthew. To be clear, I wasn't speaking for anyone on the Design team, nor trying to describe their team process. Rather I was noting that I've observed that deadlines (which correspond to the blocker process, obviously) have kicked up efforts on background wp. I don't think anyone on the Design team intends to abuse the blocker process, nor do I think they're directly doing so. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Mon, 2015-08-10 at 14:43 +0200, Jaroslav Reznik wrote: Also for KDE theming, final wallpapers packages has to exist before (it's not that important these days, as we do not change design too much and it's more like sed-version of Fn package but still causes delays). It seems rather bizarre that KDE needs a new source package for its theme for every distro release. Is there any reason why this is actually *necessary*? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 7, 2015 at 8:32 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Aug 07, 2015 at 02:03:31PM -0400, Stephen Gallagher wrote: Here's a thought: maybe the Fedora background logo GNOME Shell plugin could detect if running on an Alpha/Beta release (or on Rawhide) and change appropriately? Which is fine and dandy on a GNOME/Workstation system, but doesn't help KDE at all. Could there be something equivalent for KDE? A plasma widget? It might be possible to create such Plasma widget for consistency between main desktop offerings. And it will be just a few lines of QML code, not a heroic effort. I'll take a look. I'm just not sure I like it at all :). For wallpapers and release blocking... It's always nice to have at least some version of backgrounds in Alpha to get feedback. There were wallpapers voted down by community after Alpha. But there might be more ways how to ensure feedback, I can imagine packaging it for stable Fn version, so everyone can install it and try etc. Btw. I don't like that enforcing part of being Alpha blocker. With Sirko, we pushed so much once that Design community wasn't happy that something was marked as Alpha wp... Also for KDE theming, final wallpapers packages has to exist before (it's not that important these days, as we do not change design too much and it's more like sed-version of Fn package but still causes delays). On the other hand - we have to force new wallpaper for final release, so it's final release... And on the third hand - we can just use one wallpaper for longer than one release and only change it, if there's newer, nicer, more modern design? But it's more question for Design team... So many options :D. Jaroslav -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- -- Jaroslav Řezník jrez...@redhat.com Engineering Program Manager Office: +420 532 294 645 Mobile: +420 602 797 774 PIN: REZZABBM Red Hat, Inc. http://www.redhat.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On 08/07/2015 10:41 PM, Kevin Fenzi wrote: On Fri, 07 Aug 2015 10:03:34 -0700 Adam Williamson adamw...@fedoraproject.org wrote: This is exactly what I *don't* want to happen, and what rather annoys me about this whole business. The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation the blocker process is built around is that people should be working towards its requirements *all the time*, ideally well in advance, and the blocker process is there to catch the relatively *few* cases where things break unexpectedly. It's absolutely not supposed to work like this: * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. +1000. +1k1. I'd like to propose something somewhat shocking. How about we get these things done in rawhide, so we are a release ahead of things instead of scrambling to get them done at the last minute all the time. Cannot the design team work on F24 wallpaper _right_ now? get it in rawhide and test that it's all there and then when we branch it's done, they can work on f25 in rawhide and so on. +1. In this process we would have to work on both 24 and 25 simultaneously, with higher priority on 24. Cause on the day we branch from rawhide, they should have 25 wallpaper ready so that people don't get confused again :) Another proposal would be to have a rawhide wallpaper with watermark (probably the same wallpaper as of of n+1 release with watermark saying rawhide). That way, design team would need not worry about 2 simultaneous release wallpaper, if that helps. Regards, Sudhir Just a thought... kevin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 11:59:51AM -0700, Adam Williamson wrote: Here's a thought: maybe the Fedora background logo GNOME Shell plugin could detect if running on an Alpha/Beta release (or on Rawhide) and change appropriately? That's certainly what I thought would help with the whole backgrounds thing, yes - making it *more* complex and tied to advanced desktop -specific functionality. (you may wish to apply your sarcasm detector to the above sentence :) Aw man -- I was just about to take it literally. :) In any case, the reasoning is: this is a one-time thing which would then not require any updates or new design or action on any calendar. Except, of course, keeping the branding widget/extension working, which we want to do anyway. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
Auto Freeze Exeception seems too complicated an answer to this question. Either continue to call new background a blocker, or decide it is desirable but not a blocking issue. If lovely new art is not available, some generic Fnn background could be used then replaced by an update after release, in order to avoid delay. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
There are pros and cons to a generic background to pass the blocker status. The benefit of course is that it fulfills the need to be a different background and thus detectable as not the latest/stable etc. The cons is that quality of that generic background image may be less than it currently is, and that could change perception of the quality of the Alpha itself to anyone outside the core group who experiments with it. So, if we could come up with a high-quality, generic background image that is the image we always use for prerelease etc, then sounds like a good compromise. There wouldn't be a holdup for new artwork, yet it would look different and thus noticable as not stable. Going back to the criteria of 'different from the two prior stable releases' - suggests we could recycle earlier release backgrounds? At least as a temporary patch for Alpha. Mind you, when I read the requirements, I take a different reason for why we have it - and that would be to detect I have the latest/greatest Fedora. Does that background change between Alpha and final release? If not, then I'd suggest the alpha blocker is more for showing off the new release than detecting it's an unstable release. Sandra On Fri, Aug 7, 2015 at 9:15 AM, Richard Ryniker ryni...@alum.mit.edu wrote: Auto Freeze Exeception seems too complicated an answer to this question. Either continue to call new background a blocker, or decide it is desirable but not a blocking issue. If lovely new art is not available, some generic Fnn background could be used then replaced by an update after release, in order to avoid delay. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On 08/08/15 05:42, Matthew Miller wrote: On Fri, Aug 07, 2015 at 10:22:56AM -0700, Adam Williamson wrote: What I *can't* find is any reference for the justification usually cited for the criterion. Several times we mention that there was an actual case where people downloaded an Alpha or Beta then got confused because the background was the same as the previous stable release, but I've been searching for 15 mins and can't find it. This is probably just because it's a difficult thing to search for, though. It's worth noting that we used to use considerably more 'striking' desktop backgrounds than we currently do; the last few releases have all been fairly subtle variations on the theme of 'abstract shapes in Fedora blue', really. Here's a thought: maybe the Fedora background logo GNOME Shell plugin could detect if running on an Alpha/Beta release (or on Rawhide) and change appropriately? Some us fled from GNOME, when GNOME 3 was unleashed! I now use Mate, and avoid GNOME as much as is practicable. Cheers, Gavin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On 08/08/15 03:06, Kevin Fenzi wrote: [...] I don't even think the desktop background is all that visible anymore, especially on some desktops (like workstation/gnome). People there tend to use full screen apps and never even see the wallpaper. That also seems like a pretty poor way to tell what release you are running. I have a 30 monitor and have 35 Virtual Desktops under Mate. The only time I regularly use a full screen app is for Eclipse IDE. Not all of us have a Microsoft mentality! :-) It is usually more productive, not to automatically make apps fullscreen. [...] Cheers, Gavin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 2015-08-07 at 09:15 -0400, Richard Ryniker wrote: Auto Freeze Exeception seems too complicated an answer to this question. Either continue to call new background a blocker, or decide it is desirable but not a blocking issue. That's fair. I was trying to offer an alternative to that ultimatum, but maybe it *is* a bit of a premature optimization. If lovely new art is not available, some generic Fnn background could be used then replaced by an update after release, in order to avoid delay. Believe it or not, the way wallpapers are handled today, that would actually be no easier to accomplish (and probably harder) than actually updating them properly. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 09:06:26AM -0600, Kevin Fenzi wrote: I don't even think the desktop background is all that visible anymore, especially on some desktops (like workstation/gnome). People there tend to use full screen apps and never even see the wallpaper. FWIW, I use GNOME without fullscreen apps. On the other hand, I also don't see the wallpaper since I change it to a plain dark gray. :) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 07 Aug 2015 08:30:44 -0400 Stephen Gallagher sgall...@redhat.com wrote: As promised at yesterday's Go/No-Go meeting, I'm starting a discussion on the Alpha criterion that states: The default desktop background must be different from that of the two previous stable releases. As I understand it, the intent is essentially that no one booting a Fedora pre-release should infer that it is a stable release and that this should be obvious from the desktop background. I don't even think the desktop background is all that visible anymore, especially on some desktops (like workstation/gnome). People there tend to use full screen apps and never even see the wallpaper. That also seems like a pretty poor way to tell what release you are running. I suppose this makes some sense for Live media (particularly when burned to a USB stick that may not have a label). That being said, I do not agree that this should be a *blocking* issue for release. I agree. I think we should remove this critera from the alpha critera. ...snip... I'd like to propose that we remove this as a strict blocking criterion and instead introduce a new category of criteria for automatic freeze -exceptions of which this could be a part. Essentially, up to the moment that an RC is declared gold, any changes made to support an automatic freeze-exception must be pulled in. The idea would be that these auto-FEs should still be part of the validation runs, but not blocking for the release. Does this seem like a reasonable middle-ground? I don't think we should do this, it sounds overcomplex. How about we just let new backgrounds propose as FE's and get pulled in if we feel they should be. kevin pgpdyMxg_x472.pgp Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 08:30:44AM -0400, Stephen Gallagher wrote: It's very likely to get into last blocker discussions (as it did yesterday). (By last blocker I mean those cases where the Go/No-Go would tend to waive it as a blocker if it was the only one holding up a release). To me, that means it's not really a blocker (and shouldn't be classified as one). I'm not sure it should be dropped as a blocker. A lot of these things are here as a way of encoding institutional knowledge so that if someone was doing something we found to be important every release but then moves on to somethin else, it doesn't get forgotten. Maybe the release criteria aren't the best place for it, but we don't have much else which is a) global, b) well-documented, and c) has teeth. Making a non-blocker-but-checked state removes c, and while it theoretically keeps a and b, I'm kind of afraid that without c, the first ones fall by the wayside in the last-minute crunch. But, really, every time something gets into a last-minute crunch, we should evaluate how we can avoid that problem for the next release. (For example, with this cloud boot problem, the automated testing we're working on for two-week atomic will transfer directly to having much earlier warning about that kind of problem.) So, rather than dropping it as the first response, I think we should check if someone — from Design, presumably, possibly with the assistance of the maintainers of the backgrounds rpm; or else from the Workstation team — will put this on their schedule for next and future releases well before Alpha. If we can't find someone to do that, *then* weigh whether it is really important (and, if we decide it still is, look harder for the commitment). -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 09:06:26AM -0600, Kevin Fenzi wrote: On Fri, 07 Aug 2015 08:30:44 -0400 Stephen Gallagher sgall...@redhat.com wrote: As promised at yesterday's Go/No-Go meeting, I'm starting a discussion on the Alpha criterion that states: The default desktop background must be different from that of the two previous stable releases. As I understand it, the intent is essentially that no one booting a Fedora pre-release should infer that it is a stable release and that this should be obvious from the desktop background. I don't even think the desktop background is all that visible anymore, especially on some desktops (like workstation/gnome). People there tend to use full screen apps and never even see the wallpaper. That also seems like a pretty poor way to tell what release you are running. I suppose this makes some sense for Live media (particularly when burned to a USB stick that may not have a label). That being said, I do not agree that this should be a *blocking* issue for release. I agree. I think we should remove this critera from the alpha critera. ...snip... I'd like to propose that we remove this as a strict blocking criterion and instead introduce a new category of criteria for automatic freeze -exceptions of which this could be a part. Essentially, up to the moment that an RC is declared gold, any changes made to support an automatic freeze-exception must be pulled in. The idea would be that these auto-FEs should still be part of the validation runs, but not blocking for the release. Does this seem like a reasonable middle-ground? I don't think we should do this, it sounds overcomplex. How about we just let new backgrounds propose as FE's and get pulled in if we feel they should be. That sounds reasonable. I think it would make sense for the Design team to be aware of this proposal too. I think the criterion has been used as a forcing function in the past, so if it's not going to trigger a notification they expect, we don't want designers to be surprised by this change in the future. Obviously this change would beg the discussion of how they manage background art schedule in the future, but at least we want to afford them the opportunity. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 2015-08-07 at 09:15 -0400, Richard Ryniker wrote: Auto Freeze Exeception seems too complicated an answer to this question. Either continue to call new background a blocker, or decide it is desirable but not a blocking issue. If lovely new art is not available, some generic Fnn background could be used then replaced by an update after release, in order to avoid delay. This is actually exactly what's supposed to happen already, but it seems no-one ever implemented such a mechanism. The criterion was already watered down back in 2012 (from a version requiring the wallpaper correctly identify the release) specifically to allow for use of a generic pre-release wallpaper outside of final releases. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 07 Aug 2015 10:03:34 -0700 Adam Williamson adamw...@fedoraproject.org wrote: This is exactly what I *don't* want to happen, and what rather annoys me about this whole business. The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation the blocker process is built around is that people should be working towards its requirements *all the time*, ideally well in advance, and the blocker process is there to catch the relatively *few* cases where things break unexpectedly. It's absolutely not supposed to work like this: * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. +1000. I'd like to propose something somewhat shocking. How about we get these things done in rawhide, so we are a release ahead of things instead of scrambling to get them done at the last minute all the time. Cannot the design team work on F24 wallpaper _right_ now? get it in rawhide and test that it's all there and then when we branch it's done, they can work on f25 in rawhide and so on. Just a thought... kevin pgpcGwFs074_p.pgp Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 2015-08-07 at 11:57 -0400, Paul W. Frields wrote: I think it would make sense for the Design team to be aware of this proposal too. I think the criterion has been used as a forcing function in the past, so if it's not going to trigger a notification they expect, we don't want designers to be surprised by this change in the future. This is exactly what I *don't* want to happen, and what rather annoys me about this whole business. The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation the blocker process is built around is that people should be working towards its requirements *all the time*, ideally well in advance, and the blocker process is there to catch the relatively *few* cases where things break unexpectedly. It's absolutely not supposed to work like this: * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 02:03:31PM -0400, Stephen Gallagher wrote: Here's a thought: maybe the Fedora background logo GNOME Shell plugin could detect if running on an Alpha/Beta release (or on Rawhide) and change appropriately? Which is fine and dandy on a GNOME/Workstation system, but doesn't help KDE at all. Could there be something equivalent for KDE? A plasma widget? -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 10:22:56AM -0700, Adam Williamson wrote: What I *can't* find is any reference for the justification usually cited for the criterion. Several times we mention that there was an actual case where people downloaded an Alpha or Beta then got confused because the background was the same as the previous stable release, but I've been searching for 15 mins and can't find it. This is probably just because it's a difficult thing to search for, though. It's worth noting that we used to use considerably more 'striking' desktop backgrounds than we currently do; the last few releases have all been fairly subtle variations on the theme of 'abstract shapes in Fedora blue', really. Here's a thought: maybe the Fedora background logo GNOME Shell plugin could detect if running on an Alpha/Beta release (or on Rawhide) and change appropriately? -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 07, 2015 at 10:03:34AM -0700, Adam Williamson wrote: The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation [...] * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. Yeah; if this wasn't clear in my last message, I think that it does, unfortunately, seem to work that way by default for lack of any better/stronger schedule reminder system. I think in any case where we *do* hit something which slipped off whichever non-QA schedule, we should fix _that_ side first. Now, maybe it is also the case that the wallpaper is not really an appropriate blocker. I'm pretty sympathetic to that point on its own, too. So, I think the appropriate thing to do here is to drop this particular blocker, but add it to something else that serves as a that reminder system — ideally, with some form of teeth. Since this seems like a program management function, I'm going to talk to Jan Kurik — Fedora Program Manager — about it. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 2015-08-07 at 09:59 -0700, Adam Williamson wrote: On Fri, 2015-08-07 at 09:15 -0400, Richard Ryniker wrote: Auto Freeze Exeception seems too complicated an answer to this question. Either continue to call new background a blocker, or decide it is desirable but not a blocking issue. If lovely new art is not available, some generic Fnn background could be used then replaced by an update after release, in order to avoid delay. This is actually exactly what's supposed to happen already, but it seems no-one ever implemented such a mechanism. The criterion was already watered down back in 2012 (from a version requiring the wallpaper correctly identify the release) specifically to allow for use of a generic pre-release wallpaper outside of final releases. For some history, here's the discussion: https://meetbot.fedoraproject.org/fedora-bugzappers/2010-09-03/fedora-b ugzappers.2010-09-03-16.00.log.html/ (search for 'art') that led to the original criteria: https://lists.fedoraproject.org/pipermail/test/2010-September/093476.ht ml Here's the proposed blocker from 2012: https://bugzilla.redhat.com/show_bug.cgi?id=849982 that led to watering down the criteria to their current state: https://lists.fedoraproject.org/pipermail/test/2012-August/109712.html The discussion of the blocker is in this meeting: https://meetbot.fedoraproject.org/fedora-bugzappers/2012-08-22/f18-alph a-blocker-review-4.2012-08-22-16.01.log.html What I *can't* find is any reference for the justification usually cited for the criterion. Several times we mention that there was an actual case where people downloaded an Alpha or Beta then got confused because the background was the same as the previous stable release, but I've been searching for 15 mins and can't find it. This is probably just because it's a difficult thing to search for, though. It's worth noting that we used to use considerably more 'striking' desktop backgrounds than we currently do; the last few releases have all been fairly subtle variations on the theme of 'abstract shapes in Fedora blue', really. Purely considering this criterion on its merits, I can live with removing at least the Alpha component. What worries me about this whole process is that twice now we'll have realized we can't meet some requirements which should be really pretty easy and decided to just throw them out instead. It should not be beyond the abilities of a decade-old software project to update its desktop backgrounds in a timely fashion. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 2015-08-07 at 13:42 -0400, Matthew Miller wrote: On Fri, Aug 07, 2015 at 10:22:56AM -0700, Adam Williamson wrote: What I *can't* find is any reference for the justification usually cited for the criterion. Several times we mention that there was an actual case where people downloaded an Alpha or Beta then got confused because the background was the same as the previous stable release, but I've been searching for 15 mins and can't find it. This is probably just because it's a difficult thing to search for, though. It's worth noting that we used to use considerably more 'striking' desktop backgrounds than we currently do; the last few releases have all been fairly subtle variations on the theme of 'abstract shapes in Fedora blue', really. Here's a thought: maybe the Fedora background logo GNOME Shell plugin could detect if running on an Alpha/Beta release (or on Rawhide) and change appropriately? Which is fine and dandy on a GNOME/Workstation system, but doesn't help KDE at all. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, Aug 7, 2015 at 11:11 AM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 07 Aug 2015 10:03:34 -0700 Adam Williamson adamw...@fedoraproject.org wrote: This is exactly what I *don't* want to happen, and what rather annoys me about this whole business. The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation the blocker process is built around is that people should be working towards its requirements *all the time*, ideally well in advance, and the blocker process is there to catch the relatively *few* cases where things break unexpectedly. It's absolutely not supposed to work like this: * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. +1000. I'd like to propose something somewhat shocking. How about we get these things done in rawhide, so we are a release ahead of things instead of scrambling to get them done at the last minute all the time. Cannot the design team work on F24 wallpaper _right_ now? get it in rawhide and test that it's all there and then when we branch it's done, they can work on f25 in rawhide and so on. Just a thought... For that matter, it still baffles me that there are late changes (before and even after freeze) that get applied to Rawhide and Fedora N concurrently. I thought such changes were supposed to go in Rawhide first. That's what I think needs teeth, is ending this simultaneous application of changes to Rawhide and current. -- Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alpha Criterion Discussion: Desktop Backgrounds
On Fri, 2015-08-07 at 13:42 -0400, Matthew Miller wrote: On Fri, Aug 07, 2015 at 10:22:56AM -0700, Adam Williamson wrote: What I *can't* find is any reference for the justification usually cited for the criterion. Several times we mention that there was an actual case where people downloaded an Alpha or Beta then got confused because the background was the same as the previous stable release, but I've been searching for 15 mins and can't find it. This is probably just because it's a difficult thing to search for, though. It's worth noting that we used to use considerably more 'striking' desktop backgrounds than we currently do; the last few releases have all been fairly subtle variations on the theme of 'abstract shapes in Fedora blue', really. Here's a thought: maybe the Fedora background logo GNOME Shell plugin could detect if running on an Alpha/Beta release (or on Rawhide) and change appropriately? That's certainly what I thought would help with the whole backgrounds thing, yes - making it *more* complex and tied to advanced desktop -specific functionality. (you may wish to apply your sarcasm detector to the above sentence :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Alpha Criterion Discussion: Desktop Backgrounds
As promised at yesterday's Go/No-Go meeting, I'm starting a discussion on the Alpha criterion that states: The default desktop background must be different from that of the two previous stable releases. As I understand it, the intent is essentially that no one booting a Fedora pre-release should infer that it is a stable release and that this should be obvious from the desktop background. I suppose this makes some sense for Live media (particularly when burned to a USB stick that may not have a label). That being said, I do not agree that this should be a *blocking* issue for release. It's very likely to get into last blocker discussions (as it did yesterday). (By last blocker I mean those cases where the Go/No-Go would tend to waive it as a blocker if it was the only one holding up a release). To me, that means it's not really a blocker (and shouldn't be classified as one). I'd like to propose that we remove this as a strict blocking criterion and instead introduce a new category of criteria for automatic freeze -exceptions of which this could be a part. Essentially, up to the moment that an RC is declared gold, any changes made to support an automatic freeze-exception must be pulled in. The idea would be that these auto-FEs should still be part of the validation runs, but not blocking for the release. Does this seem like a reasonable middle-ground? signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
