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 4
retagged Jan 26, 2017 by admin

61 Responses

0 votes

+1. Not closing the spec process and alowing work to continue is good. Open Source works by allowing developers to scratch itches. If you impeed that itch scratching long enough they will go somewhere else to be able to meet their needs. The window between missed spec deadline and next open window is a very long time for that.

Thanks,
Kevin


From: Maxim Nestratov
Sent: Wednesday, June 24, 2015 11:58:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs

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

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 Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

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

On 06/24/2015 04:41 PM, Joe Gordon wrote:

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).

That may be true, but it certainly doesn't jibe with the experiences
of many spec authors. And even if it did work flawlessly, it
represents extra work for zero benefit.

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.

Specs are about general direction, with some specifics on
implementation. Sure, things change, and a previously valid spec might
no longer be valid, but that would certainly be caught in the code
review, no? I don't think that most developers operate in a vacuum,
and if the part of the code they are working on is changing that
radically, they will certainly notice the merge conflicts at the very
least. :)

John Garbutt gave the example in a different reply of the closing of
changes to the v2 API in Kilo. That's a perfect example of why a spec
should not be invalidated. If a the implementation of a
previously-approved spec tried to modify the v2 API, that would
certainly be caught in code review, and the developer would have to
address that change via a microversion instead. The change itself is
still valid, but the means of implementing it might have to be updated.


iQIcBAEBCgAGBQJVjAQ3AAoJEKMgtcocwZqLsckP/09N2kvQv5YiuDmzu5Ieyvl/
ZIb8o2kh0gp89I/wd4uGdZhXxVVJLLm0EO09UfI8zNKJyDIBC8QRdISqueMkffub
dgWBIIc5kxTJQhxPNq96B5rQE26W8lZnonZuJ/lCI8+hn81cmtlXU8TDZFBJY4+I
A27SGvJZXchAPbom4XXP0laxGnN7V5liuYp/KSNstkQSoQX12JSS8cafXST+mkWs
Crqyq+5bjmccbX+8e1yywvKopMe7uMe15ASp5ueWA7jYE0+y+655/13v2IpEQvfu
Evptf3JX5Rs71C5XPeHKMMlZOi2wZeWVtoEsqsuwkWzTiZP9EctzOTCv0xwNDYGl
VukA8gLF9Q+wtACCj8UDPWSEyJn3FUsbQXmgHcDrnpI4FrSIxqGUvxO7ck33rjOr
p6iHHLuNAti9dcwGEkSwLKqJ/ysrk9omtOwn/xifGV9PlxaupqFrzCPaiVs0L6Ac
RpVsNv/uy/uVmV2xeVAV3LUD4/PUd4UGY0DnO974eoJBai1BnBo2knJJgtGzBLDo
ZHdwe8zCGRkRCl7LR8mBe6X448jYGp239ldWf5hxjEhOy8dqdJLNy3sh9ElnI/6a
x1iWPVZ6ZfezchucwuU7q4l8vtEaQQ0HPU3NjDG+mssUH96StQrujXf8Ebnh8/vw
jgloCeQr/NS+rYEAAhgY
=HJd9
-----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
responded Jun 25, 2015 by Ed_Leafe (11,720 points)   1 3 6
0 votes

On 25/06/15 09:49, "Thierry Carrez" thierry@openstack.org wrote:

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.

The operator community has also been generally positive on the specs
process. It has allowed a possibility for people without python skills to
give input on the overall approach being taken rather than needing to
review code. The approach, after all, from an operator mid cycle meetup
(blueprints on blueprints) combined with the nova specs proposal.

I’ve certainly had a few specs where the approach needed in-depth
discussion (one I remember clearly was the re-assign a project spec) and
to have waited till the code was written would have been a waste.

One of the problems that I’ve seen is with specs etiquette where people -1
because they have a question. This is a question of education rather than
a fundamental issue with the process.

--
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


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 Tim_Bell (16,440 points)   1 6 10
0 votes

On Thu, Jun 25, 2015 at 1:39 AM, Nikola Đipanov ndipanov@redhat.com wrote:

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.

The why is below. But I think its definitely worth revisiting (I am
personally for the patch).

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.

This goes back to the point(s) that was brought up over and over again in
this thread. I guess we have to agree to disagree.

I think saying 'code' is what ultimately matters is misleading. 'Code' is
the implementation of an idea. If an idea is bad, so what if the code is
good?

I wouldn't ask the PTL of say Keystone to review the implementation of some
idea in nova, but I do want their opinion on an idea that impacts how nova
and keystone interact. Why make someone write a bunch of code, only to find
out that the design itself was fundamentally flawed and they have to go
back to the drawing board and throw everything out. On top of that now the
reviewers has to mentally decouple the idea and the code (unless the
feature has good documentation explaining that -- sort of like a spec).

That being said, I do think there is definitely room for improvement.

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!

So what are you proposing ultimately? It sounds like the broad consensus
here is: specs have made things better, but there is room for improvement
(this is my opinion as well). Are you saying just drop specs all together?
Because based on the discussion here, there isn't anything near consensus
for doing that. So if we aren't going to just revert to how things were
before specs, what do you think we should do?

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


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

On 06/25/2015 09:46 PM, Joe Gordon wrote:
On Thu, Jun 25, 2015 at 1:39 AM, Nikola Đipanov <ndipanov@redhat.com

> 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.

This goes back to the point(s) that was brought up over and over again
in this thread. I guess we have to agree to disagree.

I think saying 'code' is what ultimately matters is misleading. 'Code'
is the implementation of an idea. If an idea is bad, so what if the code
is good?

I wouldn't ask the PTL of say Keystone to review the implementation of
some idea in nova, but I do want their opinion on an idea that impacts
how nova and keystone interact. Why make someone write a bunch of code,
only to find out that the design itself was fundamentally flawed and
they have to go back to the drawing board and throw everything out. On
top of that now the reviewers has to mentally decouple the idea and the
code (unless the feature has good documentation explaining that -- sort
of like a spec).

That being said, I do think there is definitely room for improvement.

It really goes both way - it's important to state the problem and the
general direction the implementation plans to take, but anything more
than that is a distraction from getting to a prototype that will tell us
more about if the design was in fact fundamentally flawed. We have
examples of that in tree right now - stuff was written and re-written
and got better. Spec will never remove the need for that and we should
not try to make them.

Also "throwing code away" is a bit of a straw-man, good code will almost
never be thrown out entirely, some bits of it - sure (that's software) -
you may change an interface to a class, or a DB schema detail here and
there - but if your code is written to be modular and does not leak
abstractions - you'll end up keeping huge bits of it through rewrites.
We need more of 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!

So what are you proposing ultimately? It sounds like the broad
consensus here is: specs have made things better, but there is room for
improvement (this is my opinion as well). Are you saying just drop specs
all together? Because based on the discussion here, there isn't anything
near consensus for doing that. So if we aren't going to just revert to
how things were before specs, what do you think we should do?

I will follow up with a more detailed email, but in short - acknowledge
that some problems are fundamentally different than others, decide what
kind of work absolutely requires an up front discussion (API seems like
a solid candidate) and drop the blanket requirement for a detailed spec
for any work (do still require a problem statement though, maybe in a
lighter format as part of the branch).

A lot of it comes back to our release mechanism too, and is definitely
something we need to work on incrementally.

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

On 26 June 2015 at 11:19, Nikola Đipanov ndipanov@redhat.com wrote:
On 06/25/2015 09:46 PM, Joe Gordon wrote:

On Thu, Jun 25, 2015 at 1:39 AM, Nikola Đipanov <ndipanov@redhat.com

> 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.

This goes back to the point(s) that was brought up over and over again
in this thread. I guess we have to agree to disagree.

I think saying 'code' is what ultimately matters is misleading. 'Code'
is the implementation of an idea. If an idea is bad, so what if the code
is good?

I wouldn't ask the PTL of say Keystone to review the implementation of
some idea in nova, but I do want their opinion on an idea that impacts
how nova and keystone interact. Why make someone write a bunch of code,
only to find out that the design itself was fundamentally flawed and
they have to go back to the drawing board and throw everything out. On
top of that now the reviewers has to mentally decouple the idea and the
code (unless the feature has good documentation explaining that -- sort
of like a spec).

That being said, I do think there is definitely room for improvement.

It really goes both way - it's important to state the problem and the
general direction the implementation plans to take, but anything more
than that is a distraction from getting to a prototype that will tell us
more about if the design was in fact fundamentally flawed. We have
examples of that in tree right now - stuff was written and re-written
and got better. Spec will never remove the need for that and we should
not try to make them.

We changed things significantly at the start of kilo:
http://specs.openstack.org/openstack/nova-specs/specs/kilo-template.html

The spec is explicitly about the direction, not the code details.

We need to be clearer about why we are doing specs, and be clear about
how best to use that tool. I am sure we can do much better here.

Also "throwing code away" is a bit of a straw-man, good code will almost
never be thrown out entirely, some bits of it - sure (that's software) -
you may change an interface to a class, or a DB schema detail here and
there - but if your code is written to be modular and does not leak
abstractions - you'll end up keeping huge bits of it through rewrites.
We need more of 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!

So what are you proposing ultimately? It sounds like the broad
consensus here is: specs have made things better, but there is room for
improvement (this is my opinion as well). Are you saying just drop specs
all together? Because based on the discussion here, there isn't anything
near consensus for doing that. So if we aren't going to just revert to
how things were before specs, what do you think we should do?

I will follow up with a more detailed email, but in short - acknowledge
that some problems are fundamentally different than others, decide what
kind of work absolutely requires an up front discussion (API seems like
a solid candidate) and drop the blanket requirement for a detailed spec
for any work (do still require a problem statement though, maybe in a
lighter format as part of the branch).

To be clear, we dropped the blanket requirement for specs at the start of kilo:
http://docs.openstack.org/developer/nova/blueprints.html

Its not very clear though, in its current form. Help needed with that.

A lot of it comes back to our release mechanism too, and is definitely
something we need to work on incrementally.

I really need someone to step up and help document how you can use
release milestones, and the ups and downs of that. And similar things
for using any commit from trunk. We are not good at telling people
about what Nova is delivering/promising when you do that vs using
something with a stable branch.

That should be a help towards discussing adopting semver, in a similar
way to ironic maybe, during the next cycle.

Thanks,
John


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 26, 2015 by John_Garbutt (15,460 points)   3 4 5
0 votes

On 2015-06-25 16:39:56 +0000 (+0000), Tim Bell wrote:
[...]
One of the problems that I’ve seen is with specs etiquette where
people -1 because they have a question. This is a question of
education rather than a fundamental issue with the process.

http://docs.openstack.org/infra/manual/developers.html#peer-review
has been updated with a 7th entry addressing this in particular.
Hopefully that will help realign reviewers on acceptable vs.
unacceptable use of -1 for certain types of questions over time.
--
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 Jun 26, 2015 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

On 06/25/2015 05:39 PM, Tim Bell wrote:

On 25/06/15 09:49, "Thierry Carrez" thierry@openstack.org wrote:

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.

The operator community has also been generally positive on the specs
process. It has allowed a possibility for people without python skills to
give input on the overall approach being taken rather than needing to
review code. The approach, after all, from an operator mid cycle meetup
(blueprints on blueprints) combined with the nova specs proposal.

I’ve certainly had a few specs where the approach needed in-depth
discussion (one I remember clearly was the re-assign a project spec) and
to have waited till the code was written would have been a waste.

No doubt doing design prior to coding is extremely useful in a lot of
cases, and having documents/artifacts of that process in a well-known
place. Some problems don't need that much of design outside of code
itself though.

This is what I was referring to elsewhere on the thread when I said we
are coupling together the process of designing a feature with it's
approval for a release and release planning etc. and then blanket apply
it to everything that resembles a feature.

One of the problems that I’ve seen is with specs etiquette where people -1
because they have a question. This is a question of education rather than
a fundamental issue with the process.

It's not only about education - I think Gerrit is the wrong medium to
have a design discussion and do design work. Maybe you disagree as you
seem to imply that it worked well in some cases?

I've recently seen on more than a few cases how a spec "review" can
easily spiral into a collection of random comments that are hard to put
together in a coherent discussion that you could call design work.

If you throw in the expectation of approval into the mix, I think it
basically causes the opposite of good design collaboration to happen.

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

-----Original Message-----
From: Nikola Đipanov [mailto:ndipanov@redhat.com]
Sent: 26 June 2015 18:34
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs

On 06/25/2015 05:39 PM, Tim Bell wrote:

On 25/06/15 09:49, "Thierry Carrez" thierry@openstack.org wrote:

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.

The operator community has also been generally positive on the specs
process. It has allowed a possibility for people without python skills
to give input on the overall approach being taken rather than needing
to review code. The approach, after all, from an operator mid cycle
meetup (blueprints on blueprints) combined with the nova specs
proposal.

I’ve certainly had a few specs where the approach needed in-depth
discussion (one I remember clearly was the re-assign a project spec)
and to have waited till the code was written would have been a waste.

No doubt doing design prior to coding is extremely useful in a lot of cases,
and having documents/artifacts of that process in a well-known place.
Some problems don't need that much of design outside of code itself
though.

This is what I was referring to elsewhere on the thread when I said we are
coupling together the process of designing a feature with it's approval for a
release and release planning etc. and then blanket apply it to everything
that resembles a feature.

One of the problems that I’ve seen is with specs etiquette where
people -1 because they have a question. This is a question of
education rather than a fundamental issue with the process.

It's not only about education - I think Gerrit is the wrong medium to have a
design discussion and do design work. Maybe you disagree as you seem to
imply that it worked well in some cases?

I've recently seen on more than a few cases how a spec "review" can easily
spiral into a collection of random comments that are hard to put together
in a coherent discussion that you could call design work.

Limiting those who give input to the people who can analyse python and determine the impacts of the change has significant risks. Many of those running OpenStack clouds can give their feedback as part of the specs process. While this may not be as fully structured as you would like, ignoring the input from those who are running clouds when proposing a change is likely to cause problems later on.

The specs process was developed jointly to allow exactly this kind of early input ... people writing the code wanted input from those who were using this code to deliver new functions and improvements to the end users of the cloud. No problem to discuss how to improve the process but it is important to allow all the people affected by a change to be involved in the solution and contribute, not just the ones writing the code.

Tim

If you throw in the expectation of approval into the mix, I think it basically
causes the opposite of good design collaboration to happen.

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

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 26, 2015 by Tim_Bell (16,440 points)   1 6 10
0 votes

-----Original Message-----
From: Jeremy Stanley [mailto:fungi@yuggoth.org]
Sent: 26 June 2015 16:42
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs

On 2015-06-25 16:39:56 +0000 (+0000), Tim Bell wrote:
[...]

One of the problems that I’ve seen is with specs etiquette where
people -1 because they have a question. This is a question of
education rather than a fundamental issue with the process.

http://docs.openstack.org/infra/manual/developers.html#peer-review
has been updated with a 7th entry addressing this in particular.
Hopefully that will help realign reviewers on acceptable vs.
unacceptable use of -1 for certain types of questions over time.

I also feel that stackalytics should credit people of a 0 review comment on specs. Currently, I think that only non-zero reviews are considered as a contribution. My understanding of the workflow is that a 0 is in many cases is the constructive way to respond and therefore should be considered as a contribution.

Tim

--
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

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 26, 2015 by Tim_Bell (16,440 points)   1 6 10
...