[CentOS-devel] iSCSI Enterprise Target

On Aug 7, 2009, at 9:46 AM, Ross Walker <rswwalker at gmail.com> wrote:

> On Aug 6, 2009, at 12:36 PM, Karanbir Singh <mail-lists at 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