Update System: Not Rawhide

Jeff Spaleta jspaleta at gmail.com
Thu May 17 06:07:43 UTC 2007


On 5/16/07, Nigel Jones <dev at nigelj.com> wrote:
> I think this can lead to an improved workflow (yes I realise it ends up
> into 4 maintained branches at any one time, and if a maintainer finds
> him/herself strapped for time to make changes in all 4 branches, then they
> should feel free to add co-maintainers.

Uhm you make it sound like co-maintainers are an infinite resource.
I'm here to tell you that they aren't.  Co-maintainers aren't pogs or
AOL cds.  If the workload increases for all maintainers, then you are
effectively pulling manhours away from the available labor pool that
could be used for wider co-maintainership activity.

Do we have a reasonable way yet to add a co-maintainer on packages who
isn't aren't already a primary maintainer on at least one package? I'd
love to pull in people from outside the existing Fedora contributor
space who know the software I act as a primary maintainer for and
train them up to be competent package monkeys, giving them specific
co-maintainership duties, without having them go through the standard
sponsorship process through package submission.

For the crap I maintain... I don't need other people who are
reasonable good at maintaining Fedora packages. I need to build
relationships with people who know how to grok the codebase inside the
packages and get them hooked into the process of maintainership in
Fedora space with me acting as the gatekeeper to ensure Fedora
packaging policies are observed.  As long as the same level of
contributor sponsorship status is required for primary maintainers as
well as co-maintainers..all we are doing is redistributing the
available sponsored contributor labor force and not adding a new pool
of labor.  I am the package monkey, I've got that role pretty much
covered. What I need are code monkeys (preferably of the genus
upstreamum gurunish ) who can help me patch bugs on an as needed
basis.

Beyond that little rant, I don't see how an additional branching aids
in workflow. You have to have some very specific and very agreed on
doctrine on how the pre-release and development branches interact...
and a ninja-grade QA process to shadow the pre-release branching...
and universal respect for stabilization policy enforcement. Now I have
high hopes for Will and the QA process, but policy enforcement is and
will be a huge problem for what is essentially a volunteer managed
software collection.

Adding yet another branch meant for stabilization doesn't
automatically prevent crap from breaking in an untimely manner. We
don't have anything close to a demarcation of tiers in the software
stack by which we can incrementally clamp down a stabilization policy.
And even if we did, there isn't a real policy enforcement model in
place to 'encourage' maintainers to stick to a structured
stabilization process that 'discourages' significant changes in
fundamental tiers of the software stack. And even if we did,
structured stabilization processes take longer...longer than we
actually have.  Late breaking fixes going in to the stabilization tree
will undoubtedly cause regressions that require additional
fixes...just like you see in rawhide.  We do not have the laborforce,
the timescale, nor the centralized management enforcement mechanisms
to make a dedicated controlled stabilization branch mean anything
other than a version of rawhide that is on average harder to get
changes pushed into than rawhide is.

I'll tell you right now... even with the few packages I have...
there's a snowball's chance in hell that I'd be able to keep up with
updating into additional pre-release branches as well as development.
And a bigger snowball's chance that I'd have spare cycles to take on
additional co-maintainership duties beyond the packages that I am
primary owner for. If there is a very early split for the next
release, I will undoubtedly be forced to choose where i spend what
time I have between updating devel,pre-release updating,reviewing new
or god-forbid lingering merge reviews,and prepping my own new
packaging.  Someone is going to have to do a pretty damn good sales
pitch to convince me that a pre-release branch is worth my time to
update compared to rawhide.

-jef"man i love my new postdoc... i'm writing python bindings over C
code.. so I can work with the radar data with scipy and
friends....specifically to avoid having to do the data analysis in IDL
or matlab and watching money get burned on yet another per-seat
software license just to draw pretty graphs of auto-correlation
functions."spaleta




More information about the Fedora-maintainers mailing list