Testing Fedora - small (?) suggestion.

[Jeff Spaleta]

On 11/11/06, n0dalus <n0dalus+redhat at gmail.com> wrote:
> On 11/11/06, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > or we instruct testers to use yum-skip-broken plugin that is now
> > available as of fe6.
> >
>
> I think that's missing the point. Testers should have to do as little
> voodoo as possible on their machines to get a working rawhide install.

I think you are missing the point... we should ALL need to do as
little as possible to get a working install.  Its called "the ideal
situation."  You are free to continue to wax eloquently about it all
you want.. but some of us live in reality.. you are welcome to join us
in finding reasonable. balanced solutions which strike the most
equitable balanced use of the amount of currently available manhours
and assocsiated infrastructure resources.

> Telling them to install a yum plugin is just as bad as telling them to
> --exclude={,,,}. Multiply every minute you expect testers to sit there
> trying to work out why updates aren't happening and installing plugins
> by the number of testers and the result is a substantial waste of time
> (that could have been used to find real bugs).

Sorry, but I look at testing as the exact opposite problem. Testers
need MORE guidance... MORE instruction... not less.  Dear god, if
installing a defined set of tester oriented tools that is not in the
default install usage senario is over-burdensome, I'm almost at a loss
for words.  The expectation that testers don't have to do any
additional software installs to be effective is ...tragic.

>
> Maybe the yum-skip-broken plugin should be installed by default in
> test releases.

Maybe...  testers should be more informed about the point of the test
releases. Let me remind you right now, it is to be as close to the
final shipping solution as possible,  If we make the defaults oriented
for testers specifically..we are no longer testing the final release
as it is going to be shipping.  What we do is start spinning up a
suite of tester oriented tools as an optional group of packages and
spin up guidance associated with how to use those tester oriented
tools.

> Or maybe we could just fix the build system. Any new
> update generated by the build system that isn't installable due to
> dependencies should be put in a temporary place until the dependent
> packages arrive.

I don't know if this is feasible or not. I'd be concerned that such a
situation would make it easier for maintainers to forget about
rebuilding, if there isn't public pressure to clean up the tree in a
timely manner. If the staging area lets built packages from maintainer
A fester outside of general availability for long periods of time due
to inaction from maintainer B we are actually de-valuing the effort
made by maintainer A to get packages out to chew on.  These issues
however can be addressed with the appropriate level of script logic to
inform the general community what was built and held back. Also
scripts to ensure cross-maintainer notification so that a maintainer
for a library can be informed as to exactly why her library is being
held back.

Additionally any pre-publish staging area would have to be mirrored
and accessible to anyone else in the community who need to track
packages in rawhide. People working on extras-development packages
would need to have reasonable access to this staging area to run mock
based local builds against on their own computers.  If a  library
packages lingers in a private staging area because one app in Core
hasn't been rebuilt against it yet... that could seriously impact the
abiliity of multiple application maintainers in Extras to rebuild in a
timely manner.

-jef"
You need to make sure that in your efforts to make testing push-button
simple for testers, you aren't amplifying the burden on other parts of
the community.  It's never going to be perfect, but there is a
direction forward::
http://fedoraproject.org/wiki/QA/Beaker
https://testing.108.redhat.com/
"spaleta