Re: motu-release

2010-02-26 Thread Steve Langasek
On Thu, Feb 18, 2010 at 03:52:49PM -0500, Scott Kitterman wrote:
  Regarding the team unification, is there an expectation that the two-vote
  approach will continue?  I don't have a strong preference between the
  ubuntu-release and motu-release approaches, but I think it would be strange
  to be applying different procedures for different archive sections - or to
  different members of the team! - so we should probably pick one...

 I think it should go.  IMO one of the main reasons to unify the teams is to 
 simply the process for people trying to work through getting needed 
 approvals.  
 If we have two separate rule sets, we may as well keep it two teams (I'm not 
 proposing we do this).

I think the attached diff for FreezeExceptionProcess reflects the emerging
consensus.  Are there any objections if I apply this to the wiki and send
out an updated freeze process mail to u-d-a?

Are there any team delegations we want to have in place before sending out
the announcement?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--- tmpdCsjqP.moin.orig	2010-02-25 07:47:35.037545082 -0800
+++ tmpdCsjqP.moin	2010-02-25 07:58:00.317544338 -0800
@@ -139,7 +139,7 @@
 
 == General Instructions ==
 
-Requests for freeze exceptions for `main` should be filed as bugs in launchpad against the relevant package (or just Ubuntu if the package is not available yet).  Once the bug is filed and the necessary information is available, subscribe [[https://launchpad.net/~ubuntu-release|ubuntu-release]] (main, restricted) or [[https://launchpad.net/~motu-release|motu-release]] (universe, multiverse). All freeze exceptions must include the following information, in order to provide them with enough information to weigh the risk of regressions against the benefit of the changes:
+Requests for freeze exceptions should be filed as bugs in launchpad against the relevant package (or just Ubuntu if the package is not available yet).  Once the bug is filed and the necessary information is available, subscribe [[https://launchpad.net/~ubuntu-release|ubuntu-release]]. All freeze exceptions must include the following information, in order to provide them with enough information to weigh the risk of regressions against the benefit of the changes:
 
  * A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution
  * A rationale for the exception, explaining the benefit of the change
@@ -157,25 +157,6 @@
   * installs and upgrades,
   * does not break packages which depend on it, or that corresponding updates have been prepared.
 
-== UserInterfaceFreeze Exceptions ==
-
-The exception request bug report needs to have a justification why the user interface needs to be changed at that point, and give a rationale why the benefits of it are worth breaking existing documentation and translations.
-
-Every change of the user interface (either a string or the layout) requires you to notify the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc|documentation]] and [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators|translation]] teams. Please include a link to these posts in the mailing list archives of [[https://lists.ubuntu.com/archives/ubuntu-doc/|ubuntu-...@]] and [[https://lists.ubuntu.com/archives/ubuntu-translators/|ubuntu-translat...@]].
-
-After that, subscribe the release team, as usual.
-
-== Milestone freeze Exceptions (like BetaFreeze) ==
-
-During milestone/final release freeze periods, extreme caution is exercised when considering exceptions, as a regression could cause a deadline to be missed, or a build to receive less testing than desired.  A request for an exception must demonstrate strong rationale and minimal risk for the update to be considered.
-
-Exception requests must include the following additional details:
-
- * It must fix a bug milestoned for that particular milestone.
- * A complete `debdiff` of the proposed upload must be provided (preferably as bug attachment).
-
-== Exceptions for Universe/Multiverse ==
-
 === FeatureFreeze for new upstream versions ===
 
 If you want to introduce a new upstream version with new features and/or ABI/API changes, please
@@ -196,45 +177,63 @@
* for instance a copy and paste of the install messages from console when installing
   * mention what testing you've done to see that it works 
* a screenshot showing the main features could also be nice
- * subscribe (not assign) it to the '`motu-release`' team.
- * In some cases a standing freeze exception for multiple uploads is the most efficient way to manage the freeze process. Standing freeze exceptions should be requested in bugs using the normal process, although not all elements of a standard FFe request 

Re: motu-release

2010-02-26 Thread Daniel Holbach
Thanks for your work on this!

On 26.02.2010 07:43, Steve Langasek wrote:
 I think the attached diff for FreezeExceptionProcess reflects the emerging
 consensus.  Are there any objections if I apply this to the wiki and send
 out an updated freeze process mail to u-d-a?

Sounds good to me, only one small oversight that I spotted:

+ * Or ask a member of the `ubuntu-release`
[[http://launchpad.net/~motu-release|team]] on IRC of approval for the
debdiff.

That should be ~ubuntu-release, I guess.


 Are there any team delegations we want to have in place before sending out
 the announcement?

I'd say go for it and discuss more team delegations in the release
meeting? Maybe the delegation process should be documented on the page too?

Have a great day,
 Daniel

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu


Re: dbeacon and SixXS graphics

2010-02-26 Thread Faidon Liambotis
Hugo Santos wrote:
 It'd be nice to fix this for Debian's and Ubuntu's LTS next releases, I
 guess the SixXS guys would appreciate it :)
 
   Yes, it would be awesome.
dbeacon 0.3.9.3 is in Debian testing since 2010-02-21.

Ubuntu MOTU, could you make sure that it gets an exception from your
Debian import freeze?

Thanks,
Faidon

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu


Re: motu-release

2010-02-26 Thread Scott Kitterman
 On Thu, Feb 18, 2010 at 03:52:49PM -0500, Scott Kitterman wrote:
  Regarding the team unification, is there an expectation that the
 two-vote
  approach will continue?  I don't have a strong preference between the
  ubuntu-release and motu-release approaches, but I think it would be
 strange
  to be applying different procedures for different archive sections -
 or to
  different members of the team! - so we should probably pick one...

 I think it should go.  IMO one of the main reasons to unify the teams is
 to
 simply the process for people trying to work through getting needed
 approvals.
 If we have two separate rule sets, we may as well keep it two teams (I'm
 not
 proposing we do this).

 I think the attached diff for FreezeExceptionProcess reflects the emerging
 consensus.  Are there any objections if I apply this to the wiki and send
 out an updated freeze process mail to u-d-a?

 Are there any team delegations we want to have in place before sending out
 the announcement?

It looks good to me.  No objections.

WRT delegations: I think between Riddell and myself Kubuntu is already
well covered.  In the past I was the server team delegate for Universe,
but the only purpose that served was to obviate the double ack rule. 
Since we're getting rid of that rule, I think there's no need.  I woulnd't
let getting delegation sorted out stop announcing thins.

Scott K


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu