Rawhide

[Panu Matilainen]

On 11/04/2012 02:32 AM, Kevin Fenzi wrote:
> So, I have been thinking about rawhide.
>
> I agree identifying the problems/issues would be good, and I think
> there's something we can do to help with that:
>
> Get a nice group of at least 10 or so folks who are active on this list
> to agree to run it full time on their main machine.
>
> As we get close to F18 release, I am considering moving my full time
> laptop to rawhide. If I can get a group of folks to do likewise we can
> at least identify issues faster and help each other as they come up.
>
> Additionally, if some number of these folks who pledge to run rawhide
> full time were provenpackagers we could just go in and fix things as
> they hit (or soon after) instead of waiting a while for fixes to go
> out.
>
> I've run a rawhide vm/test machine here for many years. It's hit it's
> share of problems, but none were insurmountable. Some of them might
> have been for folks who were not more experienced tho, so increasing
> communication around rawhide can only help, IMHO.
>
> Additional thoughts to help rawhide:
>
> - It's been suggested before, but could we practically keep N and N-1
>    packages in rawhide repos? Then 'yum downgrade' becomes much more
>    handy. Repodata size and mirror size might shoot that down though.

Setting keepcache=1 in yum.conf helps somewhat: 'yum downgrade' wont 
work but it'll ensure you do have something to downgrade to, even if it 
has to be done manually.

>
> - Autoqa could perhaps help out, but I am not holding my breath. ;)

Yeh, autoqa can't do a whole lot when its builds often intentionally 
dependencies break (eg soname bumps). Unless such builds were required 
to be done in a staging area - this is *possible* already but not much 
used. It'd have to be reasonably convenient for the developers though, 
IIRC this requires rel-eng intervention currently.

Another means to achieve dependency sanity could be a separate 
rawhide-derived repository, where packages can only enter (and would 
automatically do so) once their dependencies are satisfied.
Or perhaps more akin to the common fedora workflow: make rawhide builds 
initially enter a rawhide-testing repo, from which they "graduate" to 
the actual rawhide once defined criteria (such as dependency closure) is 
met.

The broken dependencies report from branched makes me cringe every 
single time I see it: packages with broken dependencies should really 
not be allowed to enter it at all. Rawhide as it is now is a different
story, but if we expect people to actually use it then it should be kept 
in a saner state. yum's --skip-broken helps but its not really up to the 
task for the massive, constant brokenness of rawhide.

All that easier said than done of course. And would mean we end up with 
even more repositories, not less.

>
> - Anaconda folks haven't wanted rawhide installer images as they cause
>    people to report bugs on things when not ready, etc. However, could
>    we build nightly cloud images at least? Those could help test things
>    and won't require hitting the installer path.

Anaconda has a pretty special status then, nobody else can exempt 
themselves from rawhide. Installer images *are* obviously different from 
everything else in many ways but still... if images are only ever 
getting generated for branched, it means lost opportunities for finding 
and fixing bugs *before* entering branched stage. This is yet another 
case (and I assume to no small degree, a consequence) of the skewed 
situation where actual development ends up occurring in branched stage.

This very much relates to Jesse's comment early in the anaconda-thread:
(http://lists.fedoraproject.org/pipermail/devel/2012-October/173247.html)

"I think we need to give developers more time for feature integration
after the feature freeze."

I can easily understand anaconda wanting (and needing, really) to be 
exempt from early rawhide stages, but there should (I think) be a 
reasonable period before branch-point where images are being built. 
Making that possible (and sane for anaconda developers) requires changes 
to how things are done though, there can be no anaconda-breaking 
features (or other changes) crash-landing in the very last minute then.

> - I'm sure there's more ideas to improve it...

Increased communication couldn't hurt: soname bumps are fairly well 
communicated, other kinds of breakage could use similar announcements. 
Some people do it already (kudos to them), but I think we should see 
more of that. Besides "world is going to break tomorrow or the day 
after" heads-ups, it should help overall planning if we had some kind of 
"in this cycle, we're planning to do ... with package(set) X" summaries 
from maintainer(-group)s / SIGs. Even if its just "nothing beyond basic 
bugfixes expected", it'd mean people relying on that particular package 
would know they have one less thing to worry about. Perhaps such 
plan-summaries at beginning of development cycle could/should be 
mandated for critical path packages.
The feature process is supposed (I guess) to provide some of this 
coordination and communication but its far too heavy-weight for many 
things and at least to me, far too detached from the day-to-day 
development work. And it certainly does not have a place for "no big 
changes expected" information, except for not being a feature, but as it 
is that means absolutely nothing...

	- Panu -