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