[openstack-dev] [marconi] Development process adjustments
thierry at openstack.org
Mon Apr 29 13:11:17 UTC 2013
Monty Taylor wrote:
> On 04/25/2013 05:17 PM, Flavio Percoco wrote:
>> On 25/04/13 09:59 -0700, Mark Washenberger wrote:
>>> It's definitely the case that more work needs to go into maintaining
>>> Glance's blueprint backlog. But I still wonder if something like Trello
>>> might have an appropriate role to play in our development process by
>>> representing the pipeline that transforms ideas into specified,
>>> approved, and targeted blueprints.
>> FWIW, I first used Trello when Marconi's development started and it
>> has been helpful. My main concern about Trello is to not duplicate
>> contents and make sure that what needs to be in launchpad *is* in
>> Trello has made Marconi's organization simpler (keep in mind that
>> marconi's development _just started_). I don't know whether trello is
>> the best tool out there or not, though.
>> Also, I'm not saying projects should stop using launchpad but I do
>> think that as far as our main tool (Launchpad) is up-to-date, projects
>> should feel free to use whatever they think is best for them.
> Honestly, dev on the launchpad blueprints feature stalled quite a while
> ago, and I think the trello interest shows that there are, in fact, some
> deficiencies that should be sorted out. Kurt gave some great feedback
> the other day, and we've been collecting more and more of that
> informally over drinks at bars with folks.
Yes, Launchpad blueprints have a number of shortcomings, and they also
have all those extra fields that we must learn to ignore since they are
not part of our workflow. At this point I only see two benefits in
keeping them: the release pages (which show features and bugs for a
release in an aesthetic fashion) and all the tooling we've built around
them (change friction). This may not be worth bearing with the
drawbacks, especially if we can find a compelling alternative... so I
definitely welcome experimentation in that field.
Launchpad bugs also have a number of issues, but it also has a number of
extremely interesting features for (like bugtasks, which let a single
bug affect multiple projects and stable branches in a very convenient
way). So far those features outweigh the drawbacks...
> We've been trying to not open up too many big tooling cans of worms, and
> I think that's been working so far - which is one of the reasons we
> didn't do a summit session on the topic. BUT - we may be reaching
> critical mass where we need to look more deeply into options.
> I'll write up the things we've collected so far and publish them to a
> wiki/blueprint so that we can start a proper conversation on the topic.
As one of the main consumers of the feature tracking system, I look
forward to participating to that :)
Thierry Carrez (ttx)
Release Manager, OpenStack
More information about the OpenStack-dev