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 -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
