settingsLogin | Registersettings

[openstack-dev] [Nova] The unbearable lightness of specs

0 votes

Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

That's only a subset of problems. Some more, you ask? OK. No clear
guidelines as to what needs a spec, that defaults to "everything does".
And spec being the absolute worst way to judge the validity of some of
the things that do require them.

Examples of the above are everywhere if you care to look for them but
some that I've hit this week are [1] (spec for a quick and dirty fix?!
really?!) [2] (spec stuck waiting for a single person to comment
something that is an implementation detail, and to make matter worse the
spec is for a bug fix) [3] (see how ill suited the format is for a
discussion + complaints about grammar and spelling instead of actual
point being made).

Nova's problem is not that it's big, it's that it's big and tightly
coupled. This means no one can be trusted to navigate the mess
successfully, so we add the process to stop them. What we should be
doing is fixing the mess, and the very process is preventing that.

Don't take my word for it - ask the Gantt subteam who have been trying
to figure out the scheduler interface for almost 4 cycles now. Folks
doing Cells might have a comment on this too.

The good news is that we have a lot of stuff in place already to help us
reduce this massive coupling of everything. We have versioned objects,
we have versioned RPC. Our internal APIs are terrible, and provide no
isolation, but we have the means to iterate and figure it out.

I don't expect this process issues will get solved quickly, If it were
up to me I'd drop the whole thing, but I understand that it's not how
it's done.

I do hope this makes people think, discuss and move things into the
direction of facilitating quality software development instead of
outright preventing it. I'll follow up with some ideas on how to go
forward once a few people have commented back.

N.

PS - Before you ask - splitting out virt drivers will relieve the
pressure but won't fix the tight coupling of everything else in Nova.

[1] https://review.openstack.org/#/c/84048/
[2] https://review.openstack.org/#/c/193576/
[3] https://review.openstack.org/#/c/165838/


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 Jun 24, 2015 in openstack-dev by Nikola_Đipanov (5,400 points)   2 3 5
retagged Jan 26, 2017 by admin

61 Responses

0 votes

24.06.2015 20:21, Daniel P. Berrange пишет:

On Wed, Jun 24, 2015 at 04:46:57PM +0000, Michael Krotscheck wrote:

On Wed, Jun 24, 2015 at 6:30 AM Matt Riedemann mriedem@linux.vnet.ibm.com
wrote:

There is the openstack-specs repo for cross-project specs:

http://specs.openstack.org/openstack/openstack-specs/

That'd be a good place for things like your os-vif library spec which
requires input from both nova and neutron teams, although I think it's
currently OK to have it in nova-specs since a lot of the forklift is
going to come from there and we can add neutron reviewers as needed.

Let's walk through a hypothetical (because I just went through this)
example of a cross-project spec, assuming a 6 month release cycle (26
weeks), assuming one person driving a spec.

First: Overhead
- 1 week for vacation
- 1 week for holidays.
- 4 weeks for feature freeze.
- 4 weeks of pre-summit roadmap planning.
- 1 week of summit.
Remaining: 15 weeks.

Second: Writing, discussing, and landing the spec.
Remaining: 9 weeks.

Third: Role conflicts and internal overhead.
Remaining time: 4.5 weeks

Writing the code:
Remaining time: 3.5 weeks.

The last step: Getting the cores to agree with your approach.
Remaining time: -0.5 weeks.
The problem is how long it takes.
This ultimately comes back to what I think is a far too rigid and long
development cycle. The idea that we have to work through a process on
defined milestone dates across a 6 month window is really inflexible.
It is a process designed for project managers to micro-manage a team
of product developers, not a process designed for developers who are
capable of managing their own day to day workload in an open source
project.

At a minimum I'd like to see the specs review & approval completely
de-couple from the development cycle. There is really no compelling
reason why design reviews have to be put in a box against a specific
release. In doing so we create a big crunch at the start of each cycle,
which is what we're particularly suffering under this week and last.
We should be happy to review and approve specs at any time whatsoever,
and allow approval to last for at least 1 year (with caveat that it
can be revoked if something in nova changes to invalidate a design
decision).
Absolutely agree. There is no use in waiting for another cycle to start
if you missed deadline for your spec in current cycle. Why not to review
specs and approve them setting next release cycle milestone and allow
people to start coding and get code review for next release cycle?

More generally, I think that the 6 month release cycle is really harmful
to our development agility, and we'd actually increase the work
accomplished and smooth out the highs & lows of productivity if we had
shorter cycles. This is something I suggested previously here

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html

Regards,
Daniel


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 Jun 24, 2015 by mnestratov_at_virtuo (440 points)  
0 votes

On 06/24/2015 12:25 PM, Daniel P. Berrange wrote:
Which happened repeatedly. You could say that
the first patch submitted to the code repository should simply be a doc
file addition, that describes the feature proposal and we should discuss
that before then submitting code patches, but then that's essentially
just the specs again, but with the spec doc in the main nova.git instead
of nova-specs.git.

Something like this, yes. I do not like the fact that the spec and the
code are likely to be out of sync, and that the target audience for the
spec after the feature is implemented is vanishingly small. We should
put the effort into docs that is currently going in to specs.

But, I stand by what I said before: Gerrit is not the right tool for
design, and specs are correspondingly owned by one person. I think it
is the approval part that really bugs me; the pedantry is its defining
feature. These are details much better hashed out in the code itself.

Specs prevent code from being written. If you think too much code is
written, then, yes, you will like specs. If, on the other hand, you
think that things should be implemented and tested before being posted
to the central repo, then specs are not nearly as valuable as end user
docs. I think and design in Code, not in specs. There are too many
details that you don't discover until you actually write the code, and
thus the specs often do not reflect the reality of the implementation
anyway.

So, what needs to be approved is not the spec, but the problem
statement. Saying "don't work on this until we agree your problem is
something to solve" is far more useful than "don't work on this until we
approve your design."


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 Jun 24, 2015 by Adam_Young (19,940 points)   2 7 11
0 votes

On Wed, Jun 24, 2015 at 11:42 AM, Kashyap Chamarthy kchamart@redhat.com
wrote:

On Wed, Jun 24, 2015 at 10:02:27AM -0500, Matt Riedemann wrote:

On 6/24/2015 9:09 AM, Kashyap Chamarthy wrote:

On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote:

On 06/24/2015 02:33 PM, Matt Riedemann wrote:

[. . .]

This is one of the baffling aspects -- that a so-called "super core"
has to approve specs with no obvious valid reasons. As Jay Pipes
mentioned once, this indeed seems like a vestigial remnant from old
times.

FWIW, I agree with others on this thread, Nova should get rid of this
specific senseless non-process. At least a couple of cycles ago.

Specs were only added a couple of cycles ago... :) And they were added
to
fill a gap, which has already been pointed out in this thread. So if we
remove them without a replacement for that gap, we regress.

Oops, I didn't mean to say that "Specs" as a concept should be gone.
Sorr for poor phrasing.

My question was answred by Joe Gordon with this review:

https://review.openstack.org/#/c/184912/

A bit more context:

We discussed the very issue of adjusting the review rules for nova-specs to
give all cores +2 power. But in the end we decided not to in the end.

As someone who does a lot of spec reviews, I take +1s from the right people
(not always nova-cores) to mean a lot, so much that I regularly will simply
skim the spec myself before +2ing it. If a subject matter expert who I
trust +1s a spec, that is usually all I need.

  • +1/-1s from the right people have a lot of power on specs. So the review
    burden isn't just on the people with '+W' power. We may not have done a
    great job of making this point clear.
  • There are many subject matter experts outside nova-core who's vote means
    a lot. For example PTL's of other projects the spec impacts.

--
/kashyap


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 Jun 24, 2015 by Joe_Gordon (24,620 points)   2 5 8
0 votes

On Wed, Jun 24, 2015 at 10:04 AM, Ed Leafe ed@leafe.com wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/24/2015 08:38 AM, Nikola Đipanov wrote:

I urge people to reply to this instead of my original email as the
writing is more detailed and balanced.

OK, I've read what others have written, and want to throw in my own
0.00008316 BTC.

The spec process is invaluable, but that is not to say that it can't be
improved - a lot.

Other emails have touched on the biggest disconnect in the process: that
an approved spec magically becomes unapproved on a particular calendar
date. This makes no sense whatsoever. If it was a good idea yesterday,
it will almost always be a good idea tomorrow.

I don' think this is a accurate summary of the status quo.

We currently have the fast track process, where if a spec was previously
approved we will quickly re-approve it. (I do a git diff between the
previous version and make sure the diff is trivial). By my count in liberty
we successfully used this procedure around 14 times. So yes things do
magically become unapproved on a somewhat random date, but I don't think
this is realistically a major pain point. (Side note we were able to
approve a lot of those specs before the summit).

Secondly nova is moves fast. For example in Kilo we had: 4752 files
changed, 299,275 insertions(+), 309,689 deletions(-) [0]. What is amazing
about this is nova kilo only had 251,965 lines [1]. So specs that we
approved 6 months ago are often not valid anymore, I have seen this happen
time and time again.

[0] git diff --stat 0358c9afb5af6697be88b5b69d96096a59a2148e
2439e97c42d99926bc85ee93799006c380073c8d
[1] git ls-files | xargs wc -l

The other obvious disconnect is the gap between nova-core and
nova-spec-core. If someone is knowledgeable enough and trusted enough to
commit code to Nova, they should be trusted to approve a spec.

Those two changes aren't controversial, are they? If not, let's do them
ASAP, and then iterate from there.


iQIcBAEBCgAGBQJViuMJAAoJEKMgtcocwZqLp2EQAIFOeEJgfVZoVOeFIpEkr7wy
zmDzmJdTTGxLeG1fguLUimb72Vp1CfS/iL+bMSuFC+dSgam+w+BZuewuwbDMdhdO
RzjCuRpOaPqm6h/fhEUYAeLH9jLBcX7NJrwJHJOKFQMVhVSNVZrvEOwGk//KYg47
U8GrFsI7tvYKF25b2siv3WhiFRG+WoGhakBgeP+6fv91jEYwhVgV0OW98ZZao6sV
aAmbRbfxAhjIjqywLASi0LobFFdeqWyXq8rMVQd1e/4dK4r38OxOZKP907RQIyW2
181w1kMwUpYvzSJd7CQjp8Zb337XRZWNEcXuESqrsqmB4LNPN1MKzbx2N0+xtyFq
IoSki5E4khnIvFNWA2CrUXE599piUV2BRP5hXKSgEdqnaBN51g0AgPMsoMQZFu5c
xnDaHSW5v285ukiHxFp88XA6JHcCxd5tGOj9WmE5BeWHP6nXjzFbiv+HTxyBp0vZ
ph5fqNpK4sA+z7dO81ji2yQBtSJbI2kTYIbgc5ylkRpKXKRjm4FDgTgp1asEj8Je
POstxWSbduGWEYvCkkWnRC3s45vKYaulNt699OcrnuE/2v9nmQat2K7mevZF+JAz
YIAF32WDN27lcgWRLd3OxPpRy2P3a/5MwYcvwKHGyaYKAKXNtXUzs7EriMqrUXkV
1B2kPORGp8nUNKEQobP5
=UaLL
-----END PGP SIGNATURE-----


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 Jun 24, 2015 by Joe_Gordon (24,620 points)   2 5 8
0 votes

On 06/24/2015 08:42 AM, Daniel P. Berrange wrote:
On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:

Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

I'd like to see some actual evidence to backup a sweeping statement
as "Specs dont work. They do nothing to facilitate good design happening,
if anything they prevent it."

Comparing Nova today, with Nova before specs were introduced, I think
that specs have had a massive positive impact on the amount of good
design and critique that is happening.

Yes, I feel the same.

When I was reviewing features in Nova before specs came along, I spent
alot of time just trying to figure out what on earth the code was
actually attempting to address, because there was rarely any statement
of the problem being addressed, or any explanation of the design that
motivated the code. This made life hard for reviewers trying to figure
out if the code was acceptable to merge. It is pretty bad for contributors
trying to implement new features too, as they could spend weeks or months
writing and submitting code, only to be rejected at the end because the
(lack of any design discussions) meant they missed some aspect of the
problem which in turn meant all their work was in vain. That was a collosal
waste of everyone's time and resulted in some of the very horrible code
impl decisions we're still living with today.

Right.

In reviewing specs, we also often get into far too much detail about
the actual implementation, which is really counterproductive. eg when
get down to bikeshedding about the names of classes, types of object
attributes, and so forth, it is really insane. That level of detail
and bikesheeding belongs in the code review, not the design for the
most part.

While we can sometimes get a little deep in implementation details, I
have one comment about this.

Naming is extremely important. I know it sounds silly, but what people
name classes and modules and methods goes directly to the readability
and understandability of the code itself. I often bring up naming points
in spec reviews because I feel it forces the submitter to think through
how to explain their proposed solution to people. I know that
personally, conversations about naming things in my own submitted spec
reviews have been immensely useful. As an example recently, Alexis Lee
and Ed Leafe had some comments about how I'd named the objects in my
resource-objects spec, and although I went back and forth with Alexis on
a number of things, the end result I am confident produced objects and
methods that were named in a way that is most readable and
comprehensible to contributors.

Specs are also inflexible when it comes to dealing with features that
cross multiple projects, because we silo'd spec reviews against the
individual projects. This is sub-optimal, but ultimately not a show
stopper.

Well, we do have the openstack-specs repo for cross-project specs, but
it's not well reviewed, to be fair.

I also think the way we couple spec approval & reviews to the dev
cycles is counterproductive. We should be willing to accept and
review specs at any point in any cycle, and once approved they should
remain valid for a prolonged period of time - not require us to go
through re-review every new dev cycle as again that's just creating
extra burden. We should of course though reserve the right to unapprove
specs if circumstances change, invlidating the design for the previous
approval.

OMG, thank you SO much for bringing this up. I could not agree more with
the above paragraph. We can always amend a previously approved spec with
additional information based on followup conversations, but taking the
time to continually push new specs for review each cycle is a colossal
waste of time.

Best,
-jay


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 Jun 24, 2015 by Jay_Pipes (59,760 points)   3 11 14
0 votes

On 06/24/2015 06:42 PM, Jay Pipes wrote:

I also think the way we couple spec approval & reviews to the dev
cycles is counterproductive. We should be willing to accept and
review specs at any point in any cycle, and once approved they should
remain valid for a prolonged period of time - not require us to go
through re-review every new dev cycle as again that's just creating
extra burden. We should of course though reserve the right to unapprove
specs if circumstances change, invlidating the design for the previous
approval.

OMG, thank you SO much for bringing this up. I could not agree more
with the above paragraph. We can always amend a previously approved
spec with additional information based on followup conversations, but
taking the time to continually push new specs for review each cycle is
a colossal waste of time.

What I have been pushing for in Keystone is that all specs get submitted
against backlog. They get approved there, and then assigning them to a
specific release is a deliberate second change. Backlog reviews can be
approved at any point.


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 Jun 25, 2015 by Adam_Young (19,940 points)   2 7 11
0 votes

On Wed, 2015-06-24 at 17:25 +0100, Daniel P. Berrange wrote:
On Wed, Jun 24, 2015 at 11:52:37AM -0400, Adam Young wrote:

On 06/24/2015 06:28 AM, Nikola Đipanov wrote:

Gerrit and our spec template are a horrible tool for
discussing design.
This is the heart of the problem.

I think that a proper RFE description in the bug tracker is the best place
to start. Not a design of the solution, but a statement of the problem.

Then, the rest of the discussion should take place in the code. Keystoen has
the Docs right in the code, as do, I think, every other project. Don't sign
off on a patch for a major feature unless the docs have been updated to
explain that feature. It will keep us from bike shedding about Database
schemas.

What you are describing is sounds like the situation that existed before
the specs concept was introduced. We had a statement of problem in the
blueprint, and then people argued over the design in the code reviews.
It really didn't work at all - code reviews are too late in the workflow
to start discussions around the design, as people are already invested
in dev work at that point and get very upset when you then tell them
to throw away their work. Which happened repeatedly. You could say that
the first patch submitted to the code repository should simply be a doc
file addition, that describes the feature proposal and we should discuss
that before then submitting code patches, but then that's essentially
just the specs again, but with the spec doc in the main nova.git instead
of nova-specs.git.

I don't think you meant this as a don't do it, just an experience point:
you're saying we couldn't make the process work, but that doesn't mean
that the process itself (specless code reviews) can't be made to work.
It works fine for a lot of open source projects, so the process must be
workable. However, what the experience has shown is that there's a
bottleneck which isn't removed simply by removing the spec process.

On the spec question, the reason projects like the Linux Kernel are so
code driven is that with code it's harder to block a submission on
esoteric grounds, whereas with no code it is easier to argue endlessly
about minutiae. I think this might be the reason for the "lightness"
Nikola complains about: the less you put in a spec, the less reason
people have to weigh in on it and delay its approval. Perhaps an
appropriate question is: "is that fear well founded or just anecdotal?"

If I look at what the above says about the main issue that doesn't get
solved by removing the spec process, it's review pressure: how do you
increase the throughput of approval/rejection. Note I didn't advocate
more reviews: The metric for success should be time to resolution
(accept/reject), not the number of reviews, if we ask everyone to double
their time spent reviewing and the net result of this is that the
average number of reviews to resolution doubles, nothing is gained. So
perhaps it's time to actually measure the number of reviews to
resolution and look at ways to reduce this metric. That will make the
available current review bandwidth go further and reduce the time to
actual resolution without anyone having to do more work. The low
hanging fruit in this might be the obvious patches: obvious accept
(simple bug fix) or obvious reject (bogus code) should go through after
one review: do they? Perhaps one other is wasting core time: after a
couple of failed reviews by people who could +2 the thing, is it time to
reject? And perhaps, finally, there should be a maximum number of
reviews before an automatic reject?

Sorry for derailing the argument, but I do still see review bandwidth as
a key issue behind all the problems.

James


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 Jun 25, 2015 by James_Bottomley (2,940 points)   2 2
0 votes

On 06/24/2015 10:17 PM, Joe Gordon wrote:

On Wed, Jun 24, 2015 at 11:42 AM, Kashyap Chamarthy <kchamart@redhat.com
kchamart@redhat.com> wrote:

On Wed, Jun 24, 2015 at 10:02:27AM -0500, Matt Riedemann wrote:
>
>
> On 6/24/2015 9:09 AM, Kashyap Chamarthy wrote:
> >On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote:
> >>On 06/24/2015 02:33 PM, Matt Riedemann wrote:

[. . .]

> >This is one of the _baffling_ aspects -- that a so-called "super core"
> >has to approve specs with *no* obvious valid reasons.  As Jay Pipes
> >mentioned once, this indeed seems like a vestigial remnant from old
> >times.
> >
> >FWIW, I agree with others on this thread, Nova should get rid of this
> >specific senseless non-process.  At least a couple of cycles ago.
>
> Specs were only added a couple of cycles ago... :)  And they were added to
> fill a gap, which has already been pointed out in this thread.  So if we
> remove them without a replacement for that gap, we regress.

Oops, I didn't mean to say that "Specs" as a concept should be gone.
Sorr for poor phrasing.

My question was answred by Joe Gordon with this review:

    https://review.openstack.org/#/c/184912/

A bit more context:

We discussed the very issue of adjusting the review rules for nova-specs
to give all cores +2 power. But in the end we decided not to in the end.

I was expecting to also read a "why" here, since I was not at the summit.

As someone who does a lot of spec reviews, I take +1s from the right
people (not always nova-cores) to mean a lot, so much that I regularly
will simply skim the spec myself before +2ing it. If a subject matter
expert who I trust +1s a spec, that is usually all I need.

  • +1/-1s from the right people have a lot of power on specs. So the
    review burden isn't just on the people with '+W' power. We may not have
    done a great job of making this point clear.
  • There are many subject matter experts outside nova-core who's vote
    means a lot. For example PTL's of other projects the spec impacts.

This is exactly the kind of cognitive dissonance I find hard to not get
upset about :)

Code is what matters ultimately - the devil is in the details, and I
can bet you that it is extremely unlikely that a PTL of any other
project is also going to go and do a detailed review of a feature branch
in Nova, and have the understanding of the state of the surrounding
codebase needed to do it properly. That's what's up to the nova
reviewers to deal with. I too wish Nova code was in a place where it was
possible to just do "architecture", but I think we all agree it's
nowhere near that.

With all due respect to you Joe (and I do have a lot of respect for you)
- I can't get behind how Nova specs puts process and documents over
working and maintainable code. I will never be able to get behind that!

I honestly think Nova is today worse off then it could have been, just
because of that mindset. You can't "process" away the hard things in
coding, sorry.

N.


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 Jun 25, 2015 by Nikola_Đipanov (5,400 points)   2 3 5
0 votes

Maxim Nestratov wrote:
24.06.2015 20:21, Daniel P. Berrange пишет:

On Wed, Jun 24, 2015 at 04:46:57PM +0000, Michael Krotscheck wrote:

First: Overhead
- 1 week for vacation
- 1 week for holidays.
- 4 weeks for feature freeze.
- 4 weeks of pre-summit roadmap planning.
- 1 week of summit.
Remaining: 15 weeks.

Second: Writing, discussing, and landing the spec.
Remaining: 9 weeks.

Third: Role conflicts and internal overhead.
Remaining time: 4.5 weeks

Writing the code:
Remaining time: 3.5 weeks.

The last step: Getting the cores to agree with your approach.
Remaining time: -0.5 weeks.
The problem is how long it takes.
[...]

At a minimum I'd like to see the specs review & approval completely
de-couple from the development cycle. There is really no compelling
reason why design reviews have to be put in a box against a specific
release. In doing so we create a big crunch at the start of each cycle,
which is what we're particularly suffering under this week and last.
We should be happy to review and approve specs at any time whatsoever,
and allow approval to last for at least 1 year (with caveat that it
can be revoked if something in nova changes to invalidate a design
decision).
Absolutely agree. There is no use in waiting for another cycle to start
if you missed deadline for your spec in current cycle. Why not to review
specs and approve them setting next release cycle milestone and allow
people to start coding and get code review for next release cycle?

I totally agree that there is no reason to tie specs drafting, review &
approval to the development cycle. In fact, most project teams don't.

Now, Michael's example is a bit unrealistic -- cross-project specs
aren't tied to release cycle at all, and you can certainly work on them
during the 4 weeks of feature freeze or 4 weeks of pre-summit roadmap
planning.

I would even argue that those 8 weeks are the ideal time to draft and
get early reviews on a spec : you can use the design summit at the end
of them to close the deal if it still needs discussion, and start
working on code the week after.

--
Thierry Carrez (ttx)


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 Jun 25, 2015 by Thierry_Carrez (57,480 points)   3 8 15
0 votes

Joe Gordon wrote:
On Wed, Jun 24, 2015 at 10:04 AM, Ed Leafe <ed@leafe.com
ed@leafe.com> wrote:

[...]
Other emails have touched on the biggest disconnect in the process: that
an approved spec magically becomes unapproved on a particular calendar
date. This makes no sense whatsoever. If it was a good idea yesterday,
it will almost always be a good idea tomorrow.

I don' think this is a accurate summary of the status quo.

We currently have the fast track process, where if a spec was previously
approved we will quickly re-approve it. (I do a git diff between the
previous version and make sure the diff is trivial). By my count in
liberty we successfully used this procedure around 14 times. So yes
things do magically become unapproved on a somewhat random date, but I
don't think this is realistically a major pain point. (Side note we were
able to approve a lot of those specs before the summit).

Secondly nova is moves fast. For example in Kilo we had: 4752 files
changed, 299,275 insertions(+), 309,689 deletions(-) [0]. What is
amazing about this is nova kilo only had 251,965 lines [1]. So specs
that we approved 6 months ago are often not valid anymore, I have seen
this happen time and time again.

Could you give specific examples ? Tying the specs to a specific cycle
results in lots of overhead and extra pain. I understand it's meant to
ensure that 6-month-old specs are still current, but the benefits may
not outweigh the huge drawbacks. Is there any horror story that this
process actually prevented ?

--
Thierry Carrez (ttx)


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 Jun 25, 2015 by Thierry_Carrez (57,480 points)   3 8 15
...