Open Stack

On Sun, 24 Feb 2019, Matt Riedemann wrote:

> The issue is none of the changes are being reflected back in the whiteboard 
> for the blueprint in launchpad because the changes are made in the extracted 
> placement repo which doesn't have a launchpad project, nor is there anything 
> in storyboard for placement.

Yeah, there's a similar issue with os-resource-classes releases not
updating launchpad bugs as released. Probably others.

> Right now it's a small thing, but I'm wondering what, if any, plans are in 
> place for tracking blueprints for the extracted placement repo. I'm assuming 
> the answer is storyboard but maybe it hasn't been discussed much yet.

As Jay and Eric point out we've talked about what to do about specs
and months ago there was some talk of "well, eventually we'll go to
storyboard" but that was sort of pending governance decisions and
stability. I guess we're nearly there.

(more below...)

On Sun, 24 Feb 2019, Jay Pipes wrote:

> There was some light discussion about it on IRC a couple weeks ago. I 
> mentioned my preference was to not have a separate specs repo nor use the 
> Launchpad blueprints feature. I'd rather have a "ideas" folder or similar 
> inside the placement repo itself that tracks longer-form proposals in 
> Markdown documents.

I like no-separate-specs-repo ideas as well and got the sense that
most people felt the same way.

I think still having some kinds of specs for at least some changes
is a good idea, as in the past it has helped us talk through an API
to get it closer to right before writing it. We don't need
spec-cores and I reckon the rules for what needs a spec can be
loosened, depending on how people feel.

(Markdown! I'd love to do markdown but using existing tooling, and
including all these artifacts in the existing docs (even if they are
just "ideas") seems a good thing.)

On Sun, 24 Feb 2019, Eric Fried wrote:

> +1 to combining specs into the code repo.

> Re launchpad vs storyboard: This may be going too far, but is
> "neither" an option? The information in a blueprint has always
> seemed largely redundant to me. Approved blueprints can be
> review.o.o?proj=placement&status=merged&path=specs/$release/approved/*.
> Whiteboards can be etherpads (which is what I thought you were
> talking about originally, which confused me, because I marked the
> placement blueprints unblocked on the etherpad last week; didn't
> think to duplicate that to the blueprints, my bad.) Are etherpads
> any more... "ethereal" than lp whiteboards or storyboards? (Does
> anyone look at those after the blueprint is closed?)

I agree that blueprint+spec management has felt largely redundant,
probably because one came later than the other. However, I'd prefer
for us to kind of unify under storyboard rather than mix and match
several different pieces. I think etherpads are pretty good for the
note taking thing at PTGs and the like, but execrable for pretty
much everything else.

(What follows are just some ideas, for comment, we'll have to figure
out together what will work best.)

I haven't had a chance to really learn up on storyboard as much as
I would like, but I think we should probably try to use it as a
central tracking place. Features that warrant a spec should be a
story where one of the tasks in the story is the spec itself. The rest
of the tasks are the implementation. tags, boards and lists ought to
allow us to create useful views.

Storyboard isn't fully soup yet, but we can help push it in that
direction. We should probably create ourselves there and update
infra config so gerrit updates happen well.

For things that are currently in progress, we should simply carry on
with them as they are, and manage them manually. That means paying
some close attention to the 4 extant blueprints and the various
bugs. At the end of Stein we should kill or migrate what's left.

So, to take it back to Matt's question, my opinion is: Let's let
existing stuff run its course to the end of the cycle, decide
together how and when we want to implement storyboard.

(I've been sort of putting these kinds of questions off until
there's a new PTL.)


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent