Eric Rostetter wrote:
Quoting Axel Thimm <Axel.Thimm@xxxxxxxxxx>:
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
--
fedora-legacy-list mailing list
fedora-legacy-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-legacy-list
