Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180611/55def8ae/attachment.sig>