Rawhide development

[Jeff Spaleta]

On 7/18/05, Rahul Sundaram <sundaram at redhat.com> wrote:
> Reading through the desktop-devel-list in GNOME brings
> http://mail.gnome.org/archives/desktop-devel-list/2005-July/msg00357.html.

>Making it easier for end users to test rawhide?. 
> Making it more dogfoodable?  

Its not going to get easier or more dogfoodable unless there is a
commitment to provide a version of the development tree  that is
self-consistent on a more regular basis.  Barring bugs in anaconda,
fresh installs or upgrades using anaconda over the network are
possible when the tree is self-consistent..but from day-to-day you
can't know if thats going to be the case.
To make it easier, how the development tree is populated or structured
is going to have to change, but that is a trade-off.  If there was a
way to provide something like the last known fully consistent rawhide
tree in an automated way for dogfooders to target for network installs
or upgrades.. that might help... but that comes at a cost in terms of
mirror space and resources to change the daily pushing behavior.


Right now, I've had the most success eating rawhide in piecemeal
package upgrades using yum... but that is an iterative trial and error
process as you do the upgrade in chunks. You can't expect yum upgrade
to just work when moving over to the development tree.  And you
certaintly have to be attentive.  I'd like to add that I think
anaconda itself would recieve for more testing inside the development
tree if there was a garunteed to be self-consistent tree to target to
test anaconda against, so its not just something to think about in
terms of helping upstream gnome out.

However, I am more concerned about making sure users approach the
process of using the development tree with the right expectations than
I am about driving high numbers of testers into the testing process
just to be ground up into dogfood.  And I'm also concerned about
making sure novice testers have adequate familiarity with the rpm
system and related tools to deal with the very common packaging
problems that happen from day-to-day. I am quite frankly not
interested in a blanket encouragement of run-of-the-mill fedora
end-users eating rawhide if they are not prepared to deal with day to
day breakage.   A multitude of shallow bugreports from frustrated
users who came into contact with rawhide with the wrong expectations
is just going to overwhelm the process and cause a futher disconnect
between developers and users.

My thoughts so far as to how to prep users to use the development tree
as part of test release testing are summarized at:
http://fedoraproject.org/wiki/TestingManifesto

> Encourage them to file
> upstream bug reports more?.

This is highly dependant on the package.. and how 'stock' the package
is inside fedora.
Downstream patches can play a role in behavior, and as Jesse points
out some upstream projects are particularly fond of getting bug
reports caused by downstream patches. Determining whether or not a
downstream patch is involved requires examination of the fedora spec
file, something you can't expect end-users to do without some hand
holding.

-jef