On Mon, 2019-02-25 at 09:25 -0600, Matt Riedemann wrote:
On 2/25/2019 5:53 AM, Chris Dent wrote:
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.
FWIW I agree with this. I'm fine with no separate specs repo or core team. I do, however, think that having some tracking tool is important for project management to get an idea of what is approved for a release and what is left (and what was completed). Etherpads are not kanban boards nor are they indexed by search engines so they are fine for notes and such but not great for long-term documentation or tracking. for what its worth i would proably jsut creat a specs folder in the placement repo and then choose to use it as much or as little as required. kolla-ansible for example has an in repo specs folder but it only uses it very sparingly so the presence of a spec folder does not mean you have to use it for every feature. they use rfe bugs/blueprint to track most features and you could make the decision on that later depening on what tool suits placment best. be that lauchpad,storyboard or just etherpad. etherpad i think make more sense for tracking review priorites rather then completion but
for what its worth os-vif does have its own launchpad add we just use RFE bugs for any non cross project features. for cross project stuff e.g. nova usecases we use a nova bug/blueprint/sepc. the donwside of this is ironic approved a spec after m2 for a feature this release that required a os-vif change and we didnt know about it so we had to review it quickly not to block them. in that case i would have prefered at least an rfe bug against os-vif to tacked the change. anyway that is just my 2 cents out of tree specs repos with a sepreate specs core team has its uses but its overkill i think in most cases espcially for small repos like placement or os-vif but haveing a placemnt spec dir might be helpful in some cases.