You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit

[Tim Thome]

Eric Rostetter wrote:
> Quoting Axel Thimm <Axel.Thimm at ATrpms.net>:
>
>> The issue is also not the infrstructure IMO, it's simply lack of human
>> resources and either someone needs to assign them to it if that entity
>> (Red Hat/board/whatever) considers that a worthy goal, or the
>> resources need to come from more voluntary people, e.g. FL needs a
>> marketing manager.
>
> I think it is both Infrastructure and lack of humans, plus stupid 
> barriers
> that shouldn't exist.
Agreed... getting people to participate is one thing, but the effort to 
contribute is a bit high at the moment, considering that most folks are 
making this part of their spare time...

It's also about organizational leadership, which to be honest, I do find 
lacking... there is no specific plan, no accountability/responsibility, 
no visible means to release into testing and production. To be honest, 
Legacy is pretty much borken as an organization at the people level.

Folks want/need to know what to do, who does what, and how things work. 
This may be an implied thing at the moment, but speaking from somebody 
looking in from the outside, I have to ask why bother?

1) Packagers - this is important obviously
2) Testers - packagers should not be testers, but testers should be defined
3) Releaser Management - once QA is done, somebody needs to release the 
package to the production tree...

The three roles are very different, and these need to be filled by 
different people, i.e. no overlap in responsibility...

> The learning curve is high, people look down at volunteers just because
> they don't/won't/can't use some technology (e.g. IRC), and there is 
> little
> effort expended to get people to participate (though much flaming people
> for not participating).
The bar is pretty high to get in, and this is intimidating for those who 
lack experience with items outside of the course of their normal usage. 
Not to say that folks could not rise up to the challenge, it's just that 
the path is poorly documented, and the tools are, to be honest, a bit 
tough to use. Again, it comes down to who and how...


> There is also an emphasis on getting people to only help with QA, which
> is rather bad.  If you can get people to start helping however they
> feel they can, they will generally and eventually start helping in
> other areas.  But people generally need encouragement, and not flame
> wars, insults, and barriers.
Bingo... thing is that QA is the end of the line, and the one most 
needed and least respected by the folks that build packages. One thing 
that is very important, as the base of folks that would be potential QA 
candidates is to:

1) spell out what is needed - what is the problem and fix, how to test it?
2) how to use the systems - how to mark tested, reopen, open new bugs

For the packagers... how to package for a release. I maintain my own 
boxen, so when a security issue pops up, I download source or make the 
fix locally. How to build a package and release it into testing remains 
somewhat of a mystery... I'd be happy to do so, if it were documented 
somehow.

>
>> Or the need for resources is cut by reducing the number and time span
>> of supported releases.
>
> An option, but it only makes the limited resources go further, when what
> we really need are more resources...
More resources is not the answer - better management of the resources 
that are on board, and better tools to manage the process is what is needed.

The process itself needs to be defined and clarified.

Tim