Re: Future Releases
I'm sorry to hear this, Kate. You have done an amazing job, and it's been an honor to work with you in this role. On the wider scale of Ubuntu culture/politics, the change could turn out to be a good thing. In many open source projects with corporate sponsors, the Release Manager is a role appointed through community governance processes. In recent years there has been some (entirely understandable) tension caused by a role that is so central to the entire Ubuntu Project being appointed through the Canonical hiring process. Some very practical questions I'm sure will be discussed at UDS: - Who will run the weekly project-wide release meeting? - How will the flavors coordinate their releases and release needs? - What will the process be for keeping on top of release critical bugs and ensuring they don't slip through the cracks of somebody else's problem? Canonical can eliminate the employment position, and distribute internal release-related work, but there are still a number of functions within the Ubuntu Project that will need to be served by someone. Logically this work falls to the Release Team, and it will be largely up to you all to decide how you want to distribute it (with guidance from additional members of the TB who aren't already on the Release Team, if you want it), and whether to recognize some form of coordination role or roles in the team with responsibility for various pieces. Allison On 10/12/2012 06:53 AM, Kate Stewart wrote: Dear Release Team members and Ubuntu Flavor leads, Evolution and organic changes across Canonical have resulted in headcount consolidation such that there will be no dedicated Release Manager role going forward. I am proud to be a member of the Ubuntu community and the best release team around, and intend to remain so for the foreseeable future. I will be in my current role with Canonical until 28 October and will continue to work with you to complete the 12.10 release. My plans for UDS at this time are still emerging, at a minimum I look forward to participating remotely in the usual 12.10 feedback session during UDS and as many other sessions as possible. Thank you for your support throughout my time at Canonical and for your help during this transition. Kind regards, Kate -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Nautilus crashes
Hello all - I don't have the LP privileges to nominate bugs, so I'm (nervously) posting here. In the time I spend triaging, and running Quantal myself, I keep seeing three nautilus crashes that have had private master bugs. Although many developers can see them, I'm not sure if that has contributed to their not being nominated for Quantal yet. And I'm seeing reports from users who don't realize that the background nautilus has crashed. But they're getting the problems that Unity has without nautilus (which itself is bug 952321). So I wonder if that, too, is masking the problems a bit. Whether these bugs should in fact be nominated, I have to leave to those who know the process better. But let me note them. Bugs 1054297 and 1053862 have just recently been made public, happily. Bug 1054737, which I think may be the most common, is still private at the moment. If that could be made public, at least, it would be great. I can't see the page to know the description there, but apport sends me here whenever this crash happens: Nautilus crashed with SIGSEGV in gtk_widget_destroy https://bugs.launchpad.net/bugs/1054737 And the now-public ones: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1054297 https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1053862 As a user and triager, I'm driven a bit batty by private master bugs, and I look forward to their demise. Excuse me if this madness has led me to post unnecessarily here. Thank you! Ed Donovan -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Fwd: Application of UIFEs
Forwarding to ubuntu-release,ubuntu-doc,and ubuntu-translators at Iain Lane's suggestion. Original Message Subject:Application of UIFEs Date: Fri, 05 Oct 2012 11:28:19 +0100 From: John Lea john@canonical.com To: product-strat...@lists.canonical.com CC: Sebastien Bacher sebastien.bac...@canonical.com, Didier Roche didier.ro...@canonical.com, Jason Warner jason.war...@canonical.com, iain.l...@canonical.com, kate.stew...@canonical.com, Cristian Parrino cristian.parr...@canonical.com Hi All, Over the past week there have been a couple of cases where bug fixes have been IMHO incorrectly marked as requiring UIFEs. UIFEs are an important process step to make sure that string changes are translated and that users reading documentation are not confused. However visual bug fixes that do not involve string changes or bug fixes will not cause any user confusion if the documentation is not updated should not require a UIFE. Two of the examples from last week are: #1043808 - Preview activation doesn't have instant feedback #1052513 - 'More suggestions' icons in App Lens are too large In the case of the first bug, although adding a loading spinner is a visual change, if the documentation is not updated users will not be confused. This change also has no translation impact. In the case of the second bug, making the 'More Suggestions' app icons in the App Lens the correct size and thus fixing the bad pixelation will again not confuse users even if the documentation is not updated, and also this bug fix has no translation impact. Over zealous application of the UIFE rules increases the likelihood that fixes to bugs like these will not land in Quantal. I hope that we can take a more pragmatic approach when considering which bugs do or do not require a UIFE, and consider the total impact on all Ubuntu users of landing or not landing a bug fix, and not just the documentation impact. For example should we choose: a) perfectly consistent documentation with badly pixelated app icons in both the documentation and the App Lens for the Quantal cycle. b) to fix this bug in the App Lens even though the documentation would then become slightly inconsistent with the implementation? A yardstick to help make this choice could be will the user be confused by this documentation inconsistency. Of course the root cause of these problems is how late all the features have been landing this cycle. Ideally all the features that are landing into a release should be complete by Feature Freeze; this would then give us enough time to really reduce the number of bugs we are seeing at this point in the cycle. However this is a different (and also very important) discussion. cheers, John -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Application of UIFEs
On 05/10/12 12:11, Matthew East wrote: On 5 October 2012 11:54, John Lea john@canonical.com wrote: Forwarding to ubuntu-release,ubuntu-doc,and ubuntu-translators at Iain Lane's suggestion. Original Message Subject: Application of UIFEs Date: Fri, 05 Oct 2012 11:28:19 +0100 From: John Lea john@canonical.com To: product-strat...@lists.canonical.com CC: Sebastien Bacher sebastien.bac...@canonical.com, Didier Roche didier.ro...@canonical.com, Jason Warner jason.war...@canonical.com, iain.l...@canonical.com, kate.stew...@canonical.com, Cristian Parrino cristian.parr...@canonical.com Hi All, Over the past week there have been a couple of cases where bug fixes have been IMHO incorrectly marked as requiring UIFEs. UIFEs are an important process step to make sure that string changes are translated and that users reading documentation are not confused. However visual bug fixes that do not involve string changes or bug fixes will not cause any user confusion if the documentation is not updated should not require a UIFE. Please also take into account that documentation includes screenshots, which are invalidated by changes to how the desktop or its components look visually. We used to have two separate freezes, one involving changes to strings, another involving changes to the user interface. These have now been combined into a single User Interface Freeze, which applies to both types of change. I appreciate that not all design changes will invalidate screenshots, but many of them have the potential to, so this should be borne in mind as this discussion proceeds. Yes, I think it is exactly the question of what impact visual changes have on screenshots that needs clarification. Do we fix the 'pixelated app icons in the App Lens' bug even if this would mean that the implementation would be slightly different from the screenshot in the documentation? Would any users be confused by this difference? If we have to choose between: a) fixing a visual bug in the Ubuntu interface (which is seen by all our users every day) b) not fixing the bug in the Ubuntu interface so that the documentation screenshots are 100% consistent with the implementation. Which is the right choice? This release has been absolutely horrendous from the point of view of respecting freezes. Whatever solution is adopted, it is important that there is not a general expectation that freezes are made to be broken as there is a last minute rush to introduce fixes which could and should have been raised much earlier. Agreed about respecting freezes, but respecting freezes is a different discussion. Even if new features get landed on time, there will always be bugs, so these questions would still be relevant. Of course if the new features had landed earlier this cycle we would have had more time to fix bugs, but there will always be some bugs. Matt -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Application of UIFEs
On 5 October 2012 12:42, John Lea john@canonical.com wrote: On 05/10/12 12:11, Matthew East wrote: Original Message Subject: Application of UIFEs Date: Fri, 05 Oct 2012 11:28:19 +0100 From: John Lea john@canonical.com To: product-strat...@lists.canonical.com CC: Sebastien Bacher sebastien.bac...@canonical.com, Didier Roche didier.ro...@canonical.com, Jason Warner jason.war...@canonical.com, iain.l...@canonical.com, kate.stew...@canonical.com, Cristian Parrino cristian.parr...@canonical.com Hi All, Over the past week there have been a couple of cases where bug fixes have been IMHO incorrectly marked as requiring UIFEs. UIFEs are an important process step to make sure that string changes are translated and that users reading documentation are not confused. However visual bug fixes that do not involve string changes or bug fixes will not cause any user confusion if the documentation is not updated should not require a UIFE. Please also take into account that documentation includes screenshots, which are invalidated by changes to how the desktop or its components look visually. We used to have two separate freezes, one involving changes to strings, another involving changes to the user interface. These have now been combined into a single User Interface Freeze, which applies to both types of change. I appreciate that not all design changes will invalidate screenshots, but many of them have the potential to, so this should be borne in mind as this discussion proceeds. Yes, I think it is exactly the question of what impact visual changes have on screenshots that needs clarification. Do we fix the 'pixelated app icons in the App Lens' bug even if this would mean that the implementation would be slightly different from the screenshot in the documentation? Would any users be confused by this difference? It's a question of balancing, on the one hand, the benefits of fixing the bug, against on the other hand, the effects that will have on screenshots (which - depending on the context and the extent of the change - may not just be about confusing users, but also a question of ensuring that the screenshots look professional). Weighing up that balance is not something we can address in the definition of what fixes are subject to the UIFE process in the first place. It's exactly what the freeze exception process is there to do: to weigh up the pros and cons, and decide whether an exception is justified or not. Matthew -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Fwd: Application of UIFEs
On Friday, October 05, 2012 11:54:01 AM John Lea wrote: Forwarding to ubuntu-release,ubuntu-doc,and ubuntu-translators at Iain Lane's suggestion. Original Message Subject: Application of UIFEs Date: Fri, 05 Oct 2012 11:28:19 +0100 From: John Lea john@canonical.com To: product-strat...@lists.canonical.com CC: Sebastien Bacher sebastien.bac...@canonical.com, Didier Roche didier.ro...@canonical.com, Jason Warner jason.war...@canonical.com, iain.l...@canonical.com, kate.stew...@canonical.com, Cristian Parrino cristian.parr...@canonical.com Hi All, Over the past week there have been a couple of cases where bug fixes have been IMHO incorrectly marked as requiring UIFEs. UIFEs are an important process step to make sure that string changes are translated and that users reading documentation are not confused. However visual bug fixes that do not involve string changes or bug fixes will not cause any user confusion if the documentation is not updated should not require a UIFE. Two of the examples from last week are: #1043808 - Preview activation doesn't have instant feedback #1052513 - 'More suggestions' icons in App Lens are too large In the case of the first bug, although adding a loading spinner is a visual change, if the documentation is not updated users will not be confused. This change also has no translation impact. In the case of the second bug, making the 'More Suggestions' app icons in the App Lens the correct size and thus fixing the bad pixelation will again not confuse users even if the documentation is not updated, and also this bug fix has no translation impact. Over zealous application of the UIFE rules increases the likelihood that fixes to bugs like these will not land in Quantal. I hope that we can take a more pragmatic approach when considering which bugs do or do not require a UIFE, and consider the total impact on all Ubuntu users of landing or not landing a bug fix, and not just the documentation impact. For example should we choose: a) perfectly consistent documentation with badly pixelated app icons in both the documentation and the App Lens for the Quantal cycle. b) to fix this bug in the App Lens even though the documentation would then become slightly inconsistent with the implementation? A yardstick to help make this choice could be will the user be confused by this documentation inconsistency. Of course the root cause of these problems is how late all the features have been landing this cycle. Ideally all the features that are landing into a release should be complete by Feature Freeze; this would then give us enough time to really reduce the number of bugs we are seeing at this point in the cycle. However this is a different (and also very important) discussion. You misunderstand the purpose of UIF and there is time between feature freeze and UI freeze precisely to work out UI affecting bugs. I believe you are trying to solve the wrong problem. I agree it is a problem that so many bugs needed review for a UIFe, but I think the root of that problem is that PS landed so much, so late. The bureaucracy is much easier if you get your stuff in on time. Scott K -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
