On 2018-06-11 19:53:47 +0000 (+0000), CARVER, PAUL wrote: [...] > Well, that's a bit rude [...]
Apologies for the strong language; I did not intend any offense, and it was indeed unnecessary for purposes of my point. > So, are you saying the information shown in the examples I gave is > not useful? I'm saying as far as OpenStack is concerned, it's not a "standard" (which was your original claim). A minority of the 40 official services (so named by the project navigator anyway) are relying on it and I'd wager far fewer still of the >800 deliverable repositories maintained by official OpenStack project teams are either. > Or just that I've been lucky in the past that the projects I'm > most interested in do a better than typical job of managing > releases but the future is all downhill? I think you likely care proportionally more about projects which have been in the OpenStack ecosystem for longer (this is unsurprising) and of those quite a few are tracking series/milestone info in LP because it was integrated with release management once upon a time (up until a couple years ago) so there was a lot of pressure, perhaps even a requirement, to do so and old habits die hard. Matt R. notes in his reply that as PTL he found using it for tracking cycle work independent of whether the Release Management team was still expecting/relying on it, so I don't doubt the usefulness of having some means of continuing to do that (and with StoryBoard there are a few ways you could do it but we didn't want to be proscriptive). Some other teams have found that they prefer a kanban style tool for this sort of effort instead, but have unfortunately turned to proprietary services like Trello as a result. I also don't think that lack of using the series/milestone tracker in LP is an indication that a project is doing a worse job of managing releases. We have a lot more useful automation now around release notes, highlights, release processes scraping references from commit logs, and so on. > If you're saying it's not useful info and we're better off without > it then I'll just have to disagree. If you're saying that it has > been replaced with something better, please share the URLs. https://docs.openstack.org/infra/storyboard/gui/theory.html#worklists-and-boards As I said, we didn't want to start out telling teams how they should be doing their release tracking so that we could see what patterns emerged. If you recall the "specs" experiment years ago, a few teams tried mildly different solutions for moving from LP blueprints with random wiki page links to tracking specifications in Git repositories, and over time they learned successful patterns from each other and mostly converged on similar solutions. There were similar cries back then about "how will users/operators find out what is being planned?" but I think the end result was far better than what it replaced. > I'm all for improvements, but saying "only a few people were doing > something useful so we should throw it out and nobody do it" isn't > a path to improvement. How about we discuss alternate (e.g. > better/easier/whatever) ways of making the information available. I'm not saying anything should be thrown out. I personally don't even feel that teams should be forced to use StoryBoard (or any particular tool for that matter), but just want to focus on making sure we provide useful, free and open tools through which and on which we can collectively collaborate. -- Jeremy Stanley
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
