On Aug 7, 2009, at 9:46 AM, Ross Walker rswwalker@gmail.com wrote:
On Aug 6, 2009, at 12:36 PM, Karanbir Singh mail-lists@karan.org wrote:
Ross Walker wrote:
Ok, I'll play.
Excellent!
How about, package maintainers will test that their package works correctly on all architectures and platforms their package supports, they will then submit the SRPM to enter in the next "scheduled" build cycle, if it builds clean they should hear nothing, but if it fails they should get the error report emailed back to them, they will then need to fix and re-submit for the next build cycle. The CentOS team will discard any new SRPMs that fail to build.
This sort of a thing is easy, let me also plumb in a few more bits : people get 'version control' access, and can then submit and track packages in there, tag'g for builds - and results being immediately visible. With an automated just-build repo's that can be ( should be ? ) public. Allowing people to do whatever and how many ever builds they fancy before actually moving their packages ( and they should be able to do this on their own - with an automated process ) into the testing repo's on dev.centos.org (1)
Heh, as long as your lips aren't writing checks that...
Honestly, if you think the project has the resources to pull off such then, yes, that would be great. Otherwise I would also take a stripped down process for submittal.
The key is to get all this great enterprise class software out to users of CentOS.
A policy can then be drafted on how and what moves from testing to stable. Where stable could be either Extras/ Contrib/ or Plus/.
Yes, I think policy should come first, then process.
I think if the core devs talk it out there is probably an informal policy already in place. Just need to write it down and have a quorum agree to it.
This puts the pressure on the maintainer to make sure it is thoroughly tested for all supported architectures and releases that they support.
Sure, that works - however we can all share the pain a bit. The tricky situation however is going to be working out what is a workable packaging standard we could / would adopt. No reason why we cant go with the Fedora churnout. If that works for everyone ?
Really don't know how Fedora does it.
I think the key here is to try and get a simple policy together at the next dev meeting that most can agree on and then put it up on the wiki under contributions. Need to decide what falls under 'extras' and what under 'contrib'. Maybe staple enterprise software under 'extras' and a potpouri of software under 'contrib'. Maybe tighter control of what's under 'extras' then what's under 'contrib'. That's really for you guys to hammer out.
Once a policy is in place you can see what resources are available for a process which you can document and put on the wiki too under the policy.
In the meantime is there a core developer who would like to sponsor me to get this into testing?
Actually that's not a bad process.
An established developer can "sponsor" an outsider's contribution, where that sponsor will be responsible for working with the outsider in getting his/her package in shape for submital. Then submitting it on behalf of the outside contributor. Working with them to get it into testing and if/when it makes it to stable keeping in touch with that outsider about updates, fixes, etc. If the outsider disappears then the package will be marked as unmaintained and if nobody is willing to pick it up after a given time frame then it will be marked as depreciated, and if nobody stands up to maintain it after another time frame it will be pulled.
That's another idea to float around.
It may provide better accountability and reputaion for contibutions.
-Ross