Open Stack

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
>> launchpad.
>>
>> 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