settingsLogin | Registersettings

[openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

0 votes

Hi,

diskimage-builder has fallen under the "centralised release tagging"
mechanism [1], presumably because it is under tripleo. I'd like to
propose that we don't do that.

Firstly, dib doesn't have any branches to manage.

dib's other main function is as part of the daily CI image builds.
This means to get a fix into the CI images in a somewhat timely
fashion, we approve the changes and make sure our releases happen
before 14:00 UTC, and monitor the build results closely in nodepool.

I don't expect the stable release team to be involved with all this;
but if we miss windows then we're left either going to efforts getting
one of a handful of people with permissions to do manual rebuilds or
waiting yet another day to get something fixed. Add some timezones
into this, and simple fixes are taking many days to get into builds.
Thus adding points where we can extend this by another 24 hours
really, well, sucks.

I have previously suggested running dib from git directly to avoid the
release shuffle, but it was felt this was not the way to go [2]. I've
proposed putting the release group back with [3] and cleaning up with
[4].

Thanks,

-i

[1] https://review.openstack.org/298866
[2] https://review.openstack.org/283877
[3] https://review.openstack.org/307531
[4] https://review.openstack.org/307534


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Apr 19, 2016 in openstack-dev by Ian_Wienand (3,620 points)   4 6

12 Responses

0 votes

Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000:

Hi,

diskimage-builder has fallen under the "centralised release tagging"
mechanism [1], presumably because it is under tripleo. I'd like to
propose that we don't do that.

Yes, we've set up all official projects to use the central release
request system this cycle.

Firstly, dib doesn't have any branches to manage.

This change doesn't have anything to do with branches.

dib's other main function is as part of the daily CI image builds.
This means to get a fix into the CI images in a somewhat timely
fashion, we approve the changes and make sure our releases happen
before 14:00 UTC, and monitor the build results closely in nodepool.

I don't expect the stable release team to be involved with all this;
but if we miss windows then we're left either going to efforts getting
one of a handful of people with permissions to do manual rebuilds or
waiting yet another day to get something fixed. Add some timezones
into this, and simple fixes are taking many days to get into builds.
Thus adding points where we can extend this by another 24 hours
really, well, sucks.

How often does that situation actually come up?

Doug

I have previously suggested running dib from git directly to avoid the
release shuffle, but it was felt this was not the way to go [2]. I've
proposed putting the release group back with [3] and cleaning up with
[4].

Thanks,

-i

[1] https://review.openstack.org/298866
[2] https://review.openstack.org/283877
[3] https://review.openstack.org/307531
[4] https://review.openstack.org/307534


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Doug_Hellmann (87,520 points)   3 4 13
0 votes

On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote:
Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000:
[...]

I don't expect the stable release team to be involved with all this;
but if we miss windows then we're left either going to efforts getting
one of a handful of people with permissions to do manual rebuilds or
waiting yet another day to get something fixed. Add some timezones
into this, and simple fixes are taking many days to get into builds.
Thus adding points where we can extend this by another 24 hours
really, well, sucks.

How often does that situation actually come up?

Semi-often. The project is officially under TripleO but it's sort of
a shared jurisdiction between some TripleO and Infra contributors. I
think the release team for diskimage-builder used to shoot for
tagging weekly (sans emergencies), though that's slacked off a bit
and is more like every 2 weeks lately.

DIB is an unfortunate combination of a mostly stable framework and a
large pre-written set of scripts and declarative data which is
constantly evolving for widespread use outside the OpenStack
ecosystem (so most of the change volume is to the latter). As Ian
points out, the Infra team has already been tempted to stop relying
on DIB releases at all (or worse, maintain a fork) to reduce overall
latency for getting emergency fixes reflected in our worker images.

I suspect that most of the concern over using OpenStack release
process for DIB (and similarly Infra projects) is that the added
complexities introduce delays, especially if there's not a release
team member available to do on-the-spot approvals on weekends and
such. I don't know whether extending that to add tagging ACLs for
the library-release group would help? That would bring the total up
to 6 people, two more of whom are in non-American timezones, so
might be worth a try.

It's also worth keeping in mind that we've sort of already
identified two classes of official OpenStack projects. One is
"OpenStack the Product" only able to be distributed under the Apache
license and its contributors bound by a contributor license
agreement. The other is the output of a loose collective of groups
writing ancillary tooling consumed by the OpenStack community and
also often used for a lot of other things completely unrelated to
OpenStack. I can see where strict coordinated release process and
consistency for the former makes sense, but a lot of projects in the
latter category likely see it as unnecessary overkill for their
releases.
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

Excerpts from Jeremy Stanley's message of 2016-04-19 15:41:26 +0000:

On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote:

Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000:
[...]

I don't expect the stable release team to be involved with all this;
but if we miss windows then we're left either going to efforts getting
one of a handful of people with permissions to do manual rebuilds or
waiting yet another day to get something fixed. Add some timezones
into this, and simple fixes are taking many days to get into builds.
Thus adding points where we can extend this by another 24 hours
really, well, sucks.

How often does that situation actually come up?

Semi-often. The project is officially under TripleO but it's sort of
a shared jurisdiction between some TripleO and Infra contributors. I
think the release team for diskimage-builder used to shoot for
tagging weekly (sans emergencies), though that's slacked off a bit
and is more like every 2 weeks lately.

That's about the same as or less often than we tag Oslo libraries.

DIB is an unfortunate combination of a mostly stable framework and a
large pre-written set of scripts and declarative data which is
constantly evolving for widespread use outside the OpenStack
ecosystem (so most of the change volume is to the latter). As Ian
points out, the Infra team has already been tempted to stop relying
on DIB releases at all (or worse, maintain a fork) to reduce overall
latency for getting emergency fixes reflected in our worker images.

Sure, that's a compelling argument. I'm not opposed to making it easier
for timely releases, just trying to understand the pressure.

I suspect that most of the concern over using OpenStack release
process for DIB (and similarly Infra projects) is that the added
complexities introduce delays, especially if there's not a release
team member available to do on-the-spot approvals on weekends and
such. I don't know whether extending that to add tagging ACLs for
the library-release group would help? That would bring the total up
to 6 people, two more of whom are in non-American timezones, so
might be worth a try.

It's also worth keeping in mind that we've sort of already
identified two classes of official OpenStack projects. One is
"OpenStack the Product" only able to be distributed under the Apache
license and its contributors bound by a contributor license
agreement. The other is the output of a loose collective of groups
writing ancillary tooling consumed by the OpenStack community and
also often used for a lot of other things completely unrelated to
OpenStack. I can see where strict coordinated release process and
consistency for the former makes sense, but a lot of projects in the
latter category likely see it as unnecessary overkill for their
releases.

It's not just about control, it's also about communication. One of
the most frequent refrains we hear is "what is OpenStack", and one
way we're trying to answer that is to publicize all of the things
we release through releases.openstack.org. Centralizing tagging
also helps us ensure consistent versioning rules, good timing, good
release announcements, etc.

Since dib is part of tripleo, and at least 2 other projects depend
on it directly (sahara-image-elements and manila-image-elements),
I would expect the tripleo team to want it included on the site,
to publish release announcements, etc.

On the other hand, dib is using the release:independent model, which
indicates that the team in fact doesn't think it should be considered
part of the "product." Maybe we can use that as our flag for which
projects should really be managed by the release team and which
should not, but we don't want projects that want to be part of official
releases to use that model.

With what I know today, I can't tell which side of the line dib is
really on. Maybe someone can clarify?

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Doug_Hellmann (87,520 points)   3 4 13
0 votes

On Tue, Apr 19, 2016 at 1:25 PM, Doug Hellmann doug@doughellmann.com wrote:
It's not just about control, it's also about communication. One of
the most frequent refrains we hear is "what is OpenStack", and one
way we're trying to answer that is to publicize all of the things
we release through releases.openstack.org. Centralizing tagging
also helps us ensure consistent versioning rules, good timing, good
release announcements, etc.

Since dib is part of tripleo, and at least 2 other projects depend
on it directly (sahara-image-elements and manila-image-elements),
I would expect the tripleo team to want it included on the site,
to publish release announcements, etc.

On the other hand, dib is using the release:independent model, which
indicates that the team in fact doesn't think it should be considered
part of the "product." Maybe we can use that as our flag for which
projects should really be managed by the release team and which
should not, but we don't want projects that want to be part of official
releases to use that model.

With what I know today, I can't tell which side of the line dib is
really on. Maybe someone can clarify?

dib is part of a TripleO "release" given it's used by users to both
install the Undercloud and build Overcloud images. IMO, I think it
makes sense to move it from release:independent to
release:cycle-with-intermediary.

Just fyi, the topic of choosing the right release tags for all the
TripleO projects just came up in the TripleO meeting today in light of
moving to the centralized release tagging. I would think all the
projects would be moving from release:independent to the proposed
release:cycle-trailing or release:cycle-with-intermediary.

--
-- James Slagle
--


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by James_Slagle (7,000 points)   1 3 4
0 votes

On Tue, Apr 19, 2016 at 11:41 AM, Jeremy Stanley fungi@yuggoth.org wrote:
DIB is an unfortunate combination of a mostly stable framework and a
large pre-written set of scripts and declarative data which is
constantly evolving for widespread use outside the OpenStack
ecosystem (so most of the change volume is to the latter). As Ian
points out, the Infra team has already been tempted to stop relying
on DIB releases at all (or worse, maintain a fork) to reduce overall
latency for getting emergency fixes reflected in our worker images.

A fork would be unfortunate. What about a new repo that's just for the
elements used heavily by infra, e.g., openstack-infra-elements.

As you say, the dib interface is pretty stable, are most of the
emergency fixes from the past mostly in elements themselves?

You could have openstack-infra-elements be release:independent, giving
you the freedom to release emergency fixes as quickly as needed.

It's also worth keeping in mind that we've sort of already
identified two classes of official OpenStack projects. One is
"OpenStack the Product" only able to be distributed under the Apache
license and its contributors bound by a contributor license
agreement. The other is the output of a loose collective of groups
writing ancillary tooling consumed by the OpenStack community and
also often used for a lot of other things completely unrelated to
OpenStack. I can see where strict coordinated release process and
consistency for the former makes sense, but a lot of projects in the
latter category likely see it as unnecessary overkill for their
releases.

I definitely think dib is part of "OpenStack the Product" given it has
to be used by users and operators of TripleO.

--
-- James Slagle
--


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by James_Slagle (7,000 points)   1 3 4
0 votes

As an Op, I've been bitten by both sides of this....

I've seen dib updated and broken things.
I've seen dib elements updated and things broke (centos6 removal in particular hurt.)
I've appreciated dib elements getting fixed quickly at times because distro's changed, and the element needed change too and so I didn't have to continue to work around issues.

So, I can't say which way forward is best. Just that care has to be taken in all cases. :)

Thanks,
Kevin


From: James Slagle [james.slagle@gmail.com]
Sent: Tuesday, April 19, 2016 12:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On Tue, Apr 19, 2016 at 11:41 AM, Jeremy Stanley fungi@yuggoth.org wrote:
DIB is an unfortunate combination of a mostly stable framework and a
large pre-written set of scripts and declarative data which is
constantly evolving for widespread use outside the OpenStack
ecosystem (so most of the change volume is to the latter). As Ian
points out, the Infra team has already been tempted to stop relying
on DIB releases at all (or worse, maintain a fork) to reduce overall
latency for getting emergency fixes reflected in our worker images.

A fork would be unfortunate. What about a new repo that's just for the
elements used heavily by infra, e.g., openstack-infra-elements.

As you say, the dib interface is pretty stable, are most of the
emergency fixes from the past mostly in elements themselves?

You could have openstack-infra-elements be release:independent, giving
you the freedom to release emergency fixes as quickly as needed.

It's also worth keeping in mind that we've sort of already
identified two classes of official OpenStack projects. One is
"OpenStack the Product" only able to be distributed under the Apache
license and its contributors bound by a contributor license
agreement. The other is the output of a loose collective of groups
writing ancillary tooling consumed by the OpenStack community and
also often used for a lot of other things completely unrelated to
OpenStack. I can see where strict coordinated release process and
consistency for the former makes sense, but a lot of projects in the
latter category likely see it as unnecessary overkill for their
releases.

I definitely think dib is part of "OpenStack the Product" given it has
to be used by users and operators of TripleO.

--
-- James Slagle
--


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

On Tue, Apr 19, 2016, at 10:25 AM, Doug Hellmann wrote:
Excerpts from Jeremy Stanley's message of 2016-04-19 15:41:26 +0000:

On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote:

Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000:
[...]

I don't expect the stable release team to be involved with all this;
but if we miss windows then we're left either going to efforts getting
one of a handful of people with permissions to do manual rebuilds or
waiting yet another day to get something fixed. Add some timezones
into this, and simple fixes are taking many days to get into builds.
Thus adding points where we can extend this by another 24 hours
really, well, sucks.

How often does that situation actually come up?

Semi-often. The project is officially under TripleO but it's sort of
a shared jurisdiction between some TripleO and Infra contributors. I
think the release team for diskimage-builder used to shoot for
tagging weekly (sans emergencies), though that's slacked off a bit
and is more like every 2 weeks lately.

That's about the same as or less often than we tag Oslo libraries.

DIB is an unfortunate combination of a mostly stable framework and a
large pre-written set of scripts and declarative data which is
constantly evolving for widespread use outside the OpenStack
ecosystem (so most of the change volume is to the latter). As Ian
points out, the Infra team has already been tempted to stop relying
on DIB releases at all (or worse, maintain a fork) to reduce overall
latency for getting emergency fixes reflected in our worker images.

Sure, that's a compelling argument. I'm not opposed to making it easier
for timely releases, just trying to understand the pressure.

I suspect that most of the concern over using OpenStack release
process for DIB (and similarly Infra projects) is that the added
complexities introduce delays, especially if there's not a release
team member available to do on-the-spot approvals on weekends and
such. I don't know whether extending that to add tagging ACLs for
the library-release group would help? That would bring the total up
to 6 people, two more of whom are in non-American timezones, so
might be worth a try.

It's also worth keeping in mind that we've sort of already
identified two classes of official OpenStack projects. One is
"OpenStack the Product" only able to be distributed under the Apache
license and its contributors bound by a contributor license
agreement. The other is the output of a loose collective of groups
writing ancillary tooling consumed by the OpenStack community and
also often used for a lot of other things completely unrelated to
OpenStack. I can see where strict coordinated release process and
consistency for the former makes sense, but a lot of projects in the
latter category likely see it as unnecessary overkill for their
releases.

It's not just about control, it's also about communication. One of
the most frequent refrains we hear is "what is OpenStack", and one
way we're trying to answer that is to publicize all of the things
we release through releases.openstack.org. Centralizing tagging
also helps us ensure consistent versioning rules, good timing, good
release announcements, etc.

Since dib is part of tripleo, and at least 2 other projects depend
on it directly (sahara-image-elements and manila-image-elements),
I would expect the tripleo team to want it included on the site,
to publish release announcements, etc.

On the other hand, dib is using the release:independent model, which
indicates that the team in fact doesn't think it should be considered
part of the "product." Maybe we can use that as our flag for which
projects should really be managed by the release team and which
should not, but we don't want projects that want to be part of official
releases to use that model.

With what I know today, I can't tell which side of the line dib is
really on. Maybe someone can clarify?

Doug

There is a bit more nuance to getting releases out for downstream
consumers than just getting DIB fixes out quickly. Often there is a
situation where a downstream needs a fix/feature soonish but not
critically - maybe DIB is creating images for infra where networking is
not working due to a dib bug. Infra can delete the last round of images
and still function but its worthwhile to get things fixed soon. In that
case we don't want to just rush a release out the door (there's often
other things which have been merged and carry some risk), and we (or at
least I) like to wait to cut a DIB release until a morning, preferably
when a DIB core is around to help debug / verify the fix and any
fallout. I am not sure there is an easy fix where we can keep this model
without being release:independent - otherwise we would be coordinating
between 3 groups to get a fix out at an ideal time rather than 2, and
the only way I could see this working is for us to give up on releases
being made at a convenient time for DIB cores.

The reason for this is partially what fungi mentioned - DIB has a fair
amount of integration code with the things it installs. Some of this
could be removed out of the in-tree elements which would help, but at
the end of the day DIB will always be responsible for a fair amount of
distro-specific logic to make a workable image. As a result, there will
always be a need for some integration between DIB and downstreams who
gate using it (as with any other tool to build images / packages / etc).

In an ideal world, we would solve this with tighter integration testing
between DIB and its downstreams, but this isn't possible right now due
to the fact that there isn't a way for us to build DIB images in the
gate without hitting a ton of upsteam resources (such as package
mirrors), and as a result the DIB tests are inherently unstable. There
are new package mirrors being worked on, and this will solve some of the
issues, but I think we are a long way from DIB tests being stable
enough to be OK to run in a gate for other projects. The best fix we
have been able to come up with for now is to make sure DIB tests arent
integrated in the gate with others, and try and be vocal about potential
breaks with our downstreams.

I hope this clarifies a bit (although maybe it just made things more
confusing given all that text ;)).

-Greg


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Gregory_Haynes (4,320 points)   3 4
0 votes

On 04/20/2016 03:25 AM, Doug Hellmann wrote:
It's not just about control, it's also about communication. One of
the most frequent refrains we hear is "what is OpenStack", and one
way we're trying to answer that is to publicize all of the things
we release through releases.openstack.org.

So for dib, this is mostly about documentation?

We don't have the issues around stable branches mentioned in the
readme, nor do we worry about the requirements/constraints (proposal
bot has always been sufficient?).

Centralizing tagging also helps us ensure consistent versioning
rules, good timing, good release announcements, etc.

We so far haven't had issues keeping the version number straight.

As mentioned, the timing has extra constraints due to use in periodic
infra jobs that I don't think the release team want to be involved
with. It's not like the release team will be going through the
changes in a new release and deciding if they seem OK or not (although
they're welcome to do dib reviews, before things get committed :) So I
don't see what timing constraints will be monitored in this case.

When you look at this from my point of view, dib was left/is in an
unreleasable state that I've had to clean up [1], we've now missed yet
another day's build [2] and I'm not sure what's different except I now
have to add probably 2 days latency to the process of getting fixes
out there.

To try and be constructive : is what we want a proposal-bot job that
polls for the latest release and adds it to the diskimage-builder.yaml
file? That seems to cover the documentation component of this.

Or, if you want to give diskimage-builder-release group permissions on
the repo, so we can +2 changes on the diskimage-builder.yaml file, we
could do that. [3]

-i

[1] https://review.openstack.org/#/c/306925/
[2] https://review.openstack.org/#/c/307542/
[3] my actual expectation of this happening is about zero


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Ian_Wienand (3,620 points)   4 6
0 votes

On 04/20/2016 06:09 AM, Fox, Kevin M wrote:
I've seen dib updated and broken things.

I've seen dib elements updated and things broke (centos6 removal in
particular hurt.)

By the time it gets to a release, however, anything we've broken is
already baked in. Any changes in there have already passed review and
whatever CI we have.

(not to say we can't do better CI to break stuff less. But that's
outside the release team's responsibility)

-i


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Ian_Wienand (3,620 points)   4 6
0 votes

On Tue, Apr 19, 2016, at 01:25 PM, Ian Wienand wrote:
On 04/20/2016 03:25 AM, Doug Hellmann wrote:

It's not just about control, it's also about communication. One of
the most frequent refrains we hear is "what is OpenStack", and one
way we're trying to answer that is to publicize all of the things
we release through releases.openstack.org.

So for dib, this is mostly about documentation?

We don't have the issues around stable branches mentioned in the
readme, nor do we worry about the requirements/constraints (proposal
bot has always been sufficient?).

Centralizing tagging also helps us ensure consistent versioning
rules, good timing, good release announcements, etc.

We so far haven't had issues keeping the version number straight.

As mentioned, the timing has extra constraints due to use in periodic
infra jobs that I don't think the release team want to be involved
with. It's not like the release team will be going through the
changes in a new release and deciding if they seem OK or not (although
they're welcome to do dib reviews, before things get committed :) So I
don't see what timing constraints will be monitored in this case.

When you look at this from my point of view, dib was left/is in an
unreleasable state that I've had to clean up [1], we've now missed yet
another day's build [2] and I'm not sure what's different except I now
have to add probably 2 days latency to the process of getting fixes
out there.

To try and be constructive : is what we want a proposal-bot job that
polls for the latest release and adds it to the diskimage-builder.yaml
file? That seems to cover the documentation component of this.

Or, if you want to give diskimage-builder-release group permissions on
the repo, so we can +2 changes on the diskimage-builder.yaml file, we
could do that. [3]

-i

[1] https://review.openstack.org/#/c/306925/
[2] https://review.openstack.org/#/c/307542/
[3] my actual expectation of this happening is about zero

I think I have a handle on the different release tags after some reading
/ IRC chat, and AIUI - as long as DIB is an official project then in the
current system it's releases will be going through the release team.
Therefore, the discussion about release tag type isn't really relevant
to the concerns we seem to be bringing up which mostly center around us
worrying over the new step required to get a release out - there doesn't
exist a tag which will change this.

My concern with this extra step is mostly wondering what the practical
benefit to us is? Obviously there is some complexity being added to us
getting out a release, and were also involving a whole new team of folks
in doing this, so I think this absolutely warrants some benefit over the
existing system to us. There's a couple obvious things (having releases
go through review rather than just git push is extremely nice), but IMO
this doesn't outweigh the downsides of adding an additional review team.
I also feel like this is an issue we could solve while still allowing us
to retain release control.

So, a couple questions:

  • Is there disagreement with the sentiment that adding the extra
    releases review team to our release process is not desirable for DIB? I
    am really wondering if there's some practical benefit here we might be
    missing...

  • Are there some benefits inherent to the extra releases review team
    that we are missing and outweigh the benefits of the added process? I
    want to make sure to distinguish between things (like gerrit perms with
    our existing setup) which we could work with the releases team to fix,
    and things that we can't.

Thanks,
Greg


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Gregory_Haynes (4,320 points)   3 4
...