Re: Micro Release Exception needed for nova/glance/keystone

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Micro Release Exception needed for nova/glance/keystone

Dave Walker (Daviey)
On Fri, Nov 25, 2011 at 04:15:43PM -0800, Clint Byrum wrote:

> I was just reviewing the SRU's that Chuck Short uploaded for keystone,
> nova, and glance to oneiric-proposed, and it strikes me that really
> OpenStack core components should go through the MicroReleaseException
> process.
>
> Upstream has active QA, and as of diablo supports a stable release branch
> with policies around acceptance.
>
> Just sending this to ubuntu-devel as a PSA that if your SRU has more
> than 2 or 3 bugs to fix at one time, its probably not going to be able
> to pass through our manual patch review process. However, take a look
> at the criteria here and consider applying for a micro release exception:
>
> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
Hi Clint,

I think this really needs some further clarification.

I followed this process earlier this year, when performing an SRU for
bind9 which involved a new upstream version.. This was jumping from
upstream versions 9.7.0 -> 9.7.3 in Lucid.

I raised the subject with the TB, and mdz responded that:
"MicroReleaseExceptions is a list of standing exceptions. It's not
necessary to go through the tech board to handle one-off requests like
this one. The SRU team can decide what to do here without TB
involvement." [0]

Is this still the case?

[0] https://bugs.launchpad.net/ubuntu/lucid/+source/bind9/+bug/651875/comments/12

Kind Regards,
Dave Walker

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Micro Release Exception needed for nova/glance/keystone

Clint Byrum-4
Excerpts from Dave Walker's message of Mon Nov 28 16:50:07 -0800 2011:

> On Fri, Nov 25, 2011 at 04:15:43PM -0800, Clint Byrum wrote:
> > I was just reviewing the SRU's that Chuck Short uploaded for keystone,
> > nova, and glance to oneiric-proposed, and it strikes me that really
> > OpenStack core components should go through the MicroReleaseException
> > process.
> >
> > Upstream has active QA, and as of diablo supports a stable release branch
> > with policies around acceptance.
> >
> > Just sending this to ubuntu-devel as a PSA that if your SRU has more
> > than 2 or 3 bugs to fix at one time, its probably not going to be able
> > to pass through our manual patch review process. However, take a look
> > at the criteria here and consider applying for a micro release exception:
> >
> > https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
>
> Hi Clint,
>
> I think this really needs some further clarification.
>
> I followed this process earlier this year, when performing an SRU for
> bind9 which involved a new upstream version.. This was jumping from
> upstream versions 9.7.0 -> 9.7.3 in Lucid.
>
> I raised the subject with the TB, and mdz responded that:
> "MicroReleaseExceptions is a list of standing exceptions. It's not
> necessary to go through the tech board to handle one-off requests like
> this one. The SRU team can decide what to do here without TB
> involvement." [0]
>

Indeed, in single cases the SRU team can in fact approve whatever is
necessary to correct high impact bugs in stable releases.

I'm suggesting that if OpenStack will continue to fix bugs at this rate
on stable releases of OpenStack, it would be best if it were covered by a
standing exception so that these massive bug fix releases can be waived
through and managed by those who know OpenStack best. Otherwise the SRU
team will have to be faced with a decision each time.. whether to reject
it on its merits, or waive the verification steps, or require that all
of the bugs fixed in the upload are verified with the usual procedures.

We can absolutely waive the usual verification and bug requirements this
time, if you don't feel that there will be issues like this going forward
with OpenStack. Given the work around setting up policy and structure for
the stable updates branch of OpenStack, it would seem that there will
be quite a bit of ongoing maintenance of stable releases of OpenStack.
I think it would be in both Ubuntu and OpenStack's best interest if
those were able to move through the SRU process rapidly.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Micro Release Exception needed for nova/glance/keystone

Matt Zimmerman-2
In reply to this post by Dave Walker (Daviey)
On Tue, Nov 29, 2011 at 12:50:07AM +0000, Dave Walker wrote:

> On Fri, Nov 25, 2011 at 04:15:43PM -0800, Clint Byrum wrote:
> > I was just reviewing the SRU's that Chuck Short uploaded for keystone,
> > nova, and glance to oneiric-proposed, and it strikes me that really
> > OpenStack core components should go through the MicroReleaseException
> > process.
> >
> > Upstream has active QA, and as of diablo supports a stable release branch
> > with policies around acceptance.
> >
> > Just sending this to ubuntu-devel as a PSA that if your SRU has more
> > than 2 or 3 bugs to fix at one time, its probably not going to be able
> > to pass through our manual patch review process. However, take a look
> > at the criteria here and consider applying for a micro release exception:
> >
> > https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
>
> Hi Clint,
>
> I think this really needs some further clarification.
>
> I followed this process earlier this year, when performing an SRU for
> bind9 which involved a new upstream version.. This was jumping from
> upstream versions 9.7.0 -> 9.7.3 in Lucid.
>
> I raised the subject with the TB, and mdz responded that:
> "MicroReleaseExceptions is a list of standing exceptions. It's not
> necessary to go through the tech board to handle one-off requests like
> this one. The SRU team can decide what to do here without TB
> involvement." [0]
>
> Is this still the case?

I see the distinction as:

A. "Should we update package foo to version x.y.z in order to fix bugs N and
   M?" should be cleared with the SRU team.  The SRU team can set policy and
   make exceptions to it as appropriate to act in the best interests of
   Ubuntu users.

B. "Should we, *in general*, track upstream bugfix releases of package foo and
   trust that they're appropriate for use by all Ubuntu users?" should be
   cleared with the TB.  The TB has set criteria to help evaluate whether this
   is appropriate.

It sounds like Clint is suggesting that B. would be more appropriate than A.
for OpenStack.  I haven't personally checked if the OpenStack components
meet the documented criteria.

FWIW, I would support the TB in delegating more of this authority to the SRU
team if that would streamline things.  So far, there have only been a
handful of exceptions, and it hasn't been an issue.

--
 - mdz

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel