[cdwg] 2.5 blockers list

[Christopher J. Morrone]

On 09/26/2013 10:57 AM, Cory Spitz wrote:
> If we create a filter, than users can subscribe as well so I'd still like
> to see the blocker list created and managed regardless of search options.
>
> Are we going to micro-manage the Fix Version/s field in the tickets
> though?  If we decide a bug isn't a blocker for 2.5.0, someone will reset
> the Fix Version/s field to 2.5.1 right away?  We should be careful that
> the 2.5 blocker list and a list formed from tickets with Fix Version/s ==
> 2.5 are exact duplicate lists.

I would just call that managing the tickets, not micromanaging (with all 
its negative connotations).

And it kind of depends on what you mean by "blocker list".  In one 
sense, "blockers" are the tickets that have a priority setting of 
Blocker, and that is probably what Intel folks think of when you say 
"blocker list".  But I am trying to work to change that perception, and 
get people to realize than even tickets with a priority lower than 
"Blocker" sometimes needs to be scoped, worked, and resolved before the 
release can happen.

In other words, in a broader sense _all_ of the unresolved tickets 
lodged against 2.5.0 need to be addressed in some way before the release.

I think that it is important to include tickets with all priorities in 
the normal search results of unfinished work for a release.  If we 
continually show folks only a list of Blocker priority tickets, they 
will only be seeing the tip of the iceberg.  My belief is that this 
leaves too many people ignorant of the vast amount of work that we 
continue to leave unfinished in every release.

When people underestimate the unfinished work, I feel that has a 
negative impact on our planning for Lustre in general.  Folks 
continually fight attempts to address the technical debt in lustre 
(horrible API, unintelligble and undocumented code, barely useable 
command line tools, horrible configuration system, etc.)

When folks aren't aware of the backlog of work, we see too much funding 
going to fancy new features.  Those feature introduce new bugs on top of 
the large pile of existing bugs, and Lustre gets worse over time rather 
than better.

I'm not advocating that we stop feature development; we always need to 
strike a balance between stability and new features.  But in my opinion 
speed and stability are on the decline, and we need to tip the balance 
back a bit in in the other directions.

So in summary, I strongly believe that the "2.5.0 Unresolved Issues" 
search on the

   http://wiki.opensfs.org/Lustre_2.5.0

page is the correct one to be watching on a regular basis.  I have made 
a publicly accessible filter named

   2.5.0 Unresolved Issues

in jira, for those who don't want to hit the "Save as" button on their 
own. :)

If that list is not zero, we don't make the release.

Chris