I was wondering if there was room in 'extras' for IET?
If there is interest let me know and I can supply/maintain the packages.
Just need to modify them to track kernel API.
-Ross
On 08/03/2009 10:38 PM, Ross Walker wrote:
I was wondering if there was room in 'extras' for IET?
If there is interest let me know and I can supply/maintain the packages.
Just need to modify them to track kernel API.
sure!
On Mon, Aug 3, 2009 at 7:01 PM, Karanbir Singhmail-lists@karan.org wrote:
On 08/03/2009 10:38 PM, Ross Walker wrote:
I was wondering if there was room in 'extras' for IET?
If there is interest let me know and I can supply/maintain the packages.
Just need to modify them to track kernel API.
sure!
Ok, then, is there a procedure outline for submission and maintenance that I should follow?
-Ross
On 08/04/2009 12:30 AM, Ross Walker wrote:
Ok, then, is there a procedure outline for submission and maintenance that I should follow?
Nothing that allows you to get anything done 'easily', but perhaps this is a good chance for us to fix that problem.
On Aug 5, 2009, at 7:50 AM, Karanbir Singh mail-lists@karan.org wrote:
On 08/04/2009 12:30 AM, Ross Walker wrote:
Ok, then, is there a procedure outline for submission and maintenance that I should follow?
Nothing that allows you to get anything done 'easily', but perhaps this is a good chance for us to fix that problem.
Ok, I'll play.
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 puts the pressure on the maintainer to make sure it is thoroughly tested for all supported architectures and releases that they support.
-Ross
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)
A policy can then be drafted on how and what moves from testing to stable. Where stable could be either Extras/ Contrib/ or Plus/.
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 ?
- KB
(1) might need some thinking around howto vaccumme and also resources on that dev.c.o machine - perhaps something to storm over later.
Dear Karan,
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)
That sounds very nice...
A policy can then be drafted on how and what moves from testing to stable. Where stable could be either Extras/ Contrib/ or Plus/.
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 ?
.. and would work at least for me ;)
Best Regards Marcus
Dear Karan,
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)
Do you think we could move further .spec/SRPM review to the bugtracker? Is it possible to attach the necessary files there?
And what about non-free contributions. Will they make it to "Contrib" or will there be something like "Contrib-nonfree"?
Best Regards Marcus
On 08/07/2009 07:37 AM, Marcus Moeller wrote:
Do you think we could move further .spec/SRPM review to the bugtracker? Is it possible to attach the necessary files there?
I dont personally like the review process at all. Its flawed by the fact that its only ever cycled through once. We would need some other means for initial-import. Who knows, perhaps the best means would be a initial proposal via the bugtracker, picked up by 'sponsor' and passed into the build process as required.
And what about non-free contributions. Will they make it to "Contrib" or will there be something like "Contrib-nonfree"?
For the time being, until there is some way to 'manage non free' in a reasonable way, lets stay clear.
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?
-Ross
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
-
Johnny Hughes -
Karanbir Singh -
Marcus Moeller -
Ralph Angenendt -
Ross Walker