On 5/16/07, Nigel Jones <dev@xxxxxxxxxx> 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 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
