Re: motu-release
Since there are no objections to the proposed diff, I've applied it now (plus Daniel's correction). I'll send out an announcement mail in the next day or so informing developers of the new procedure, then mass-migrate the motu-release bug subscriptions over to ubuntu-release. On Sun, Feb 28, 2010 at 12:35:26AM +0100, Stefan Potyra 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? > no objection, but still got a few questions: > 1) how are FFe's handled? I assume that one ACK from a member of > ubuntu-release suffices, correct? Yes, that's the intent, consistent with my own feeling on the subject and the feedback from Scott. The wiki changes reflect this, I think, by removing all mentions of the two-vote requirement. > 2) new packages: do we also just require one ACK there, or do we want two > ACKs? Also, new packages was delegated from MOTU to motu-release (or rather > motu-uvf which got renamed to motu-release later). Even later ubuntu-release > was made a member of motu-release, acknowledging that ubuntu-release should > always be able to decide for motu-release. Do we need a formal MOTU decision > to transfer this responsibility? If so (please speak up if you anyone think > that it's needed, otherwise I'll assume consensus), what is the current > process to get this decision? Effectively, the ubuntu-release team and the motu-release team are now identical, so I don't think redelegation would be needed here. As for a two-ack requirement on new packages, I have no strong feeling here either, but I think a single ack from ubuntu-release should be sufficient as it is for other exceptions. The wiki page mentions that the packages still have to go through <https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages>. > 3) Universe used to have a later deadline for final freeze, to get latest bug > fixes in. Past the deadline we used -proposed to get very late fixes in, > handing over the queue to -sru. I think this could prove worthwhile again. > Maybe we should replace universe with unseeded packages and decide later on > it? Yes, I agree that this probably needs to be s/universe/unseeded/. I don't see any explicit mention of this on the wiki page, so I think the details can be hashed out closer to the release. > > 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. > delegations also served to have the people with best knowledge cover an FFe. > Teams not mentioned yet were we had delegates are: > * mythbuntu > * mozilla team > * ubuntustudio > * xubuntu > * desktop (gnome) > * netbook > * edubuntu > I'm not yet 100% sure how delegates fit in with the motu-release and > ubuntu-release merge. I for one am happy to see the delegation process continue, at least for packages in universe (not to be confused with unseeded packages - obviously a mythbuntu or xubuntu delegate only makes sense for seeded packages :). I was never involved in delegate selection or observing closely how well particular delegated decisions worked, so I'll defer to you guys regarding who you think the delegates should be. Thanks, -- 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 signature.asc Description: Digital signature -- 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
On Thu, Feb 18, 2010 at 01:02:43PM +0100, Stefan Potyra wrote: > Definitely makes sense. I don't have a strong preference over the exact > procedure as well. How did ubuntu-release handle FFe's so far? I assume the > worklist is the list of subscribed bugs? Yep, precisely. > Do you also use the +nominations page? No, the conclusion a couple cycles back was that the +nominations list has a low S:N ratio, and anyway that feature doesn't add anything over the subscribed bugs list. Cheers, -- 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 signature.asc Description: Digital signature -- 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
Hi, Am Friday 26 February 2010 20:37:24 schrieb 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. no objection, but still got a few questions: 1) how are FFe's handled? I assume that one ACK from a member of ubuntu-release suffices, correct? 2) new packages: do we also just require one ACK there, or do we want two ACKs? Also, new packages was delegated from MOTU to motu-release (or rather motu-uvf which got renamed to motu-release later). Even later ubuntu-release was made a member of motu-release, acknowledging that ubuntu-release should always be able to decide for motu-release. Do we need a formal MOTU decision to transfer this responsibility? If so (please speak up if you anyone think that it's needed, otherwise I'll assume consensus), what is the current process to get this decision? 3) Universe used to have a later deadline for final freeze, to get latest bug fixes in. Past the deadline we used -proposed to get very late fixes in, handing over the queue to -sru. I think this could prove worthwhile again. Maybe we should replace universe with unseeded packages and decide later on it? > > 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. delegations also served to have the people with best knowledge cover an FFe. Teams not mentioned yet were we had delegates are: * mythbuntu * mozilla team * ubuntustudio * xubuntu * desktop (gnome) * netbook * edubuntu I'm not yet 100% sure how delegates fit in with the motu-release and ubuntu-release merge. Personally, for few requests I've simply subscribed the relevant persons and requested input from them, which gave the basis on my decision. I'd suggest that this scheme can be applied until we reach consensus about delegates. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- 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
> 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
Re: motu-release
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: motu-release
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 excep
Re: motu-release
On Thursday 18 February 2010 06:21:34 am Steve Langasek wrote: > On Wed, Feb 17, 2010 at 01:42:29PM +0100, Stefan Potyra wrote: > > > As a first step, I suggest merging motu-release and ubuntu-release for > > > lucid. > > > > This seems to be the consensus so far, anyone disagree? > > > > As FeatureFreeze is already tomorrow, I think we should immediately try > > to find the procedure how to handle freeze exception requests (which I > > guess will start to get filed from tomorrow on). To not block lucid > > development on the lack of a procedure, I suggest that we keep the status > > quo and have motu-release handle universe/multiverse exception requests > > with two +1 votes and have ubuntu-release handle main/restricted as an > > interim solution. > > Ack; freeze announcement sent out with the status quo. > > 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). Scott K -- 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
Hi, Am Thursday 18 February 2010 12:21:34 schrieb Steve Langasek: [..] > > Ack; freeze announcement sent out with the status quo. Thanks! > > 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... Definitely makes sense. I don't have a strong preference over the exact procedure as well. How did ubuntu-release handle FFe's so far? I assume the worklist is the list of subscribed bugs? Do you also use the +nominations page? Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- 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
On Wed, Feb 17, 2010 at 01:42:29PM +0100, Stefan Potyra wrote: > > As a first step, I suggest merging motu-release and ubuntu-release for > > lucid. > This seems to be the consensus so far, anyone disagree? > As FeatureFreeze is already tomorrow, I think we should immediately try to > find the procedure how to handle freeze exception requests (which I guess > will start to get filed from tomorrow on). To not block lucid development on > the lack of a procedure, I suggest that we keep the status quo and have > motu-release handle universe/multiverse exception requests with two +1 votes > and have ubuntu-release handle main/restricted as an interim solution. Ack; freeze announcement sent out with the status quo. 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... -- 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 signature.asc Description: Digital signature -- 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
Hi, Am Thursday 18 February 2010 02:09:04 schrieb Steve Langasek: > On Wed, Feb 17, 2010 at 11:32:13PM +0100, Stefan Potyra wrote: > > Agreed. Delegating freeze decisions for a set of packages matches very > > much what we've done with delegates so far :). > > > > motu-release chose the relevant delegates themselves. With "decisions in > > terms of freeze exceptions", I meant that not motu-release chooses > > delegates, but any team can handle freeze exception requests for a given > > subset of packages how the team think it's best. Of course this should > > include a responsibility to ask the release-team in case of potentially > > contentious packages. > > That's precisely the model that I'm arguing against. If there are to be > delegations here, they should be decided on a per-team basis, not as a > blanket policy. So not "any team can handle" - only teams for which we > identify delegates that we're confident are on the same page with the rest > of the release team. Ok, was just an idea. Your proposal sounds good to me as well. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- 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
On Wed, Feb 17, 2010 at 11:32:13PM +0100, Stefan Potyra wrote: > Agreed. Delegating freeze decisions for a set of packages matches very much > what we've done with delegates so far :). > motu-release chose the relevant delegates themselves. With "decisions in > terms > of freeze exceptions", I meant that not motu-release chooses delegates, but > any team can handle freeze exception requests for a given subset of packages > how the team think it's best. Of course this should include a responsibility > to ask the release-team in case of potentially contentious packages. That's precisely the model that I'm arguing against. If there are to be delegations here, they should be decided on a per-team basis, not as a blanket policy. So not "any team can handle" - only teams for which we identify delegates that we're confident are on the same page with the rest of the release team. -- 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 signature.asc Description: Digital signature -- 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
Hi, Am Wednesday 17 February 2010 11:03:09 schrieb Steve Langasek: > On Wed, Jan 27, 2010 at 03:03:35PM +0100, Stefan Potyra wrote: > > I've (only) talked to Daniel so far and we came up with the following > > possible alternatives: > > > > - Flavours like Kubuntu can approve their own members, so it would > >make sense to let them make decisions in terms of freeze exceptions > >too. (The MOTU Release team had delegates of various teams that > >made decisions, which worked out well.) > > Between Jonathan's Riddell's status as a member of the release team, and > his repeated delegation by motu-release regarding Kubuntu packages in > universe, I think that reasonably approximates the status quo; but I > hesitate to describe this as "flavors making their own decisions about > freeze > exceptions". So long as the Ubuntu family of distributions continue to > make releases together out of the same archive, there's a need for > coordination on such matters as the timing of the archive freeze, buildd > quiescing for ISO mastering, and release-readiness criteria; I think the > best option is to continue having a central team, which can either solicit > team members from the flavour communities or delegate freeze decisions for > a set of packages. Agreed. Delegating freeze decisions for a set of packages matches very much what we've done with delegates so far :). motu-release chose the relevant delegates themselves. With "decisions in terms of freeze exceptions", I meant that not motu-release chooses delegates, but any team can handle freeze exception requests for a given subset of packages how the team think it's best. Of course this should include a responsibility to ask the release-team in case of potentially contentious packages. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- 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
Hi, Am Wednesday 17 February 2010 11:03:09 schrieb Steve Langasek: [..] > > > - Merge motu-release and ubuntu-release? Add team members of the > >"flavours" to ubuntu-release to form kind of a "release > >taskforce"? > > As a first step, I suggest merging motu-release and ubuntu-release for > lucid. This seems to be the consensus so far, anyone disagree? As FeatureFreeze is already tomorrow, I think we should immediately try to find the procedure how to handle freeze exception requests (which I guess will start to get filed from tomorrow on). To not block lucid development on the lack of a procedure, I suggest that we keep the status quo and have motu-release handle universe/multiverse exception requests with two +1 votes and have ubuntu-release handle main/restricted as an interim solution. Hopefully we'll find a common procedure on how to hande freeze exceptions in the next few days then. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- 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
On Thu, Jan 28, 2010 at 01:04:25AM +0900, Emmet Hikory wrote: > Scott Kitterman wrote: > > On Wednesday 27 January 2010 09:03:35 am Stefan Potyra wrote: > >> FeatureFreeze is less than a month away, so the discussion over > >> restaffing the current MOTU Release team, which is a short of members > >> [1], brought up the topic how best to deal with release decisions in > >> light of Permissions Reorg. > <...> > > motu-sru and ubuntu-sru merged into a single team. I've had a couple of > > conversations with people in terms of doing something simllar with motu- > > release and ubuntu-release. I think it's the right answer. So far it's > > been > > a matter of finding time to talk with everyone about it and decide what > > should > > be done. > Could such an item be added to the agenda of the next release > meeting? It seems like the various groups typically reporting there > would be natural delegates for the various areas on which they report If you mean that they should be delegates for all the packages related to their teams, I don't think that's a good idea. If not an outright conflict of interest, leaving these decisions to the individual teams directly brings the problem of myopia alluded to in my previous message. The point of having a team approve freeze exceptions at all, instead of letting individual developers continue to upload directly to the archive, is to make sure we're collectively on the same page regarding what should be going into the release when; that means the people approving freeze exceptions for packages that land on CDs need to have an overview of the release as a whole. I don't think per-team delegates are the way to achieve this. > (and those groups that had historical delegates ought be encouraged to > participate and report in that forum). Unfortunately, the structure of the release meetings today doesn't scale well to a large number of teams, and the length of the meeting is already a challenge for scheduling. Where there is a need for other coordination within the release team, I would prefer to see this take place via either separately scheduled meetings, or email. -- 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 signature.asc Description: Digital signature -- 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
On Wed, Jan 27, 2010 at 03:03:35PM +0100, Stefan Potyra wrote: > I've (only) talked to Daniel so far and we came up with the following > possible > alternatives: > - Flavours like Kubuntu can approve their own members, so it would >make sense to let them make decisions in terms of freeze exceptions > too. (The MOTU Release team had delegates of various teams that >made decisions, which worked out well.) Between Jonathan's Riddell's status as a member of the release team, and his repeated delegation by motu-release regarding Kubuntu packages in universe, I think that reasonably approximates the status quo; but I hesitate to describe this as "flavors making their own decisions about freeze exceptions". So long as the Ubuntu family of distributions continue to make releases together out of the same archive, there's a need for coordination on such matters as the timing of the archive freeze, buildd quiescing for ISO mastering, and release-readiness criteria; I think the best option is to continue having a central team, which can either solicit team members from the flavour communities or delegate freeze decisions for a set of packages. > - Merge motu-release and ubuntu-release? Add team members of the >"flavours" to ubuntu-release to form kind of a "release >taskforce"? As a first step, I suggest merging motu-release and ubuntu-release for lucid. > - Just drop motu-release and let ubuntu-release make the decisions? I think that would only frustrate contributors, as the existing ubuntu-release team isn't likely to be able to keep up with all requests. Cheers, -- 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 signature.asc Description: Digital signature -- 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
On 17.02.2010 11:03, Steve Langasek wrote: > On Wed, Jan 27, 2010 at 03:03:35PM +0100, Stefan Potyra wrote: >> - Merge motu-release and ubuntu-release? Add team members of the >>"flavours" to ubuntu-release to form kind of a "release >>taskforce"? > > As a first step, I suggest merging motu-release and ubuntu-release for > lucid. That sounds reasonable to me. After a cleanup the documentation should be simpler too: https://wiki.ubuntu.com/FreezExceptionProcess Just in time for Feature Freeze, eh? ;-) 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: motu-release
Am Donnerstag, den 28.01.2010, 01:04 +0900 schrieb Emmet Hikory: > > motu-sru and ubuntu-sru merged into a single team. I've had a couple of > > conversations with people in terms of doing something simllar with motu- > > release and ubuntu-release. I think it's the right answer. So far it's > > been > > a matter of finding time to talk with everyone about it and decide what > > should > > be done. Since nobody objected up until now, could somebody maybe write up something quick how this should all work in the future? (Including changes to https://wiki.ubuntu.com/FreezeExceptionProcess ), so it could be discussed at the next Release team meeting? > Could such an item be added to the agenda of the next release > meeting? It seems like the various groups typically reporting there > would be natural delegates for the various areas on which they report > (and those groups that had historical delegates ought be encouraged to > participate and report in that forum). Alternately, if more time is > required, the 5th February meeting? Sounds good to me. 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: motu-release
Scott Kitterman wrote: > On Wednesday 27 January 2010 09:03:35 am Stefan Potyra wrote: >> FeatureFreeze is less than a month away, so the discussion over >> restaffing the current MOTU Release team, which is a short of members >> [1], brought up the topic how best to deal with release decisions in >> light of Permissions Reorg. <...> > motu-sru and ubuntu-sru merged into a single team. I've had a couple of > conversations with people in terms of doing something simllar with motu- > release and ubuntu-release. I think it's the right answer. So far it's been > a matter of finding time to talk with everyone about it and decide what should > be done. Could such an item be added to the agenda of the next release meeting? It seems like the various groups typically reporting there would be natural delegates for the various areas on which they report (and those groups that had historical delegates ought be encouraged to participate and report in that forum). Alternately, if more time is required, the 5th February meeting? -- Emmet HIKORY -- 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
On Wednesday 27 January 2010 09:03:35 am Stefan Potyra wrote: > Hi, > > FeatureFreeze is less than a month away, so the discussion over > restaffing the current MOTU Release team, which is a short of members > [1], brought up the topic how best to deal with release decisions in > light of Permissions Reorg. > > I've (only) talked to Daniel so far and we came up with the following > possible alternatives: > > - Flavours like Kubuntu can approve their own members, so it would >make sense to let them make decisions in terms of freeze exceptions >too. (The MOTU Release team had delegates of various teams that >made decisions, which worked out well.) > > - Merge motu-release and ubuntu-release? Add team members of the >"flavours" to ubuntu-release to form kind of a "release >taskforce"? > > - Just drop motu-release and let ubuntu-release make the decisions? > motu-sru and ubuntu-sru merged into a single team. I've had a couple of conversations with people in terms of doing something simllar with motu- release and ubuntu-release. I think it's the right answer. So far it's been a matter of finding time to talk with everyone about it and decide what should be done. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
motu-release
Hi, FeatureFreeze is less than a month away, so the discussion over restaffing the current MOTU Release team, which is a short of members [1], brought up the topic how best to deal with release decisions in light of Permissions Reorg. I've (only) talked to Daniel so far and we came up with the following possible alternatives: - Flavours like Kubuntu can approve their own members, so it would make sense to let them make decisions in terms of freeze exceptions too. (The MOTU Release team had delegates of various teams that made decisions, which worked out well.) - Merge motu-release and ubuntu-release? Add team members of the "flavours" to ubuntu-release to form kind of a "release taskforce"? - Just drop motu-release and let ubuntu-release make the decisions? - < fill in you alternative > The final question is: should we aim to resolve this for Lucid or should it be for Lucid+1? Cheers, Stefan -- [1]: <https://launchpad.net/~motu-release/+members> signature.asc Description: This is a digitally signed message part. -- 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 done for Karmic
On 2009-10-28 10:50:24 -0700, Scott Ritchie wrote: > Is there a way we could speed up SRUs for the next week? As I > understand it the current process requires uploading the package to > Lucid before backporting the fix. > > Does this mean updates are going to be impossible until Lucid is > available? I have a package ready to go into -proposed today, however > if I have to wait until Lucid is open to upload that could be much longer. I assume it will be handled like in the past: you can upload to -proposed now and once lucid opens you can catch up with fixing it in lucid too. Michael -- 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 done for Karmic
Scott Kitterman wrote: > The final deadline for motu-release approved uploads has passed. We had a > good run of fixing the last few days. Thanks everyone for the work. > > In the event of any OMG, kittens! issues for Universe/Multiverse, please > contact ubuntu-release. > > Scott K > For the MOTU Release Team > Is there a way we could speed up SRUs for the next week? As I understand it the current process requires uploading the package to Lucid before backporting the fix. Does this mean updates are going to be impossible until Lucid is available? I have a package ready to go into -proposed today, however if I have to wait until Lucid is open to upload that could be much longer. Thanks, Scott Ritchie -- 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 done for Karmic
On Tue, 2009-10-27 at 08:20 -0400, Scott Kitterman wrote: > The final deadline for motu-release approved uploads has passed. We had a > good run of fixing the last few days. Thanks everyone for the work. > > In the event of any OMG, kittens! issues for Universe/Multiverse, please > contact ubuntu-release. > > Scott K > For the MOTU Release Team Grats! -Rob signature.asc Description: This is a digitally signed message part -- 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 done for Karmic
Hi there, On Tue, Oct 27, 2009 at 08:20:25AM -0400, Scott Kitterman wrote: The final deadline for motu-release approved uploads has passed. We had a good run of fixing the last few days. Thanks everyone for the work. In the event of any OMG, kittens! issues for Universe/Multiverse, please contact ubuntu-release. Scott K For the MOTU Release Team Congratulations and well done to everyone involved. Special mention to our brave release managers :) How about a MOTU Lucid planning meeting? We've attempted to organise ourselves a bit recently but the meetings have not happened. I suggest Thursday 05 November, 1800UTC. Regards, Iain signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
MOTU Release done for Karmic
The final deadline for motu-release approved uploads has passed. We had a good run of fixing the last few days. Thanks everyone for the work. In the event of any OMG, kittens! issues for Universe/Multiverse, please contact ubuntu-release. Scott K For the MOTU Release Team -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Minutes from the MOTU Release meeting, Monday 24th Aug, 19:00 UTC
2009/8/25 Iulian Udrea > * Sebastien Bacher (seb128) was proposed again to act as a delegate for > Ubuntu > Desktop packages this cycle. This is still unclear, unfortunately. > Action: Iulian Udrea (iulian) to send an e-mail to the ubuntu-desktop ML to > find out > who will act as a delegate. > Sebastien has just agreed to act as a delegate again. Iulian -- Iulian Udrea iul...@ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Minutes from the MOTU Release meeting, Monday 24th Aug, 19:00 UTC
Hi. Here are the minutes from the MOTU Release meeting, Monday 24th August, 19:00 UTC. = Members present (4/5) = * Stefan Potyra (sistpoty) * Scott Kitterman (ScottK) * Iulian Udrea (iulian) * Steve Stalcup (vorian) Absent: Nathan Handler (nhandler) = MOTU Release delegates = * Scott Kitterman suggested to make Steve Stalcup the Qt/KDE delegate for this cycle. We all agreed. Riddell said he could be fallback if Steve becomes unavailable. * Mario Limonciello (superm1) agreed to act as a delegate for Mythbuntu again. * Cody Somerville (cody-somerville) agreed to act as a delegate for Xubuntu. He also recommended Lionel Le Folgoc (mr_pouit) to be a delegate as well. They will both be the delegates for Xubuntu this cycle. * Fabien Tassin (fta) agreed to act as a delegate for Mozilla packages, along with Alexander Sack (asac). * Luis de Bethencourt Guimerá (luisbg) and Cory Kontros (_MMA_) will act as delegates for Ubuntu Studio. * Sebastien Bacher (seb128) was proposed again to act as a delegate for Ubuntu Desktop packages this cycle. This is still unclear, unfortunately. Action: Iulian Udrea (iulian) to send an e-mail to the ubuntu-desktop ML to find out who will act as a delegate. * Steve Kowalik (StevenK) will act as a delegate for Ubuntu Netbook, Ubuntu MID. * Scott Kitterman (ScottK) for Ubuntu Server again. * We haven't delegated responsibility to no one for Edubuntu yet. It seems that Jordan Mantha (LaserJock) is unavailable at the moment. We will talk to him when he reappears. = Freeze Exception process = * There were no questions regarding the Freeze Exception process [0]. We all agreed that the process should remain the same. + 2 ACKs for the exception to become valid. + 2 ACKs for new packages as well. We won't consider exception for new packages if there are not worthwhile. + New upstream releases that are bug fix only just need a bug for documentation, no FFe. = Standing Freeze exceptions = * audacity [1] + Reinhard Tartler (siretart) suggested to don't update to the latest upstream release, 1.3.8. Reinhard said that the latest release doesn't work with ffmpeg 0.5 release. It will need a newer ffmpeg which we are not shipping. + It was agreed to wait for input from Luis de Bethencourt Guimerá on this issue. Cheers, -- Iulian Udrea iul...@ubuntu.com (On behalf of the MOTU Release team) [0] https://wiki.ubuntu.com/FreezeExceptionProcess [1] https://lists.ubuntu.com/archives/ubuntu-motu/2009-August/006079.html -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
2009/8/14 Nathan Handler > On Fri, Aug 14, 2009 at 9:00 AM, Iulian Udrea wrote: > > Nathan, does Friday, the 21st, 13:00 UTC work for you as well? > > It looks like my reply only went to Steve, and not the list. > > I could do Monday the 17th at 13:00 UTC, but I can't do 13:00 UTC on > Friday the 21st. I can do a meeting on Friday the 21st after 22:00 > UTC. > > Nathan > Bleah, I won't be home at that hour. Let's do the meeting on Monday the 24th, at 19:00 UTC. In this case, maybe Scott can be present as well. Is this too late? Iulian -- Iulian Udrea iul...@ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
On Fri, Aug 14, 2009 at 9:00 AM, Iulian Udrea wrote: > Nathan, does Friday, the 21st, 13:00 UTC work for you as well? It looks like my reply only went to Steve, and not the list. I could do Monday the 17th at 13:00 UTC, but I can't do 13:00 UTC on Friday the 21st. I can do a meeting on Friday the 21st after 22:00 UTC. Nathan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
2009/8/13 Scott Kitterman > > Hi, > > > > Am Thursday 13 August 2009 16:27:36 schrieb Steve Stalcup: > >> On Thu, Aug 13, 2009 at 9:27 AM, Iulian Udrea wrote: > >> > What about Friday, the 21st? > >> > > >> > Scott, when do you come back from holiday? > > I can't commit to be available until the 24th. > > >> > > >> > I would very much like to see all members of the motu-release team > >> > present at the meeting. > > > > yes, I agree. > > > >> > >> That date works for me. > > > > Works for me as well. > > I think it's better to meet sooner. I doubt I will disagree on anything. > > Ouh, OK. You can always send us an email if you disagree on something. Nathan, does Friday, the 21st, 13:00 UTC work for you as well? Iulian -- Iulian Udrea iul...@ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
> Hi, > > Am Thursday 13 August 2009 16:27:36 schrieb Steve Stalcup: >> On Thu, Aug 13, 2009 at 9:27 AM, Iulian Udrea wrote: >> > What about Friday, the 21st? >> > >> > Scott, when do you come back from holiday? I can't commit to be available until the 24th. >> > >> > I would very much like to see all members of the motu-release team >> > present at the meeting. > > yes, I agree. > >> >> That date works for me. > > Works for me as well. I think it's better to meet sooner. I doubt I will disagree on anything. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
Hi, Am Thursday 13 August 2009 16:27:36 schrieb Steve Stalcup: > On Thu, Aug 13, 2009 at 9:27 AM, Iulian Udrea wrote: > > What about Friday, the 21st? > > > > Scott, when do you come back from holiday? > > > > I would very much like to see all members of the motu-release team > > present at the meeting. yes, I agree. > > That date works for me. Works for me as well. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
On Thu, Aug 13, 2009 at 9:27 AM, Iulian Udrea wrote: > > What about Friday, the 21st? > > Scott, when do you come back from holiday? > > I would very much like to see all members of the motu-release team present > at the meeting. That date works for me. Steve -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
2009/8/13 Steve Stalcup > On Wed, Aug 12, 2009 at 6:11 PM, Stefan > Potyra wrote: > > > first off, welcome Steve, great to see you joining motu-release! > > Thanks! I'm happy to help out > > > Now, with Feature Freeze pending, maybe it would be a good idea to do a > > motu-release meeting again, to sort out the details for karmic's freeze. > > How about Monday, 17th Aug, 13.00 UTC? (or what other date/time would > suit > > you?) > > I will be unavailable until Wednesday the 19th (I am in the process of > moving) I will have access to email and will be more than happy > engage via mail. > > What about Friday, the 21st? Scott, when do you come back from holiday? I would very much like to see all members of the motu-release team present at the meeting. Iulian -- Iulian Udrea iul...@ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
On Wed, Aug 12, 2009 at 6:11 PM, Stefan Potyra wrote: > first off, welcome Steve, great to see you joining motu-release! Thanks! I'm happy to help out > Now, with Feature Freeze pending, maybe it would be a good idea to do a > motu-release meeting again, to sort out the details for karmic's freeze. > How about Monday, 17th Aug, 13.00 UTC? (or what other date/time would suit > you?) I will be unavailable until Wednesday the 19th (I am in the process of moving) I will have access to email and will be more than happy engage via mail. Thanks! Steve -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
> Hi folks, > > first off, welcome Steve, great to see you joining motu-release! > > Now, Feature Freeze starting at August 27 is not too far ahead, I'd like > everyone to get ready for it. > > In particular: Start to fix > 1) uninstallable packages [1] > 2) FTBFS [2] > 3) review NEW packages on REVU [3] > 4) sponsor fixes [4] > (more or less random list from my head, please anynone chime in with > additions/corrections) > > Now, with Feature Freeze pending, maybe it would be a good idea to do a > motu-release meeting again, to sort out the details for karmic's freeze. > How about Monday, 17th Aug, 13.00 UTC? (or what other date/time would suit > you?) > > Then we could sort out details like if we want delegates again, or what > general exception policy we want for karmic's release or what package sets > need immediate attention. > > Given the expectation, that delegates are desired again, and as I've had > the > pleasure to select delegates during Jaunty's cycle, whom would you suggest > for karmic? Anyone volunteering for a particular position? > > Finally, even if this may be the last time due to the archive > reorganisation, > I'd like to thank the Ubuntu release team for the good coordination and > collaboration during the last cycles. I hope for karmic we'll perform well > together again! I will be on vacation next week so am unlikely to make it, but don't let that stop you. I'm in favor of delegates and generally operating as we have before. I'd propose vorian take my spot as KDE delegate. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FeatureFreeze Aug 27 - motu-release planning ahead
Stefan Potyra wrote: > In particular: Start to fix > 1) uninstallable packages [1] > 2) FTBFS [2] > 3) review NEW packages on REVU [3] > 4) sponsor fixes [4] > (more or less random list from my head, please anynone chime in with > additions/corrections) Maybe add the NBS-List to this, packages that depend on other packages which are no longer built by any source: http://people.canonical.com/~ubuntu-archive/NBS/ -- Andreas Moog Berliner Str. 29 36205 Sontra Germany Tel.:+49(0)56 53 91 24 3 PGP-Encrypted mail preferred, please use Key-ID 0xF67089C4 Fingerprint: 7C60 6E85 F8A1 E26C 96B4 CC8D D3A1 6090 F670 89C4 signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
FeatureFreeze Aug 27 - motu-release planning ahead
Hi folks, first off, welcome Steve, great to see you joining motu-release! Now, Feature Freeze starting at August 27 is not too far ahead, I'd like everyone to get ready for it. In particular: Start to fix 1) uninstallable packages [1] 2) FTBFS [2] 3) review NEW packages on REVU [3] 4) sponsor fixes [4] (more or less random list from my head, please anynone chime in with additions/corrections) Now, with Feature Freeze pending, maybe it would be a good idea to do a motu-release meeting again, to sort out the details for karmic's freeze. How about Monday, 17th Aug, 13.00 UTC? (or what other date/time would suit you?) Then we could sort out details like if we want delegates again, or what general exception policy we want for karmic's release or what package sets need immediate attention. Given the expectation, that delegates are desired again, and as I've had the pleasure to select delegates during Jaunty's cycle, whom would you suggest for karmic? Anyone volunteering for a particular position? Finally, even if this may be the last time due to the archive reorganisation, I'd like to thank the Ubuntu release team for the good coordination and collaboration during the last cycles. I hope for karmic we'll perform well together again! Cheers, Stefan. [1]: <http://qa.ubuntuwire.com/debcheck/> [2]: <http://qa.ubuntuwire.com/ftbfs/> [3]: <http://revu.ubuntuwire.com/> [4]: <https://bugs.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs> signature.asc Description: This is a digitally signed message part. -- 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 Call for Volunteers
On Fri, Jul 31, 2009 at 1:14 PM, Steve Stalcup wrote: > I [1,2] would like to volunteer for this opening. The week is now up. Steve Stalcup (vorian) was the only person to volunteer for this position. No comments and/or criticisms were made. It is my honor to welcome Steve to the motu-release team. I know that Steve will do a great job with helping us during this and future releases. Welcome to the team Steve! Sincerely, Nathan Handler -- 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 Call for Volunteers
On Friday 31 July 2009 15:14:36 Steve Stalcup wrote: > I [1,2] would like to volunteer for this opening. +1 from me[1] too. First hand experience of quality management from vorian of our KDE releases multiple times this spring. /Andreas [1] https://launchpad.net/~andreas-wenning -- ,-¤. Kubuntu Linux ¤; http://www.kubuntu.org `-¤' Linux for Human Beings -- 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 Call for Volunteers
I am not a MOTU, but I can warmly recommend Steve. He has helped me with packaging problems several times and manages KDE packaging very professional. Regards Christian -- neversfe...@jabber.neversfelde.de neversfelde on irc.freenode.net signature.asc Description: This is a digitally signed message part. -- 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 Call for Volunteers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jul 31, 2009 at 1:14 PM, Steve Stalcup wrote: > I [1,2] would like to volunteer for this opening. +1 from me too. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKc1W5AAoJECM1+z85M6fOGxIIAJpPR2/ui/oCji5m9ytQ0ZXD B03pl1tiOh/rTybAHFcBm9CyK8KU6vTqntPV2FZ0DcONoHEqpAGpeqCMtvkuou6d 9wxJq+XPMNyHqp/7LFo+HiXWUt2JCWOoQut3xf6lGWzF0o/vwOIrMeSNp3oDc9PJ mi4v4/xlAJo6MTJJRHvryJHuF8VsKt9ArO5LYyZP+/E492yt5vhAMCnUHd5vT/O0 ede1Q/P8k8oljjXd6nojk3S3VvmojBWoz6D+5txcyIoIhhU+pGUH2KE3yOA7FRLk pTYvULjfWXHtrBia0GIBZkJHefqlvFAR35m9onZH2cInojpfoNhapgMyrawLqTw= =yBp0 -END PGP SIGNATURE- -- 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 Call for Volunteers
On Fri, 31 Jul 2009 09:14:36 -0400 Steve Stalcup wrote: ... >I [1,2] would like to volunteer for this opening. > +1 from me. Scott K -- 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 Call for Volunteers
On Thursday 30 July 2009 10:54:59 am Nathan Handler wrote: > Hello Ubuntu Developers, Hi > If you are an Ubuntu Developer who feels that > you would be capable of managing the packages in universe and multiverse in > order to ensure they are in good condition for the release, coordinating > packaging and quality assurance efforts for a wide range of packages, and > serving as a liaison between the MOTU community and the Ubuntu release > managers to coordinate package uploads and new features throughout the > various stages of the release schedule, I [1,2] would like to volunteer for this opening. -- Steve Stalcup vor...@ubuntu.com [1]https://wiki.ubuntu.com/StephenStalcup [2]https://launchpad.net/~vorian signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
MOTU Release Call for Volunteers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Ubuntu Developers, First, thanks a lot Luca for all of the time that you put into the MOTU Release team. You were a big help, and you will be missed. Now, without Luca, the MOTU Release team only has four members [1]. With Feature Freeze [2] fast approaching [3], it would be nice to have a full team of five members. We will be following the MOTU Key Team Policy [4] in order to fill the opening. If you are an Ubuntu Developer who feels that you would be capable of managing the packages in universe and multiverse in order to ensure they are in good condition for the release, coordinating packaging and quality assurance efforts for a wide range of packages, and serving as a liaison between the MOTU community and the Ubuntu release managers to coordinate package uploads and new features throughout the various stages of the release schedule, then please follow the steps outlined in the Key Team Policy in order to submit your application. Thanks, Nathan Handler On behalf of the MOTU release team [1] https://launchpad.net/~motu-release/+members [2] https://wiki.ubuntu.com/FeatureFreeze [3] https://wiki.ubuntu.com/KarmicReleaseSchedule [4] https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKcbPbAAoJECM1+z85M6fOt24H/iCIegesjB0GcD0FZbZBotbB znjhay1aYCM/MiYbxzDtfIbFdslqiHHNZiT1r00ubev3S6Y+V+ZKyIY3YyDHySQN nsIdiJsOlYzcFML4d1oS6ISp+NNHbiI3LJzrbJ/wXuOgGf2CAZx5cqP8r0hPcoEa svHqAjAXIlYmu2Fk0nSOXcajLuJiapAb1f76bb+YADUaYJGWPYFgfqsysRpfnbgQ WI4M2uMVQksXJ+tKDGkpaxD9la/YKqG3jpTqLnkOTymHLCWQdF/oeOP7FjlNjjf2 LWNbWyvGbBzMPihUH7iRGf9rJW1qJCUyT0OUUIRyf3rVNdmmNMwTUCpTz4eoPZI= =LpH6 -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Resigning from motu-release and sponsor queue admins
Hi Luca, Am Tuesday 07 July 2009 19:11:30 schrieb Luca Falavigna: > Hello, > > I decided to resign from motu-release and ubuntu-universe-sponsors queue > administrator teams due to time constraints. These two roles require > much attention than the one I can give to them right now. That's sad to hear, and I can only chime in to thank you for your excellent work! You'll definitely be missed by the teams! Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Resigning from motu-release and sponsor queue admins
On Wed, Jul 08, 2009 at 05:23:20AM EST, Nathan Handler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Jul 7, 2009 at 5:11 PM, Luca Falavigna wrote: > > I decided to resign from motu-release and ubuntu-universe-sponsors queue > > administrator teams due to time constraints. These two roles require > > much attention than the one I can give to them right now. > > You did a great job in both of those jobs Luca. Although I am sad to > see you resign, > I understand your reason. Thanks a lot for all of the time you have devoted to > motu-release and to ubuntu-universe-sponsors. > > > If you want to contribute, please nominate yourself as per > > https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy > > Please correct me if I am wrong, but I believe that the KeyTeamPolicy in this > case, only applies to the vacant motu-release position. The vacant > administrator > slot for ubuntu-universe-sponsors does not apply. I would assume that > it would be > up to Emmet Hikory and Luke Yelavich to decide if they want to fill the > vacancy, > and if so, how to go about doing it. I think we do need someone else, particularly to cover the europe/early US timezones, as Emmet and my self are somewhat similar in our timezones. I currently don't have any ideas as to how we could elect someone else, but Emmet may be able to chime in here. Luke -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Resigning from motu-release and sponsor queue admins
2009/7/7 Luca Falavigna > Hello, > Hello Luca > > I decided to resign from motu-release and ubuntu-universe-sponsors queue > administrator teams due to time constraints. These two roles require > much attention than the one I can give to them right now. > > I would like to thank existing and former team members for their job and > for the work done together. You ROCK! > > If you want to contribute, please nominate yourself as per > https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy > > I am sad to see that you've decided to resign from both motu-release and ubuntu-universe-sponsors. All I can say is that you did an awesome job. Working together with you was always a very great feeling and I am happy that I had the opportunity to work with you in such a wonderful team. Thank you and keep up the good work! Cheers! -- Iulian Udrea iul...@ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Resigning from motu-release and sponsor queue admins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jul 7, 2009 at 5:11 PM, Luca Falavigna wrote: > I decided to resign from motu-release and ubuntu-universe-sponsors queue > administrator teams due to time constraints. These two roles require > much attention than the one I can give to them right now. You did a great job in both of those jobs Luca. Although I am sad to see you resign, I understand your reason. Thanks a lot for all of the time you have devoted to motu-release and to ubuntu-universe-sponsors. > If you want to contribute, please nominate yourself as per > https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy Please correct me if I am wrong, but I believe that the KeyTeamPolicy in this case, only applies to the vacant motu-release position. The vacant administrator slot for ubuntu-universe-sponsors does not apply. I would assume that it would be up to Emmet Hikory and Luke Yelavich to decide if they want to fill the vacancy, and if so, how to go about doing it. Thanks again for all of your hard work Luca. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKU6ClAAoJECM1+z85M6fOzEQIANGjROk3v2At1F9WGgKEUPoa v8Sc4BpraeaimQy7CivyXNBLAV1/eTpNUCAGzfNQHWv+/3pTDhTjilCKNe5RIHDI vOh955PmGVQfPnVq+fZizc/f3WlgVXvczGsfqP/08w6s0SQk/rwK5i/UpgJcF0K6 dD2OJuV7VuyOjjD7CHM4sg8fTzQNby85B9iAlOrP1xmTm70iTgDZWp3+oMqp7+h6 xpLNpLudbuM935e3I47UMPAgSbIkUJC+f+CjJTnasszuBGnYczZWAqSuyQznQolQ B97lA07ZSjUXwddHyDH87oY3gisCt1zYHqaoSZ7em00SKi8tWLHy/9sOIQ/26Ms= =+oIa -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Resigning from motu-release and sponsor queue admins
Hello, I decided to resign from motu-release and ubuntu-universe-sponsors queue administrator teams due to time constraints. These two roles require much attention than the one I can give to them right now. I would like to thank existing and former team members for their job and for the work done together. You ROCK! If you want to contribute, please nominate yourself as per https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy Thank you! -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: PGP signature -- 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 Charter
On Wed, 2009-03-25 at 10:11 +0100, Luca Falavigna wrote: > > Also, Universe and Multiverse aren't "sections", they are "components". > > dak call them "sections", does Ubuntu archive use a different naming? Sections are "x11", "python", etc. http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections Debian policy calls "main", "contrib" and "non-free" "areas", but I thought we called universe etc. "components". > > I'm unsure about this point. We don't really have targeted goals for > > MOTU as a whole, except for things like few FTBFS. I also haven't seen > > much co-ordination of QA activities from motu-release. Have I missed > > them? If not, what has been stopping this from happening? > > > > Also, aren't QA activities the purview of the QA team? If motu-release > > would like to be involved with that then should this be as a liason with > > the QA team? > > There are several: FTBFS, NBS, transitions, and so on. Probably they are > not "plain QA" but more about "archive consistency". We followed several > transitions in the past, trying to get them finished in a reasonable > time, do you think we should document better their status? (something > like "Bits from motu-release" emails, like Debian teams do). I think more communication would be good, yes. Aside from that if the activities you refer to are about archive consistency, then perhaps it is better to talk about that in the charter? > >> motu-release or one of their delegates will review all Feature Freeze > >> exceptions requested for packages in the Universe or Multiverse > >> repositories, which introduce new features or substantial changes > >> after FeatureFreeze in order to weigh the potential impact of the > >> proposed changes on the rest of the distribution. > >> > > "delegates" hasn't been defined at all, does that need to be in the > > charter? If it's just an implementation detail then they shouldn't be > > mentioned here either. > > I think so. We assign some packages which belong to a given domain > (GNOME, KDE, Mozilla, and so on) to a delegate who has great knowledge > of packaging policies and infrastructure. We ask them to accept the role > and then send out a email to announce them. They contribute to the > motu-release team, so this should be documented. OK, so I think delegates should be defined elsewhere, and their role given there, rather than including it in this paragraph. > > Also, is this a power? I can review all feature freeze exceptions if I > > like. The power seems to be in forcing FFes to be requested at all, and > > being able to reject them. > > > > It seems like this paragraph should be written as to grant motu-release > > the power to request and reject freeze exception requests after a > > certain point. motu-release can then define what point that is and what > > requires a request, as you do now. > > It's not about power, but responsibility. I think we have not the > "power" to block anything, but we give advice on what could be fine from > a safe release POV. This seems odd to me. This paragraph was placed in the "Powers" section, and I do see it as a sort of power. While I could request that everyone contact me before uploading everything, I don't think it would actually happen. If you feel that it is a responsibility then move the paragraph in to that section. > >> Ubuntu developers will not upload a new source package and archive > >> administrators will not accept any package uploaded after > >> FeatureFreeze without a Feature Freeze exception from motu-release or > >> one of it's delegates (having been discussed at the UDS or providing a > >> required feature are reasonable arguments for a feature freeze > >> exception, but do not remove the need for an exception). > >> > > This seems related to the last. > > Some people don't consider a NEW package as a feature, stating so we > state it clearly. OK. > > Also, I'm not sure that talking about UDS here is appropriate. > > Why not? Suppose I had a talk at UDS about a given feature, it is > considered important and accepted for the release. I expect it could > enter without much trouble (according to release schedule timings). It seems to me that your policy on accepting or not a given request shouldn't be documented in the charter, unless it is crucial to the functioning of motu-release. This occurs at a few points in the document. If you would like to record thing
Re: MOTU Release Charter
On Thu, 2009-03-19 at 18:16 -0400, Scott Kitterman wrote: > During the Intrepid cycle the MOTU release team members were asked to come up > with a charter for the team. It's taken us some time to get a draft > together, but this: > > https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter I have some comments on the draft charter. Some are stylistic, and some are related to the content. > motu-release members manage each Ubuntu release for those packages > which belong to the Universe and Multiverse sections of the Ubuntu > archive, trying to have them in a good shape for the release. > "trying to have them in a good shape for the release" is a rather limp phrase in my opinion. Surely this statement is the most crucial of the whole document, as it is the main purpose of the release team. It currently sounds like it is talking about lots of individual packages, rather than a distribution. Having universe in the best state possible for release should be the aim in my opinion, which is slightly different to trying to get each individual package in to its best state. Also, Universe and Multiverse aren't "sections", they are "components". > motu-release members coordinate packaging and quality assurance > efforts for a wide range of packages, working together with interested > developers to reach targeted goals. I'm unsure about this point. We don't really have targeted goals for MOTU as a whole, except for things like few FTBFS. I also haven't seen much co-ordination of QA activities from motu-release. Have I missed them? If not, what has been stopping this from happening? Also, aren't QA activities the purview of the QA team? If motu-release would like to be involved with that then should this be as a liason with the QA team? "A wide range of packages" seems out of place, if the intent is to state that you will co-ordinate QA activities that touch on large numbers of packages then I believe that should be stated, rather than the ambiguity implied by that statement. > motu-release members are a liaison between the MOTU community and > Ubuntu release managers to coordinate package uploads and new features > throughout the various stages of the release schedule. > I would say that you co-ordinate the inclusion of new features, rather than the features themselves. > motu-release transitions upload decisions to motu-sru at the time of > release. In order to meet motu-release goals it may be necessary to > authorize pre-release SRU uploads. motu-release will hand these over > to motu-sru and assist with their verification and movement from > *-proposed to *-updates. > I think the first part should rather be phrased as a grant of a power, "motu-release is allowed to authorize pre-release SRU uploads where it allows them to further their work on improving the release. motu-release will then assist motu-sru with completing the SRU process for these uploads". > motu-release or one of their delegates will review all Feature Freeze > exceptions requested for packages in the Universe or Multiverse > repositories, which introduce new features or substantial changes > after FeatureFreeze in order to weigh the potential impact of the > proposed changes on the rest of the distribution. > "delegates" hasn't been defined at all, does that need to be in the charter? If it's just an implementation detail then they shouldn't be mentioned here either. Also, is this a power? I can review all feature freeze exceptions if I like. The power seems to be in forcing FFes to be requested at all, and being able to reject them. It seems like this paragraph should be written as to grant motu-release the power to request and reject freeze exception requests after a certain point. motu-release can then define what point that is and what requires a request, as you do now. > Ubuntu developers will not upload a new source package and archive > administrators will not accept any package uploaded after > FeatureFreeze without a Feature Freeze exception from motu-release or > one of it's delegates (having been discussed at the UDS or providing a > required feature are reasonable arguments for a feature freeze > exception, but do not remove the need for an exception). > This seems related to the last. Also, I'm not sure that talking about UDS here is appropriate. > motu-release will work with Ubuntu developers and contributors in > order to coordinate efforts to complete library transitions and the > addition of new packages once a Feature Freeze exception has been > granted for them. > Is this a power? It seems like a duty to me, unless we have to work with motu-release, and can't just do it on our own if we like. "inclusion of new packages" seems better than "addit
Re: MOTU Release Charter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First of all, thanks Jordan for your questions. Jordan Mantha ha scritto: >> Post FF if someone wants to start a library transition it ought to have an >> FFe from motu-release. This is how we've operated for some time and nothing >> new (I don't think). This is one area where motu-release does report to the >> Ubuntu Release team at the regular release team meetings. > > Right, so it didn't seem quite clear to me what defines a transition? > does say 3 packages constitute a transition? do we just use common > sense there? It was also not clear in the wording that motu-release is > only involved post FF. I think so. Package transitions require work by archive-admins to process binary NEW, by developers to manage rebuilds and make sure everything is fine with new library. This requires more time than a single, standalone upload. Changing SONAMEs is something like a new feature to me. Most of the times there are just ABI bump, where a rebuild is enough, but it's better to check with motu-release to make sure to be able to complete the transition in time according to release schedule. - -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknDUxcACgkQnXjXEYa8KlC8yACdF+KBUFYVgQNEDk/qAgKAhGyt m4kAn2Ah/YvYvghrOrDJNzg+zu8NYzvI =ZWBl -END PGP SIGNATURE- -- 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 Charter
On Thu, 19 Mar 2009 17:06:53 -0700 Jordan Mantha wrote: >On Thu, Mar 19, 2009 at 4:44 PM, Scott Kitterman wrote: >> On Thu, 19 Mar 2009 16:18:46 -0700 Jordan Mantha wrote: >>>On Thu, Mar 19, 2009 at 3:16 PM, Scott Kitterman wrote: >>>> During the Intrepid cycle the MOTU release team members were asked to come up >>>> with a charter for the team. It's taken us some time to get a draft >>>> together, but this: >>>> >>>> https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter >>> >>>Thanks to the MOTU Release team for all the work they've put into this charter. >>> >>>I don't have any major problems with the charter but I have a couple questions: >>> >>> * is the consultation with the doc team upon UI Freeze only for >>>seeded packages as well? I wasn't totally clear on that one. >> >> It's my understanding (from discussions with ubuntu-release) that U/I freeze only affects seeded packages. > >That makes sense and is what I assumed, but wasn't *exactly* sure so I >thought I'd ask. > >>> * "targeted goals" and "motu-release goals" are mentioned. Does that >>>mean MOTU Release will define and publish release goals? >> >> This is something that I think we have never done. I would say yes, but I'm not sure exactly how it would work. I have, as the Server Team delegate, approved FFe (as recently as today) based on the Server release goal of supporting cloud computing. >> >> I think that exactly how a Universe release goal would get proposed/accepted is something we need to figure out. Personally, I don't think it needs to be defined in the charter. > >I agree that the charter is probably not a place to discuss how we get >release goals, but I think it helps people see the basis for MOTU >Release decisions and gives a better idea of where we're heading if we >do have some defined/published release goals. I'm generically in favor of MOTU release goals that motu-release would help coordinate/facilitate. Personally I've always come up empty when I try to think up what they might be. >>> * somewhat similar to the previous question, I see mentions of >>>"transitions". Is is MOTU Release going to define and/or accept >>>transitions? >> >> Post FF if someone wants to start a library transition it ought to have an FFe from motu-release. This is how we've operated for some time and nothing new (I don't think). This is one area where motu-release does report to the Ubuntu Release team at the regular release team meetings. > >Right, so it didn't seem quite clear to me what defines a transition? >does say 3 packages constitute a transition? do we just use common >sense there? It was also not clear in the wording that motu-release is >only involved post FF. I can't envision what a non-feature library transition would be. If it's not clear it's only post-FF, then we ought to adjust it. If you've proposed wording, I'd suggest put it in the wiki page. >Again, all this is just clarification of the language, I've got no >problems with the spirit of the Charter. > Glad to hear it. Scott K -- 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 Charter
On Thu, Mar 19, 2009 at 4:44 PM, Scott Kitterman wrote: > On Thu, 19 Mar 2009 16:18:46 -0700 Jordan Mantha wrote: >>On Thu, Mar 19, 2009 at 3:16 PM, Scott Kitterman wrote: >>> During the Intrepid cycle the MOTU release team members were asked to come >>> up >>> with a charter for the team. It's taken us some time to get a draft >>> together, but this: >>> >>> https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter >> >>Thanks to the MOTU Release team for all the work they've put into this >>charter. >> >>I don't have any major problems with the charter but I have a couple >>questions: >> >> * is the consultation with the doc team upon UI Freeze only for >>seeded packages as well? I wasn't totally clear on that one. > > It's my understanding (from discussions with ubuntu-release) that U/I freeze > only affects seeded packages. That makes sense and is what I assumed, but wasn't *exactly* sure so I thought I'd ask. >> * "targeted goals" and "motu-release goals" are mentioned. Does that >>mean MOTU Release will define and publish release goals? > > This is something that I think we have never done. I would say yes, but I'm > not sure exactly how it would work. I have, as the Server Team delegate, > approved FFe (as recently as today) based on the Server release goal of > supporting cloud computing. > > I think that exactly how a Universe release goal would get proposed/accepted > is something we need to figure out. Personally, I don't think it needs to be > defined in the charter. I agree that the charter is probably not a place to discuss how we get release goals, but I think it helps people see the basis for MOTU Release decisions and gives a better idea of where we're heading if we do have some defined/published release goals. >> * somewhat similar to the previous question, I see mentions of >>"transitions". Is is MOTU Release going to define and/or accept >>transitions? > > Post FF if someone wants to start a library transition it ought to have an > FFe from motu-release. This is how we've operated for some time and nothing > new (I don't think). This is one area where motu-release does report to the > Ubuntu Release team at the regular release team meetings. Right, so it didn't seem quite clear to me what defines a transition? does say 3 packages constitute a transition? do we just use common sense there? It was also not clear in the wording that motu-release is only involved post FF. Again, all this is just clarification of the language, I've got no problems with the spirit of the Charter. -Jordan -- 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 Charter
On Thu, 19 Mar 2009 16:18:46 -0700 Jordan Mantha wrote: >On Thu, Mar 19, 2009 at 3:16 PM, Scott Kitterman wrote: >> During the Intrepid cycle the MOTU release team members were asked to come up >> with a charter for the team. It's taken us some time to get a draft >> together, but this: >> >> https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter > >Thanks to the MOTU Release team for all the work they've put into this charter. > >I don't have any major problems with the charter but I have a couple questions: > > * is the consultation with the doc team upon UI Freeze only for >seeded packages as well? I wasn't totally clear on that one. It's my understanding (from discussions with ubuntu-release) that U/I freeze only affects seeded packages. > * "targeted goals" and "motu-release goals" are mentioned. Does that >mean MOTU Release will define and publish release goals? This is something that I think we have never done. I would say yes, but I'm not sure exactly how it would work. I have, as the Server Team delegate, approved FFe (as recently as today) based on the Server release goal of supporting cloud computing. I think that exactly how a Universe release goal would get proposed/accepted is something we need to figure out. Personally, I don't think it needs to be defined in the charter. > * somewhat similar to the previous question, I see mentions of >"transitions". Is is MOTU Release going to define and/or accept >transitions? Post FF if someone wants to start a library transition it ought to have an FFe from motu-release. This is how we've operated for some time and nothing new (I don't think). This is one area where motu-release does report to the Ubuntu Release team at the regular release team meetings. For this cycle the ghc6 transition (which was totally in Universe) that was in progress at FF and the Python transition that we've inherited from Main have both been distro level interest items. Scott K -- 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 Charter
On Thu, Mar 19, 2009 at 3:16 PM, Scott Kitterman wrote: > During the Intrepid cycle the MOTU release team members were asked to come up > with a charter for the team. It's taken us some time to get a draft > together, but this: > > https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter Thanks to the MOTU Release team for all the work they've put into this charter. I don't have any major problems with the charter but I have a couple questions: * is the consultation with the doc team upon UI Freeze only for seeded packages as well? I wasn't totally clear on that one. * "targeted goals" and "motu-release goals" are mentioned. Does that mean MOTU Release will define and publish release goals? * somewhat similar to the previous question, I see mentions of "transitions". Is is MOTU Release going to define and/or accept transitions? -Jordan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
MOTU Release Charter
During the Intrepid cycle the MOTU release team members were asked to come up with a charter for the team. It's taken us some time to get a draft together, but this: https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter is something all current members of the team are happy with. It is still draft because it's up to MOTU to decide what it is we are to do. The draft just captures our understanding of the (previously undocumented) role the MOTU release team is supposed to play. I would encourage all of you to read and consider it and then make comments on the MOTU ML. This should be reviewed on the list, taken to the most reasonable MOTU meeting (I'm guessing the next one) for discussion, and then approved afterwards. Currently it does not appear one is scheduled: https://wiki.ubuntu.com/MOTU/Meetings I don't expect to take a strong role in this discussion (speaking for myself only). Motu-release is here to act for MOTU, so you tell us if this is the right job description or not. Scott Kitterman -- 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 team needs members
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan Handler ha scritto: > I would like to apply to become the 5th member of the motu-release team. I second Nathan's application. Regards, - -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmacfwACgkQnXjXEYa8KlA74wCdEnc100AfnCfZLBNRhoo0zmCI eG8AoI+9pvE33zn94lZuo1xxn1blFp77 =1vRX -END PGP SIGNATURE- -- 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 team needs members
Hi, On Fri, Feb 13, 2009 at 04:25:45AM +, Nathan Handler wrote: [..] > Hello, > > I [1] would like to apply to become the 5th member of the motu-release > team. I filed many Freeze Exception requests during the last release > cycle, and I understand the impact upgrades can have. I also have > devoted a lot of time to reviewing patches, merge/sync requests, and > new packages on REVU. Several times, these reviews have ended with me > telling the contributor that the patch/merge/sync/package is not > appropriate for Ubuntu. As a result of this, I do not think that I > will have any problems with rejecting freeze exceptions. I also have > plenty of experience carefully reviewing changelog entries and > debdiffs from the sponsoring/reviewing I have done. For these reasons, > I feel I possess all of the qualities necessary to be a members of the > motu-release team. I second the application. Cheers, Stefan. signature.asc Description: Digital signature -- 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 team needs members
On Fri, Feb 13, 2009 at 8:08 AM, Luca Falavigna wrote: > We scheduled a motu-release meeting on Monday 16, 19 UTC. Could you > attend it to discuss a bit about your candidature? Thanks in advance! I think I should be able to make that meeting. Nathan -- 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 team needs members
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan Handler ha scritto: > I would like to apply to become the 5th member of the motu-release team. We scheduled a motu-release meeting on Monday 16, 19 UTC. Could you attend it to discuss a bit about your candidature? Thanks in advance! Regards, - -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVKokACgkQnXjXEYa8KlAjsACgiMhNxqFRUT7c9qWdvhG3V0w2 AOMAoINlznnTO2SJVdsDH5Sc13tymoWU =Asqh -END PGP SIGNATURE- -- 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 team needs members
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Feb 10, 2009 at 9:27 PM, Stefan Potyra wrote: > Hi, > > thanks to Iulian, we're back at 4 members right now. Maybe someone is > still interested in becoming the 5th member, so that we'd be back at > full strength for jaunty's freeze? Hello, I [1] would like to apply to become the 5th member of the motu-release team. I filed many Freeze Exception requests during the last release cycle, and I understand the impact upgrades can have. I also have devoted a lot of time to reviewing patches, merge/sync requests, and new packages on REVU. Several times, these reviews have ended with me telling the contributor that the patch/merge/sync/package is not appropriate for Ubuntu. As a result of this, I do not think that I will have any problems with rejecting freeze exceptions. I also have plenty of experience carefully reviewing changelog entries and debdiffs from the sponsoring/reviewing I have done. For these reasons, I feel I possess all of the qualities necessary to be a members of the motu-release team. Thanks, Nathan Handler (nhandler) [1] https://launchpad.net/~nhandler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmU9hIACgkQS7NiVFf3leiFXACdExXzEADqYq1SVcJ/laNf4Ot2 EH0Anih9GnTHK5x2JqlhW0BBFfXtpwNu =WI2r -END PGP SIGNATURE- -- 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 meeting Feb 3rd - very short minutes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Potyra ha scritto: > * DktrKranz to take a stab at drafting a motu-release policy. A first, short draft is available here: https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter Regards, - -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmR+ywACgkQnXjXEYa8KlC5UwCfRpNmE865ms/rzE0dB41GHp6j /fcAoKs6klecEUWEpY2fOVSm+g9naztJ =FCH3 -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
motu-release meeting Feb 3rd - very short minutes
Hi folks, just a short heads up, sorry that I didn't come around to write a few points of the results of the meeting yet. So here a few points we discussed. Please refer to the full log, in case you're interested in getting the full picture at [1]. 1) grilling Iulian first off, after the call for volunteers, Iulian was the victim to become a member of motu-release. Questions were asked and Iulian answered them all to our consent [and he's a member of motu-release in the meantime]. 2) bi-weekly ubuntu-release meetings: Scottk brought this up, and thought it would be good if a motu-release person would be there (luckily, ScottK fullfilled this quite good last release and volunteered to do the same for jaunty -- of course other members are invited, too!) 3) new packages: We'll take a harder policy in regrads to NEW this time, so bring in your pet package before FF, otherwise we'll just say NO! other items of action: * DktrKranz to take a stab at drafting a motu-release policy. * sistpoty to review motu-release delegations. * DktrKranz to book ubuntu-meeting for next meeting [already done]. Finally, next organisational meeting will take place on Monday 16th - 19:00 UTC, #ubuntu-meeting. Cheers, Stefan. -- [1]: <http://irclogs.ubuntu.com/2009/02/03/%23ubuntu-meeting.html> -- 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 team needs members
Hi, thanks to Iulian, we're back at 4 members right now. Maybe someone is still interested in becoming the 5th member, so that we'd be back at full strength for jaunty's freeze? Quoting myself: > If you know the impact of upgrades at late stages, don't shy away from > reading > changelogs and patches, also have the ability to make unliked decisions like > rejecting freeze exceptions, then motu-release needs you. Please send in your > application as reply to this thread. Oh, and being a MOTU is required. Side-word: Imho we could also need bug-triagers that help with looking at and sorting incomplete FFe requests, or to ping FFe requestors after some time of inactivity... Is this the right list to ask for those? (If not, please bounce to the correct location). Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Iulian Udrea accepted as a MOTU Release Member
Fellow Developers, As an administrator of the MOTU Release team, I have added Iulian Udrea as a member, as there is a valid uncontested application that has completed the required discussion time, according to the agreed process (0). Application: https://lists.ubuntu.com/archives/ubuntu-motu/2009-January/005350.html Endorsements: Luca Falavigna: https://lists.ubuntu.com/archives/ubuntu-motu/2009-February/005389.html Stefan Potya: https://lists.ubuntu.com/archives/ubuntu-motu/2009-February/005390.html Scott Kitterman: https://lists.ubuntu.com/archives/ubuntu-motu/2009-February/005391.html Siegfried-Angel Gevatter Pujals: https://lists.ubuntu.com/archives/ubuntu-motu/2009-February/005395.html 0: https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy -- Emmet HIKORY -- 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 team needs members
Soyer Jerome wrote: > and me :-) > > Build and Maintain an Ubuntu every day for French Education > (http://eole.orion.education.fr/) > > I'm responsible of package building, and CD/DVD building. Jerome. Thanks for your interest in joining the MOTU Release team. This team is restricted to currently active MOTU, so this application will not be considered for processing. If you later become MOTU, and remain interested in working with the MOTU Release team, please do consider applying at that time. -- Emmet HIKORY -- 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 team needs members
2009/2/4 Siegfried-Angel : > And me :). In case it wasn't clear, that's an "I also second Iulian's application". -- Siegfried-Angel Gevatter Pujals (RainCT) Ubuntu Developer. Debian Contributor. -- 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 team needs members
and me :-) Build and Maintain an Ubuntu every day for French Education ( http://eole.orion.education.fr/) I'm responsible of package building, and CD/DVD building. -- Jérôme Soyer aka saispo 2009/2/4 Siegfried-Angel > And me :). > > -- > Siegfried-Angel Gevatter Pujals (RainCT) > Ubuntu Developer. Debian Contributor. > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- 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 team needs members
and me :-) Build and Maintain an Ubuntu every day for French Education ( http://eole.orion.education.fr/) I'm responsible of package building, and CD/DVD building. -- Jérôme Soyer aka saispo 2009/1/28 Stefan Potyra > Hi, > > first of all thanks a lot, Cesare, for your efforts within the motu-release > team! > > Now looking that [1], I see that we've only 3 members left, so I guess > motu-release could need at least one or better yet two more members. > > Now I completely forgot what the policy to add more members to key teams > was, > but I vaguely recall that it started with asking for applicants on this > list. > So that's what I'm doing right now. > > If you know the impact of upgrades at late stages, don't shy away from > reading > changelogs and patches, also have the ability to make unliked decisions > like > rejecting freeze exceptions, then motu-release needs you. Please send in > your > application as reply to this thread. > > Thanks, > Stefan. > -- > [1]: > <https://launchpad.net/~motu-release/+members<https://launchpad.net/%7Emotu-release/+members> > > > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > > -- 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 team needs members
And me :). -- Siegfried-Angel Gevatter Pujals (RainCT) Ubuntu Developer. Debian Contributor. -- 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 team needs members
On Wed, 4 Feb 2009 12:08:49 +0100 Stefan Potyra wrote: >Hi, > >On Wednesday 04 February 2009 12:02:43 Luca Falavigna wrote: >> Iulian Udrea ha scritto: >> > I would like to join the MOTU Release team, so please consider this >> > my application to become a MOTU Release member. >> >> I second Iulian's application. > >I also second Iulian's application. > /me three. Scott K -- 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 team needs members
Hi, On Wednesday 04 February 2009 12:02:43 Luca Falavigna wrote: > Iulian Udrea ha scritto: > > I would like to join the MOTU Release team, so please consider this > > my application to become a MOTU Release member. > > I second Iulian's application. I also second Iulian's application. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- 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 team needs members
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Iulian Udrea ha scritto: > I would like to join the MOTU Release team, so please consider this > my application to become a MOTU Release member. I second Iulian's application. Regards, - -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmJddMACgkQnXjXEYa8KlAcRwCgsHhKvSFPHTaufKP3ZMLAArjv zw4An00a7tH6VjyRJvMSdtIS1FtuoIjK =OYjr -END PGP SIGNATURE- -- 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 team needs members
2009/1/28 Stefan Potyra > Hi, > Hello > Now looking that [1], I see that we've only 3 members left, so I guess > motu-release could need at least one or better yet two more members. > I would like to join the MOTU Release team, so please consider this my application to become a MOTU Release member. My name is Iulian Udrea and I'm seventeen year old. I am both an Ubuntu and a FOSS Developer. Before I got the MOTU status I was interested in working with the MOTU release team. Now that I am a MOTU I would like to give a hand and work with the MOTU Release. In two release cycles I saw how the team really work, how they deal with bug fixes, new upstream releases and so forth. I read [0] and everything is understood, I have no questions about it. Launchpad page: https://launchpad.net/people/iulian Wiki page: https://wiki.ubuntu.com/IulianUdrea [0] https://wiki.ubuntu.com/FreezeExceptionProcess Thank you for your consideration. -- Iulian Udrea iul...@ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: R: motu-release organisational meeting
norse...@alice.it wrote: > Unfortunately, I'm rather busy at the moment and won't be able to > contribute much for this (and I'm afraid also next) release, certainly > not as a motu-release member. Please remove me from the team, if any > volunteer want to step in to fill the post please do so. Thank you for your past work to help ensure the quality of the previous releases. I've removed you from the team in launchpad, and updated the MOTU Leaders wiki page. -- Emmet HIKORY -- 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 team needs members
Stefan Potyra wrote: > Now I completely forgot what the policy to add more members to key teams was, > but I vaguely recall that it started with asking for applicants on this list. > So that's what I'm doing right now. The policy for membership in motu-release is detailed in the wiki (1). A call for applications is indeed the first step when a team is undersized. 1: https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
motu-release team needs members
Hi, first of all thanks a lot, Cesare, for your efforts within the motu-release team! Now looking that [1], I see that we've only 3 members left, so I guess motu-release could need at least one or better yet two more members. Now I completely forgot what the policy to add more members to key teams was, but I vaguely recall that it started with asking for applicants on this list. So that's what I'm doing right now. If you know the impact of upgrades at late stages, don't shy away from reading changelogs and patches, also have the ability to make unliked decisions like rejecting freeze exceptions, then motu-release needs you. Please send in your application as reply to this thread. Thanks, Stefan. -- [1]: <https://launchpad.net/~motu-release/+members> signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: R: motu-release organisational meeting
Hi Cesare, On Wednesday 28 January 2009 11:41:32 norse...@alice.it wrote: > Unfortunately, I'm rather busy at the moment and won't be able to > contribute much for this (and I'm afraid also next) release, certainly not > as a motu-release member. Please remove me from the team, if any volunteer > want to step in to fill the post please do so. That's sad to hear. So the meeting is scheduled for Tuesday, February 3rd, 14.00 UTC. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
R: motu-release organisational meeting
Unfortunately, I'm rather busy at the moment and won't be able to contribute much for this (and I'm afraid also next) release, certainly not as a motu-release member. Please remove me from the team, if any volunteer want to step in to fill the post please do so. Cheers, norsetto -Messaggio originale- Da: ubuntu-motu-boun...@lists.ubuntu.com per conto di Stefan Potyra Inviato: mar 27/01/2009 12.58 A: ubuntu-motu@lists.ubuntu.com Oggetto: motu-release organisational meeting Hi motu-release members, with FeatureFreeze approaching at Feb 19, I guess it'd be good if we schedule an organisational meeting. What do you think? What date would suit you? Maybe this Friday, at 14.00h UTC? Cheers, Stefan. -- 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 organisational meeting
On Tue, 27 Jan 2009 15:05:14 +0100 Stefan Potyra wrote: >Hi, > >On Tuesday 27 January 2009 15:03:11 Luca Falavigna wrote: >> Stefan Potyra ha scritto: >> > What date would suit you? Maybe this Friday, at 14.00h UTC? >> >> Probably I'll be buried in office for that time, I'd rather prefer >> Tuesday, February 3rd at the same timeframe, but I'll try to be there >> anytime (I can't promise I can catch things quickly, though). > >Tuesday, Feb 3 would work for me as well. Others? > Should be fine for me. Scott K -- 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 organisational meeting
Hi, On Tuesday 27 January 2009 15:03:11 Luca Falavigna wrote: > Stefan Potyra ha scritto: > > What date would suit you? Maybe this Friday, at 14.00h UTC? > > Probably I'll be buried in office for that time, I'd rather prefer > Tuesday, February 3rd at the same timeframe, but I'll try to be there > anytime (I can't promise I can catch things quickly, though). Tuesday, Feb 3 would work for me as well. Others? Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- 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 organisational meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Potyra ha scritto: > What date would suit you? Maybe this Friday, at 14.00h UTC? Probably I'll be buried in office for that time, I'd rather prefer Tuesday, February 3rd at the same timeframe, but I'll try to be there anytime (I can't promise I can catch things quickly, though). - -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl/FB8ACgkQnXjXEYa8KlAGKwCfZbpxjByCts2a17MgBdYmmT9/ FTUAn2Y98a06HOJoacZu/GObephLJkJL =GoZ4 -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
motu-release organisational meeting
Hi motu-release members, with FeatureFreeze approaching at Feb 19, I guess it'd be good if we schedule an organisational meeting. What do you think? What date would suit you? Maybe this Friday, at 14.00h UTC? Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposal for motu-release charter
On Sat, Nov 01, 2008 at 12:14:53AM +0100, Stefan Potyra wrote: > Technically, there aren't any powers that motu-release has, that any > other developer doesn't have: motu-release cannot reject a new > upstream version while in FeatureFreeze, nor can we accept an uploaded > package while in deep freeze (that's left to archive-admins). a) There's a difference between being able to technically carry out certain actions and to have the power to authorise said actions. I think you should focus on the latter and perhaps in time let that form a basis for the former (if, say, the motu-release charter were to say that motu-release were to have sole power to authorise uploads during deep freeze, the archive admins could do their thing until such time when Launchpad might extend this ability to motu-release). b) I don't see the motu-release charter as an attempt to describe what motu-release *are* able/empowered to do, but what you'd like to propose that they *should* be able/empowered to do. This might turn out to be the same, but don't feel limited by the status quo if you find anything that you'd like to change. > Being within a team, however means that the general attitude towards > or against that team is perceived from a differnet point of view, and > (to my observations) is often misleading of what a team should do or > should not, or what the purpose of that team is. Certainly. That is why we've asked you to come up with the charter so that we can all discuss it and eventually bless it. > Hence I guess it would be a better idea to have other developers > propose a charter for motu-release. Maybe motu-council has a good > proposal? I would still like for the current motu-release team to come up with a proposal for their own charter, so that we can use that as a starting point for a discussion. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposal for motu-release charter
Stefan Potyra wrote: > Technically, there aren't any powers that motu-release has, that any other > developer doesn't have: motu-release cannot reject a new upstream version > while in FeatureFreeze, nor can we accept an uploaded package while in deep > freeze (that's left to archive-admins). Just a note about packages being uploaded in the deep freeze - the archive admins accept universe packages on the basis of what they're told by the MOTU release team, at least in the latter stages. ScottK and such did a great job in the weeks leading up to the Intrepid Ibex release, requesting certain packages be accepted/rejected, from #ubuntu-release. While you guys can't accept packages directly, you could by proxy, and it didn't seem to block people at all (from what I saw, anyway!) Hobbsee signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposal for motu-release charter
Hi, On Monday 27 October 2008 04:37:48 Emmet Hikory wrote: > Soren Hansen wrote: > > Dear motu-release! > > > > In order to reduce misunderstandings, the MC would like to request that > > you, motu-release, come up with a proposal for a charter for yourself. > > We'd like to be able to discuss and approve it at the next MOTU Meeting, > > if possible. > > It's been a while, and you've all been busy chasing the release. > Great job on handling the final transitions and getting the RCbugs > queue down to a manageable size for the SRU team. Thanks! > Now that there's a > little breathing space, would it be possible to revisit a charter and > bring it to a MOTU Meeting in the near future? Perhaps for the 14th > of November? I've been thinking quite long about this topic, and I must admit, that I didn't come to conclusion yet. Technically, there aren't any powers that motu-release has, that any other developer doesn't have: motu-release cannot reject a new upstream version while in FeatureFreeze, nor can we accept an uploaded package while in deep freeze (that's left to archive-admins). However I believe that motu-release has a social influence, i.e. if we'd reject a new upstream version, it would imply to developers or sponsors that they shouldn't upload it, and most probably won't do so. Same goes for the reverted upload of libgems-ruby. Being within a team, however means that the general attitude towards or against that team is perceived from a differnet point of view, and (to my observations) is often misleading of what a team should do or should not, or what the purpose of that team is. Hence I guess it would be a better idea to have other developers propose a charter for motu-release. Maybe motu-council has a good proposal? Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposal for motu-release charter
Soren Hansen wrote: > Dear motu-release! > > In order to reduce misunderstandings, the MC would like to request that > you, motu-release, come up with a proposal for a charter for yourself. > We'd like to be able to discuss and approve it at the next MOTU Meeting, > if possible. It's been a while, and you've all been busy chasing the release. Great job on handling the final transitions and getting the RCbugs queue down to a manageable size for the SRU team. Now that there's a little breathing space, would it be possible to revisit a charter and bring it to a MOTU Meeting in the near future? Perhaps for the 14th of November? -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: When does MOTU Release need to start approving every upload ...
Hi again, On Thursday 16 October 2008 12:41:53 Stefan Potyra wrote: [..] > > Would it be even possible to set universe/multiverse back to auto until > that time? sistpoty|work: Launchpad provides no facility to freeze just some components. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: When does MOTU Release need to start approving every upload ...
On Thu, 16 Oct 2008 12:41:53 +0200 Stefan Potyra <[EMAIL PROTECTED]> wrote: >Hi, > >On Thursday 16 October 2008 12:33:51 Cesare Tirabassi wrote: >> On Thu, 16 Oct 2008 06:17:35 -0400 >> >> Scott Kitterman <[EMAIL PROTECTED]> wrote: >> > Based on: >> > >> > https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html >> > >> > One might think it's now, but I propose this not start until the last >> > week before release (i.e. one more week from now). >> >> +1, one week before release is more than reasonable. > >that would be Oct 23rd? > >sounds like a good idea to me. > >Would it be even possible to set universe/multiverse back to auto until that >time? > No. It'll have to be like in the Beta freeze where everything needs a manual shove. That's a majority, so let's call that the rule. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: When does MOTU Release need to start approving every upload ...
Hi, On Thursday 16 October 2008 12:33:51 Cesare Tirabassi wrote: > On Thu, 16 Oct 2008 06:17:35 -0400 > > Scott Kitterman <[EMAIL PROTECTED]> wrote: > > Based on: > > > > https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html > > > > One might think it's now, but I propose this not start until the last > > week before release (i.e. one more week from now). > > +1, one week before release is more than reasonable. that would be Oct 23rd? sounds like a good idea to me. Would it be even possible to set universe/multiverse back to auto until that time? Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: When does MOTU Release need to start approving every upload ...
On Thu, 16 Oct 2008 06:17:35 -0400 Scott Kitterman <[EMAIL PROTECTED]> wrote: > Based on: > > https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html > > One might think it's now, but I propose this not start until the last > week before release (i.e. one more week from now). +1, one week before release is more than reasonable. C. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: When does MOTU Release need to start approving every upload ...
Scott Kitterman ha scritto: > Based on: > > https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html > > One might think it's now, but I propose this not start until the last week > before release (i.e. one more week from now). My opinion: I think uploads which does not require a FFe right now (bugfixes, archive cleanups, and so on) should be granted an "exception" until RC, after that deadline every upload should be ACKed by motu-release before leaving unapproved queue. FFe requests should be approved as usual. Regards, -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
When does MOTU Release need to start approving every upload ...
Based on: https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html One might think it's now, but I propose this not start until the last week before release (i.e. one more week from now). Comments (particularly from motu-release, but others welcome)? Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
New upstream releases freeze exception (was: Re: Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.)
Hi, Stefan Potyra wrote: >> Bugfix only releases: >> Another point Scott raised, was wether bugfix only releases would need >> freeze exceptions as well. > > Imho we shouldn't need exceptions for bugfix only releases, but it would be > nice have it documented (be it either in debian/changelog or via a bug or > both). I think it would be nice too, but it shouldn't be required, at least it shouldn't be required to do it via a bug report *and* to have to attach the upstream changelog. Could we clarify what are the requirements and what are just suggestions, and then clarify [1] ? Thanks, Emilio [1] https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze for bug fix only updates (process agreed by motu-release) signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposal for motu-release charter
On 2008-09-04 01:36:51 +0900, Emmet Hikory wrote: > Understood. When the remaining members return from vacation, > could a proposed charter be prepared and presented at the following > MOTU Meeting? Given the new decision process, it may be appropriate > to send it with enough advance time that there could be some > discussion on the mailing list, and participants could arrive to the > meeting prepared. Would a draft preparation by the 14th be possible? As the last two MOTU meetings didn't take place due to lack of participants, it would be a good idea to send the proposal to the MOTU mailing list in any case. Michael -- 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 will revert libgems-ruby to the old state.
On Thu, Sep 04, 2008, Mathias Gug wrote: > Binaries installed by the administrator should take precedence over > binaries provided by packages. Yes, I think this should be the case by default. If the admin wants his binaries to only take precedence in a particular use case, he could configure the PATH to list the directory with these binaries first in the PATH only in this use case. For instance if he wants to use specific binaries when running the crontab of a particular user, he could setup the PATH env var in that crontab to list a custom local path first. (This makes me think that we should have some kind of Debian/Ubuntu sysadmin guide for the recommended way to achieve common tasks. If you search the web for such a guide, you find the sysadmin-guide package in Ubuntu.) But now I'm tempted to ask whether the proposed gem system allows installation of gems in a specific directory which is *not* in the standard PATH? [[ Not really on topic, but I did hear about people complaining that their locally installed python was picked up by packaged "#!/usr/bin/env python" scripts. I can imagine why people would complain in this particular case because most packaged scripts don't use such a shebang so it would result in differing behavior between packaged scripts. Also it certainly would confuse our complex python policy tools. Nevertheless, it seems hardcoding /usr/bin/python is less useful than picking python from the PATH. But shebangs and python shebangs are too large a topic for the gem support we're discussing here I guess. }} > FYI the gem system uses its own alternatives and administrative > directories. The gem postinstall phase calls update-alternatives with > "--altdir /usr/local/etc/gems/alternatives/ --admindir > /var/lib/gems/alternatives/". Well, in my experience, alternatives I had never touched were sometimes broken on upgrades (certainly because of packaging errors). Enforcing proper use of alternatives in packages came up "recently" again on debian-policy: http://thread.gmane.org/gmane.linux.debian.devel.policy/9669 So proper usage of alternatives is complex. The new usage of alternatives by gems adds two levels of complexity: 1) because you will have to mix admin installed data with gem provided data. This opens up plenty of questions: - binary foo exists already in /usr/local/bin but a gem wants to install it, should it be overwritten? if not, should the gem installation fail? - when removing gems, do you remove blindly all files the gem installed or only if unmodified? - admin removes /usr/local files because he wants to start afresh, will the system be able to recover? 2) because alternatives managed for gems require gem-specific altdir and admindir settings: what happens if I want to install a similar system for PEAR or CPAN modules with different altdir and admindir settings? My point here is: proper behavior might not be the update-alternatives one, and alternatives are complex already without the additional questions that the usage of a tree which can contain user data brings up. It also look like you would want to mix multiple alternatives dbs to manage symlinks in /usr/local/bin for each gem-like use case. > > I think some admins run things like ./configure (the default usually > > installs in /usr/local) && make & sudo make install to install random > > software. This would clash with the current symlinks. > To paraphrase: the gem system setup by the rubygems package could be > seen as a self-contained component. Providing symlinks in /usr/local/bin > would open the door to instability in the gem system because other > installation methods run by an administrator could overwrite the content > of binaries installed by the gem system. > Is this an accurate view of your statement above ? And vice-versa: you also need to make sure you don't overwrite admin installed data when installing gems. > >Ubuntu systems also need to allow similar situations to other > > parallel distribution/packaging systems (as provided by python tools, > > perl tools etc.). > I agree with you. This situation raises an interesting topic that is > probably worth a discussion during the next UDS. (This is relevant for the inclusion of the first system managing the /usr/local hierarchy though; we can't simply allow the first implementation to be released if we know it prevents others.) > The same way I agree with the view that gems should be provided as > packages. But that will take time - all of CPAN modules were not > packaged overnight. Neither was the Python Package Index nor the PHP > Extension and Application Repository (PEAR). Perhaps a nicer alternative would be to build packages locally then (like DKMS): install some machinery which allows one to create a .deb installing binaries below /usr/bin in a special deb namespace (packages would be named gemdeb- t
Re: motu-release will revert libgems-ruby to the old state.
On 04/09/08 at 23:57 -0400, Scott Kitterman wrote: > On Thursday 04 September 2008 21:13, Dustin Kirkland wrote: > > On Thu, Sep 4, 2008 at 7:46 PM, Mathias Gug <[EMAIL PROTECTED]> wrote: > > > On Thu, Sep 04, 2008 at 04:04:57PM +0200, Loïc Minier wrote: > > >> No, I mean that it's not a policy violation to try to add the gem > > >> binary path to PATH on a best effort basis because packages will > > >> continue to work whether PATH has the gem binary patch or not. > > >> > > >> I wish manually installed gems benefit the users of the system > > >> (including the admin) and services as much as possible since someone > > >> went through the hassle of installing the gems: it means they either > > >> additional software or newer software available as gems. > > > > > > I assume you meant "it means they *want* either additional software or > > > newer software available as gems". > > > > > > Could the following statement be considered a corollary of the above ? > > > > > > Binaries installed by the administrator should take precedence over > > > binaries provided by packages. > > > > > > That's my interpretation of the following line in /etc/environment: > > > > > > PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/g > > >ames" > > > > My reading of the FHS on /usr/local/bin corroborates that. > > * http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY > > * "The /usr/local hierarchy is for use by the system administrator > > when installing software locally." > > > > If an administrator wanted to install something above and beyond the > > normal Ubuntu packages, that would be his/her prerogative, and s/he > > should do that in /usr/local/bin. This could certainly happen as any > > given untar/make/make-install (perhaps using --prefix), for > > self-written software, or as-yet unpackaged software for Ubuntu. > > Personally, in the case of Gems, I think it's not problematic for a Gem that > an admin has specifically installed to go in /usr/local for exactly these > reasons. Where I think the disagreement stems from is how to characterize > the additional program that Gems will pull in with them. I do not believe it > is correct to characterize these as 'installed by the adminstrator'. They > were installed by the Gems system and should not be in the default path. I disagree. The easiest way to see rubygems is to see it as "tar on steroids". If you consider it differently, then you open the door to hacks to try to integrate gems with apt. Since nobody seem to want that on the rubygems side, this is likely to fail or stay in an half-broken state, and make everybody unhappy. (rubygems users, and Ubuntu maintainers that will have to deal with the bad press) For the same reason, I don't think that we should package gems, because that would be about the same as packaging tarballls. The only sane way to do that would be to have empty packages that do "gem install foo" in postinst. It's a shame that a big part of the Ruby community doesn't acknowledge that other packaging systems exist. But working around that social problem using technical hacks is not going to lead anywhere. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- 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 will revert libgems-ruby to the old state.
On Thu, Sep 4, 2008 at 7:46 PM, Mathias Gug <[EMAIL PROTECTED]> wrote: > On Thu, Sep 04, 2008 at 04:04:57PM +0200, Loïc Minier wrote: >> No, I mean that it's not a policy violation to try to add the gem >> binary path to PATH on a best effort basis because packages will >> continue to work whether PATH has the gem binary patch or not. >> >> I wish manually installed gems benefit the users of the system >> (including the admin) and services as much as possible since someone >> went through the hassle of installing the gems: it means they either >> additional software or newer software available as gems. >> > > I assume you meant "it means they *want* either additional software or > newer software available as gems". > > Could the following statement be considered a corollary of the above ? > > Binaries installed by the administrator should take precedence over > binaries provided by packages. > > That's my interpretation of the following line in /etc/environment: > > PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" My reading of the FHS on /usr/local/bin corroborates that. * http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY * "The /usr/local hierarchy is for use by the system administrator when installing software locally." If an administrator wanted to install something above and beyond the normal Ubuntu packages, that would be his/her prerogative, and s/he should do that in /usr/local/bin. This could certainly happen as any given untar/make/make-install (perhaps using --prefix), for self-written software, or as-yet unpackaged software for Ubuntu. :-Dustin -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
