On 10/07/2010 00:41, Ned Slider wrote:
Any news on the pending security updates?
As posted on the irc channel, the backlog will clear by monday.
- KB
Dne 10.7.2010 19:55, Karanbir Singh napsal(a):
On 10/07/2010 00:41, Ned Slider wrote:
Any news on the pending security updates?
Are you also talking about http://bugs.centos.org/view.php?id=4386? This is something which makes me unhappy. There is almost a month gap with CentOS4 updates. DH
On 07/12/2010 07:33 AM, David Hrbáč wrote:
Are you also talking about http://bugs.centos.org/view.php?id=4386? This is something which makes me unhappy. There is almost a month gap with CentOS4 updates.
Yes, I'm just looking at those as well. Tru has finished all the builds as far as I can see, just needs me to test and push.
- KB
On Wed, Jul 21, 2010 at 7:44 AM, David Hrbáč hrbac.conf@seznam.cz wrote:
Dne 13.7.2010 0:18, Karanbir Singh napsal(a):
Yes, I'm just looking at those as well. Tru has finished all the builds as far as I can see, just needs me to test and push.
- KB
Any news?!? DH
Not sure if it was just a coincidence, but I also just added a note to the bug report:
http://bugs.centos.org/view.php?id=4386
Akemi
On 07/21/2010 03:44 PM, David Hrbáč wrote:
Dne 13.7.2010 0:18, Karanbir Singh napsal(a):
Yes, I'm just looking at those as well. Tru has finished all the builds as far as I can see, just needs me to test and push.
Any news?!?
Tru has done the builds this morning, I'll do the push later today provided the builds pass tests. As far as I can see, all the pending updates are built already
- KB
Dne 21.7.2010 16:52, Karanbir Singh napsal(a):
Yes, I'm just looking at those as well. Tru has finished all the builds as far as I can see, just needs me to test and push.
Any news?!?
Tru has done the builds this morning, I'll do the push later today provided the builds pass tests. As far as I can see, all the pending updates are built already
- KB
Sounds like some fuzzy bot... DH
On 07/21/2010 04:09 PM, David Hrbáč wrote:
Tru has done the builds this morning, I'll do the push later today provided the builds pass tests. As far as I can see, all the pending updates are built already
- KB
Sounds like some fuzzy bot...
it is, I've not looked at the details of the specs. Will do that once I leave from work later today.
- KB
On Wed, 21 Jul 2010, Karanbir Singh wrote:
On 07/21/2010 03:44 PM, David Hrbáč wrote:
Dne 13.7.2010 0:18, Karanbir Singh napsal(a):
Yes, I'm just looking at those as well. Tru has finished all the builds as far as I can see, just needs me to test and push.
Any news?!?
Tru has done the builds this morning, ...
There seems to be a systematic process issue that the CentOS project should address. There shouldn't be a single point of failure. I would think that more tech resources are available to you if you ask.
Hi all.
On Wed, 21 Jul 2010, Karanbir Singh wrote:
On 07/21/2010 03:44 PM, David Hrbáč wrote:
Dne 13.7.2010 0:18, Karanbir Singh napsal(a):
Yes, I'm just looking at those as well. Tru has finished all the builds as far as I can see, just needs me to test and push.
Any news?!?
Tru has done the builds this morning, ...
There seems to be a systematic process issue that the CentOS project should address. There shouldn't be a single point of failure. I would
At least we got one single point of failure per release :)
Greets Marcus
Btw. doesn't Tru take part in ML discussion and speak for himself?
On 07/21/2010 05:21 PM, Marcus Moeller wrote:
Btw. doesn't Tru take part in ML discussion and speak for himself?
He's in the process of moving homes, and has limited internet access at the moment. I'm supposed to be covering for him ( and doing a bit of a crap job at the moment )
- KB
On Wed, Jul 21, 2010 at 05:27:33PM +0100, Karanbir Singh wrote:
On 07/21/2010 05:21 PM, Marcus Moeller wrote:
Btw. doesn't Tru take part in ML discussion and speak for himself?
He's in the process of moving homes, and has limited internet access at the moment. I'm supposed to be covering for him ( and doing a bit of a crap job at the moment )
Thanks Karanbir :)
I have been very busy these last weeks with my $paid work... and I am on (well deserved) holidays now. By the way I have another priority which consists of changing home in the next days. So I will probably have very limited internet access until my home adsl line is installed again. My CentOS "duty" is a best effort agreement I have agreed. Since I can only have 24h/day I made some choices. I guess that we all need to do that sometimes :D
Cheers.
Tru
Dear Tru,
Btw. doesn't Tru take part in ML discussion and speak for himself?
He's in the process of moving homes, and has limited internet access at the moment. I'm supposed to be covering for him ( and doing a bit of a crap job at the moment )
Thanks Karanbir :)
I have been very busy these last weeks with my $paid work... and I am on (well deserved) holidays now. By the way I have another priority which consists of changing home in the next days. So I will probably have very limited internet access until my home adsl line is installed again. My CentOS "duty" is a best effort agreement I have agreed. Since I can only have 24h/day I made some choices. I guess that we all need to do that sometimes :D
Thanks for the update.
Greets Marcus
On Wed, 21 Jul 2010, Charlie Brady wrote:
Tru has done the builds this morning, ...
There seems to be a systematic process issue that the CentOS project should address. There shouldn't be a single point of failure. I would think that more tech resources are available to you if you ask.
The lead CentOS devels have a redesign for some more 'trellising' in front of them presently.
There is a entire workflow and QA to this which needs to be done right, or we might, (for example) introduce possible mirror skews and potentially unsolveable dependency holes requiring manual problem solving on literally millions of machines. We dare not risk such slipping into our process
-- Russ herrold
On Wed, 21 Jul 2010, R P Herrold wrote:
On Wed, 21 Jul 2010, Charlie Brady wrote:
Tru has done the builds this morning, ...
There seems to be a systematic process issue that the CentOS project should address. There shouldn't be a single point of failure. I would think that more tech resources are available to you if you ask.
The lead CentOS devels have a redesign for some more 'trellising' in front of them presently.
There is a entire workflow and QA to this which needs to be done right, or we might, (for example) introduce possible mirror skews and potentially unsolveable dependency holes requiring manual problem solving on literally millions of machines. We dare not risk such slipping into our process
But unpatched security holes is OK? ;-)
I do respect what you are saying, but I don't see evidence that final QA and pushing to mirrors is what is holding up these updates.
On 07/21/2010 04:52 PM, Charlie Brady wrote:
There seems to be a systematic process issue that the CentOS project should address. There shouldn't be a single point of failure. I would think that more tech resources are available to you if you ask.
I am not sure what you are talking about. I've asked for help with specific things in the past - and got back almost nothing. Its always the same few people, doing the best that we can.
- KB
On 07/21/2010 02:31 PM, Karanbir Singh wrote:
I am not sure what you are talking about. I've asked for help with specific things in the past - and got back almost nothing. Its always the same few people, doing the best that we can.
That could be. I'm not sure which specific things you're referring to. I vaguely recall frequent volunteers to engage in the build/test/release process met with the pronouncement that CentOS's team is a meritocracy and that people will be allowed in as they prove their worth. The trouble seems to be that no one knows how to demonstrate their value. The CentOS team's workings seem opaque to me. Since I don't know anything about them, I realize that any idea I have about how to improve them may be completely invalid. However, I think a lot of users would be happy if CentOS were as transparent as Fedora, with clear written guidelines regarding the project governance and processes. In fact, I think it'd be wonderful to adopt Fedora's guidelines and technology as much as possible.
On 07/22/2010 04:25 AM, Gordon Messmer wrote:
That could be. I'm not sure which specific things you're referring to. I vaguely recall frequent volunteers to engage in the build/test/release process met with the pronouncement that CentOS's team is a meritocracy and that people will be allowed in as they prove their
Yes, thats about right. The idea of testing stuff within CentOS has a very finite end point. With very few exceptions the only people trying to get onto the testing team are people looking for early access. There have only ever been a small number of people who actually do anything. I would love, more than anything else at this time, to have a large and productive testing team - but one that actually does something.
Opening up the list to public and opening up access to the testing repo's and hoping for the best is not only a stupid idea, its also a massive waste of resources. But still its the only solution people seem to come up with when I pitch this problem to them. So we carry on with our solution in place right now -> invite people we know and recognise to be people interested in helping. So visibility cluefull people from the community here. And dont be mistaken : plenty have declined. Which is fine, everyone has their own agenda and life to live.
And there is plenty of places for new people who have not been involved with the project in the past, or any other project for that matter. eg. if someone was to step up and maintain a section in the wiki for the cluster suite / cluster storage stack included in CentOS - he/she would be welcome to join the QA team and help with with that resource and setup tests / testing around that resource. Cluster* is just an example, there are millions of other niche's similar to this.
worth. The trouble seems to be that no one knows how to demonstrate their value. The CentOS team's workings seem opaque to me. Since I don't know anything about them, I realize that any idea I have about how to improve them may be completely invalid.
If you just have generic ideas, I think its best to pass. But if you have ideas and are willing to back those ideas up with an offer to actually execute at least some part of the work involved with that - then this list is the place to be talking about those.
However, I think a lot of users would be happy if CentOS were as transparent as Fedora, with clear written guidelines regarding the project governance and processes. In fact, I think it'd be wonderful to adopt Fedora's guidelines and technology as much as possible.
Fedora and CentOS work with and against very different roles, background, contributions and even infrastructure. So expecting CentOS to get into the same groove as Fedora is'nt even worth thinking about. Not at this stage, and not till there are massive changes in what we do, how we do it, why we do it and where we do it.
I don't personally see any of those frames changing too far at the moment, but then I've been surprised in the past and am quite open to being surprised again :)
- KB
On Thu, 22 Jul 2010, Karanbir Singh wrote:
On 07/22/2010 04:25 AM, Gordon Messmer wrote:
That could be. I'm not sure which specific things you're referring to. I vaguely recall frequent volunteers to engage in the build/test/release process met with the pronouncement that CentOS's team is a meritocracy and that people will be allowed in as they prove their
Yes, thats about right. The idea of testing stuff within CentOS has a very finite end point. With very few exceptions the only people trying to get onto the testing team are people looking for early access. There have only ever been a small number of people who actually do anything. I would love, more than anything else at this time, to have a large and productive testing team - but one that actually does something.
I don't think the problem here is either the size or the idleness of the test team. What are the steps involved in building/validating/testing/releasing security updates? I don't know. Which steps have been completed and which steps are still to be done. I don't know. Is the bottleneck the testing team? I don't think so.
What we do know are that Tru has been unavailable for various reasons and Karanbir is "supposed to be covering for him (and doing a bit of a crap job at the moment)". These things happen, and I don't wish to attach personal blame. But I think it is also useful to acknowledge that these are the reasons for the non-released packages, rather than talk about testing resources or opportunities for people to contribute to the wiki.
As I stated earlier, I think there is systematic process issue that the CentOS project should address. I'm not sure whether you are saying that there isn't a problem, or that the problem exists but is not solveable. I don't think either response is appropriate. Wouldn't it be more useful to admit that there is a problem, and discuss exactly what needs to be done to solve it?
[I'm trying to be constructive here, so please don't be defensive. Russ can vouch for me. I don't just wish to be spoonfed, and I do know what it is like to ask for help and receive little. I just don't see that as the problem here.]
--- Charlie
On Jul 22, 2010, at 2:29 PM, Charlie Brady wrote:
On Thu, 22 Jul 2010, Karanbir Singh wrote:
On 07/22/2010 04:25 AM, Gordon Messmer wrote:
That could be. I'm not sure which specific things you're referring to. I vaguely recall frequent volunteers to engage in the build/test/release process met with the pronouncement that CentOS's team is a meritocracy and that people will be allowed in as they prove their
Yes, thats about right. The idea of testing stuff within CentOS has a very finite end point. With very few exceptions the only people trying to get onto the testing team are people looking for early access. There have only ever been a small number of people who actually do anything. I would love, more than anything else at this time, to have a large and productive testing team - but one that actually does something.
I don't think the problem here is either the size or the idleness of the test team. What are the steps involved in building/validating/testing/releasing security updates? I don't know. Which steps have been completed and which steps are still to be done. I don't know. Is the bottleneck the testing team? I don't think so.
In general, everyone doesn't really know what is contained in a "security" fix.
The details of a "security" fix are typically only summarized, and one is expected to be able to infer from the patch the relevance to the underlying security issue.
The harder (general, true for all distros, not just CentOS) is the release engineering involved. For starters -- because its "security" related -- the priority and timeliness are important.
However security fixes are invariably "out-of-band" in the sense that there's never enough time and resources to run through a full QA integration cycle. So the release engineering involves shrewd/savvy guessing that nothing else is gonna be broken by distributing the patch.
There's the further procedural risk of mis-building. Keeping build systems in perfect condition gets trickier and trickier as distros (like CentOS5) age. All security patches need to be applied as well as the original release. Any new package build relies on having a build system sufficiently close to be able to rebuild reliably.
While of the above may seem obvious, the specific points are 1) there are no steps and there is no process. Instead its savvy guesses and spot checks and triple checks. 2) the bottleneck _IS_ in some sense the testing team, who are expected to achieve the pretense of "perfection" in spite of the "out-of-band" QA procedures involved. You really start to think hard and carefully before claiming WORKSFORME when your reputation is at stake. Its embarassing when some silly error has to be re-released or re-re-re-re-released to achieve the desired "security" fix goal.
What we do know are that Tru has been unavailable for various reasons and Karanbir is "supposed to be covering for him (and doing a bit of a crap job at the moment)". These things happen, and I don't wish to attach personal blame. But I think it is also useful to acknowledge that these are the reasons for the non-released packages, rather than talk about testing resources or opportunities for people to contribute to the wiki.
As I stated earlier, I think there is systematic process issue that the CentOS project should address. I'm not sure whether you are saying that there isn't a problem, or that the problem exists but is not solveable. I don't think either response is appropriate. Wouldn't it be more useful to admit that there is a problem, and discuss exactly what needs to be done to solve it?
There are several levels of problem, but the hardest problem is figgering How much "out-of-band" QA is sufficient? That comes only from experience. There are other elements -- no different for any process that involves humans -- of vacations and moves and attention interrupts and more. But "security" fixes are usually only spot checked that indeed, the security issue is "fixed", and the release process is assumed to be just cookie-cutter gear-turning which it often is not, because older distros like RHEL5 get increasingly more complex to maintain reliably as they age.
[I'm trying to be constructive here, so please don't be defensive. Russ can vouch for me. I don't just wish to be spoonfed, and I do know what it is like to ask for help and receive little. I just don't see that as the problem here.]
I hope my comments don't qualify as "spoonfeeding", they certainly weren't intended as such.
Security "fixes" are a hard problem to solve in _ALL_ distros, not just CentOS.
73 de Jeff
On 7/22/2010 2:09 PM, Jeff Johnson wrote:
There are several levels of problem, but the hardest problem is figgering How much "out-of-band" QA is sufficient? That comes only from experience.
Yes, but the other thing that comes from experience is knowing that experienced people are very hard to find if you wait until you need them to start looking.
On 07/22/2010 08:30 PM, Les Mikesell wrote:
Yes, but the other thing that comes from experience is knowing that experienced people are very hard to find if you wait until you need them to start looking.
I completely agree with that. People who care about the project and want to be involved with the project will mostly be those who are around over a period of time. Drive-by's are plenty to be had, but they only leave wrecks behind.
- KB
On Thu, 22 Jul 2010, Jeff Johnson wrote:
In general, everyone doesn't really know what is contained in a "security" fix.
Whether true or not in general, that doesn't apply here. Anyone can see exactly what is in the source code released upstream.
The details of a "security" fix are typically only summarized, and one is expected to be able to infer from the patch the relevance to the underlying security issue.
Probably, but I don't think that is under discussion here.
The harder (general, true for all distros, not just CentOS) is the release engineering involved. For starters -- because its "security" related -- the priority and timeliness are important.
timeliness *appears* not to be important to the CentOS project, hence this discussion.
However security fixes are invariably "out-of-band" in the sense that there's never enough time and resources to run through a full QA integration cycle. So the release engineering involves shrewd/savvy guessing that nothing else is gonna be broken by distributing the patch.
There's the further procedural risk of mis-building. Keeping build systems in perfect condition gets trickier and trickier as distros (like CentOS5) age. All security patches need to be applied as well as the original release. Any new package build relies on having a build system sufficiently close to be able to rebuild reliably.
Yes, but isn't this core business for the CentOS project, and apply equally to point releases as it does for security updates?
While of the above may seem obvious, the specific points are
- there are no steps and there is no process. Instead
its savvy guesses and spot checks and triple checks.
I would hope that there are some standard steps, rather than a totally ad-hoc process.
- the bottleneck _IS_ in some sense the testing team,
who are expected to achieve the pretense of "perfection" in spite of the "out-of-band" QA procedures involved. You really start to think hard and carefully before claiming WORKSFORME when your reputation is at stake. Its embarassing when some silly error has to be re-released or re-re-re-re-released to achieve the desired "security" fix goal.
I have seen no evidence that the testing team is the bottleneck here.
Security "fixes" are a hard problem to solve in _ALL_ distros, not just CentOS.
My expectation is that it is actually an easier problem for CentOS. They don't need to consider whether it is the correct or best fix, just whether it has been built correctly, and produces build output "sufficiently similar" to that produced by upstream.
--- Charlie
On Thu, 22 Jul 2010, Charlie Brady wrote:
The harder (general, true for all distros, not just CentOS) is the release engineering involved. For starters -- because its "security" related -- the priority and timeliness are important.
timeliness *appears* not to be important to the CentOS project, hence this discussion.
Not intended to be a smear - please see timeline @
http://bugs.centos.org/view.php?id=4386
--- Charlie
On Thu, 22 Jul 2010, Charlie Brady wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
timeliness *appears* not to be important to the CentOS project, hence this discussion.
Not intended to be a smear - please see timeline @
And this the week after OLS. Et tu? Ah well.
Sure it is a data point and I suppose 'we' of CentOS are supposed to promise to never disappoint whomever again.
Tough. Not me, thank you. This is a labor of love, and if you want commercial SLA's you'll have to buy them from me. Prices on request of a serious offer to purchase http://www.owlriver.com/wings/
You know, folks both here, and in the narrower centos-qa subgroup participate on SME, and the recent new re-fork. I don't recall seeing invites there for community folks in general, not to me specifically, nor and 'timeliness metrics' and that implicit criticism. I certainly have participated in SME and in other projects without expectation of some 'reward' of invitation into some inner circle there, and I have not been disappointed measuring against my expectations as a result
Success succeeds. By the metrics I care about, CentOS is successful. I refuse to battle semantics about 'Community' and the visions some dream of some Utopian land of free milk and honey. We ship -- we have documented -- we more than meet our GPL obligations. If a consumer of our product does not like how it is provided, they can go buy a alternative, or start their own project, and run it by their lights. I am certain I've stated that pretty clearly in my blogging as well
One person comes to mind who stomped off the project very publicly, and will not be invited back. Their choice. I would not try to stop them, and will respect my relationship with the others who comprise the core of the CentOS process. We may not agree on all matters, but I think that those who remain there all agree that we will celebrate success publicly, and address failures privately
Freedom is like that in that we cannot enforce involuntary service, any more than that person can pry the door once freely opened, back open again. A needed trust relationship is gone like a soap bubble
I would like a future with a CentOS even more successful, and that fosters others on that, and so have published chrooted, and non-chrooted buildsystems code since the cAos days. Heck my latest post aggregated on http://planet.centos.org/ is quite clear on my hopes.
I would also like a pink pony and a fine single malt Scotch. [contact me privately if you wish to send a paypal gift to fund either of those last two goals] That code I long ago published is wholly sufficient, with minimal scripting glue, for any rebuild project not needing to solve cross-compiling [a space I am working in atm for my Pogoplug/ Shiva/ Marvell / Dockstar units]
I cannot alter how others choose to repaint the field lines to their taste, any more than I could mask the racket from those 'vuvuzela'
* shrug *
-- Russ herrold
On Thu, 22 Jul 2010, R P Herrold wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
timeliness *appears* not to be important to the CentOS project, hence this discussion.
Not intended to be a smear - please see timeline @
And this the week after OLS.
Yes, I missed you.
Et tu? Ah well.
Sure it is a data point and I suppose 'we' of CentOS are supposed to promise to never disappoint whomever again.
Of course not.
However, it is your choice whether you respond by saying "yes, we can try to do better. Would you like to help?", or "tough luck. That's the way it is. Take it or leave it."
I would like a future with a CentOS even more successful, ...
Well, recognizing areas which are currently sub-optimal and trying to find improvements would likely help in achieving that.
On Thu, 22 Jul 2010, Charlie Brady wrote:
However, it is your choice whether you respond by saying "yes, we can try to do better. Would you like to help?", or "tough luck. That's the way it is. Take it or leave it."
framing responses is not free and constrains future actions
... I do not see the benefit of building the needed structures for safe partiticipation by untrusted newcomers outweighs the cost and risk to the current folks who depend on the project. If someone wants to fund 6 months of my time, I'll take a run at it
-- Russ herrold
On 07/22/2010 11:25 PM, Charlie Brady wrote:
However, it is your choice whether you respond by saying "yes, we can try to do better. Would you like to help?", or "tough luck. That's the way it is. Take it or leave it."
I dont see your point. I've asked for help and got f*ckall in return from people who were not already doing a lot of the work in the group. Lets call them the regulars. And there are maybe 2 dozen such people.
So exactly where are these hordes of helpers you seem to hint at ? There are plenty of people who seem keen on offering advise, but they can feel free to excuse themselves :)
- KB
Hi Karan.
However, it is your choice whether you respond by saying "yes, we can try to do better. Would you like to help?", or "tough luck. That's the way it is. Take it or leave it."
I dont see your point. I've asked for help and got f*ckall in return from people who were not already doing a lot of the work in the group. Lets call them the regulars. And there are maybe 2 dozen such people.
So exactly where are these hordes of helpers you seem to hint at ? There are plenty of people who seem keen on offering advise, but they can feel free to excuse themselves :)
So let's pick up some random task:
What about the forums migration. We have set up a complete merge script and just wait for some decisions how authentication should be handled in the future. No response till then.
And yes, maybe these things could be solved in a hackweek or so.
Greets Marcus
On 07/23/2010 03:06 PM, Marcus Moeller wrote:
What about the forums migration. We have set up a complete merge script and just wait for some decisions how authentication should be handled in the future. No response till then.
Where is this script ? When was it tested ? I've not seen either of those. w.r.t centralised auth, I believe Ralph has already worked with you Marcus to setup an ldap instance.
Or am I out of date ?
- KB
Dear Karan.
On 07/23/2010 03:06 PM, Marcus Moeller wrote:
What about the forums migration. We have set up a complete merge script and just wait for some decisions how authentication should be handled in the future. No response till then.
Where is this script ? When was it tested ? I've not seen either of
You may want to search your mail archive.
But anyway: http://wiki.centos.org/WebsiteVer2/forums/newbb_to_phpbb
those. w.r.t centralised auth, I believe Ralph has already worked with you Marcus to setup an ldap instance.
I have asked for help and your input about the creation of a user add frontend a while ago on the devel list, without response.
Greets Marcus
Hey
On Fri, Jul 23, 2010 at 3:15 PM, Marcus Moeller mail@marcus-moeller.de wrote:
But anyway: http://wiki.centos.org/WebsiteVer2/forums/newbb_to_phpbb
Can I see a live instance running somewhere? Just some test server? If not maybe we should set that up and clarify what is stopping us from doing so :)
I have asked for help and your input about the creation of a user add frontend a while ago on the devel list, without response.
Is that so hard? Can people not just create a user account somewhere and then it will be synced to the wiki, forum, etc ... and access control is then given in the individual apps or something around those lines. This must be a solved problem.
This has nothing to do with the actual thread maybe this should be moved to a new discussion.
Cheers Didi
On Fri, 23 Jul 2010, Marcus Moeller wrote:
Where is this script ? When was it tested ? I've not seen either of
I do not recall it being announced on any of the mailing lists either
You may want to search your mail archive.
You may want to adjust your attitude, Marcus -- If we have to search for it, it might as well not exist
-- Russ herrold
Dear Russ,
Where is this script ? When was it tested ? I've not seen either of
I do not recall it being announced on any of the mailing lists either
You may want to search your mail archive.
You may want to adjust your attitude, Marcus -- If we have to search for it, it might as well not exist
I am just sad of repeating these things continuously.
But if you prefer to:
Greets Marcus
On Fri, 23 Jul 2010, Marcus Moeller wrote:
I am just sad of repeating these things continuously.
But if you prefer to:
* plonk * thanks for confirming no such posts exists.
-- Russ herrold
Hi again.
I am just sad of repeating these things continuously.
But if you prefer to:
- plonk * thanks for confirming no such posts exists.
I am not sure what about:
http://lists.centos.org/pipermail/centos-devel/2009-November/005217.html http://osdir.com/ml/centos-devel/2009-09/msg00152.html
and a lot of others, so plonk someone else.
Besides that I am happy if one like Didi is willed to help out.
Greets Marcus
On Fri, 23 Jul 2010, Marcus Moeller wrote:
What about the forums migration. We have set up a complete merge script and just wait for some decisions how authentication should be handled in the future. No response till then.
And yes, maybe these things could be solved in a hackweek or so.
I 'paid the price' of writing my requirements yet again [there is an earlie post to substantially the same effect by me out there] in a review outline' of the requirements checklist for that and invited a working test case what ... two months ago [25 May 2010]
http://lists.centos.org/pipermail/centos-devel/2010-May/005563.html
I would add [with the benefit of time and knowing what is happening in the broader Open Source world] to z00dax' comment, that it should support federated authentication [ldap,OpenID, whatever]; show a low attack surface history at the CVE; be in active maintenance or better, development; be in a language permitting addon extensibility without having to 'marry' the darn thing; and permit 'static' top pages to address 'slashdotting'. Does it integrate well with puppet, mailman, and stock CentOS tools; is it Free and Open Source software using CentOS stock supporting packages?
No test setup yet to review that I can see
-- Russ herrold
Le 23/07/10 15:57, Karanbir Singh a écrit :
On 07/22/2010 11:25 PM, Charlie Brady wrote:
However, it is your choice whether you respond by saying "yes, we can try to do better. Would you like to help?", or "tough luck. That's the way it is. Take it or leave it."
I dont see your point. I've asked for help and got f*ckall in return from people who were not already doing a lot of the work in the group. Lets call them the regulars. And there are maybe 2 dozen such people.
So exactly where are these hordes of helpers you seem to hint at ? There are plenty of people who seem keen on offering advise, but they can feel free to excuse themselves :)
- KB
I have a question on the tip of my tongue for months now, why Johnny Hughes -which was an older active member of centos- [seems to have] left the project.
JML
On 07/26/2010 03:38 PM, Jean-Marc Liger wrote:
I have a question on the tip of my tongue for months now, why Johnny Hughes -which was an older active member of centos- [seems to have] left the project.
That's a good question, if anyone speaks with him please do ask. He's not only been a great contributor to CentOS but also a good friend.
As far as I can tell, he's got other things on his plate at the moment and does not have the time and bandwidth for CentOS at the moment. And I hope he's doing well.
- KB
On 22/07/10 23:15, R P Herrold wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
timeliness *appears* not to be important to the CentOS project, hence this discussion.
Not intended to be a smear - please see timeline @
And this the week after OLS. Et tu? Ah well.
Sure it is a data point and I suppose 'we' of CentOS are supposed to promise to never disappoint whomever again.
Tough. Not me, thank you. This is a labor of love, and if you want commercial SLA's you'll have to buy them from me. Prices on request of a serious offer to purchase http://www.owlriver.com/wings/
I'm confused as to exactly what you are saying here. The CentOS Project FAQ states:
Q. How long after redhat publishes a fix does it take for CentOS to publish a fix?
A. Our goal is to have individual RPM packages available on the mirrors within 72 hours of their release, and normally they are available within 24 hours.
https://www.centos.org/modules/smartfaq/faq.php?faqid=7
Are you implying that you will provide security updates under a paid SLA agreement but not to the wider CentOS Community?
<snip>
- shrug *
-- Russ herrold _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Fri, 23 Jul 2010, Ned Slider wrote:
Tough. Not me, thank you. This is a labor of love, and if you want commercial SLA's you'll have to buy them from me. Prices on request of a serious offer to purchase http://www.owlriver.com/wings/
I'm confused as to exactly what you are saying here. The CentOS Project FAQ states:
Q. How long after redhat publishes a fix does it take for CentOS to publish a fix?
A. Our goal is to have individual RPM packages available on the mirrors within 72 hours of their release, and normally they are available within 24 hours.
Are you implying that you will provide security updates under a paid SLA agreement but not to the wider CentOS Community?
Stop being coy and a trolling Bozo -- Of course I do, and have for many many years, long predating CentOS -- if you are unaware of that you have not thought through the timing and the history
* shrug *
But, not under a CentOS signing key. The web content at 'wings' was written and updated long before RHEL ever existed, let alone CentOS. Progeny and I have pretty conclusively demonstrated that there is (or at least was) not a sustainable market for enterprise distributions maintenance (and Jesse Keating later as to a 'all packages' backport of security fixes as to FL) as a standalone matter, but rather such sales of services and SLA's occur as a 'pull along' to other consultancy work
Obviously other vendors are equally free to compete in the marketplace for selling such against me, just as I compete with Red Hat ... just as CentOS very consciously does NOT sell SLA backed update promises
Under a contract with third parties and backed and signed by an Owl River key, I do and have provided and will continue to cross-builds of [in part] publicly released Red Hat's SRPMs in advance of matter CentOS may later issue, since long before CentOS or cAos existed. I review a nightly mirroring report with 'diffs', and feed my personal buildsystems accordingly
My R side package module archive is several hundred large, covering essentially all of bioinformatics, finance, statistics and economics dependencies and all leaf nodes of merit for CRAN, RForge and Bioconductor. By comparison, RawHide seems to have 64 with indifferent attention to 'MAKE CHECK' at build time matters. The count is slightly high as this matches some non R content ls | grep ^R | wc
My most recent blog post series will conclude with a piece as to SRPM building and build environment [gawd, yet again], rpm keys and signing, local side archive building, adjunct yum repostitory setup, and Release number bumping to address the broken [as to spamassassin bleeding] perl-Tar-Net the upstream issued in the last couple of weeks. All for free, free, free
Paying customers of PMman have access to binaries, and all sources in the build chain, for a later git, the latest milter-greylist, other stuff. Some is similar to or based on parts from RPMforge, some to RawHide, and a lot is me doing dependency chain resolution, packaging, and content vetting to stablize such
[herrold@trap SRPMS]$ ls diskcheck-1.6-3orc.src.rpm fail2ban-0.8.1-11orc.src.rpm fail2ban-0.8.1-12orc.src.rpm fail2ban-0.8.4-24orc.src.rpm git-1.6.5.2-1orc.src.rpm incron-0.5.8-1orc.src.rpm keystone-spamassassin-1.00-1orc.src.rpm perl-Crypt-OpenSSL-Bignum-0.03-3orc.src.rpm perl-Crypt-OpenSSL-Random-0.04-2orc.src.rpm perl-Crypt-OpenSSL-RSA-0.25-10orc.src.rpm perl-Devel-Symdump-2.07-5orc.src.rpm perl-Digest-SHA-5.48-1orc.src.rpm perl-Encode-Detect-1.01-1orc.src.rpm perl-Error-0.17016-1orc.src.rpm perl-ExtUtils-CBuilder-0.22-1.rf.src.rpm perl-ExtUtils-ParseXS-2.15-1orc.src.rpm perl-IP-Country-2.26-2orc.src.rpm perl-Mail-DKIM-0.37-2orc.src.rpm perl-Mail-DomainKeys-1.0-1.rf.src.rpm perl-Mail-SPF-Query-1.999.1-3orc.src.rpm perl-Mail-SPF-v2.007-1orc.src.rpm perl-Mail-SRS-0.31-1.rf.src.rpm perl-Module-Build-0.2806-2.rf.src.rpm perl-Module-Signature-0.55-3orc.src.rpm perl-NetAddr-IP-4.004-2orc.src.rpm perl-Net-CIDR-Lite-0.20-3orc.src.rpm perl-Net-DNS-Resolver-Programmable-v0.003-1orc.src.rpm perl-Net-Ident-1.20-1.rf.src.rpm perl-PAR-Dist-0.25-1.orc.src.rpm perl-PAR-Dist-0.34-2orc.src.rpm perl-Pod-Coverage-0.18-1.rf.src.rpm perl-Pod-Escapes-1.04-1orc.src.rpm perl-Pod-Readme-0.081-3orc.src.rpm perl-Pod-Simple-3.04-1orc.src.rpm perl-Test-Pod-1.26-4orc.src.rpm perl-Test-Pod-Coverage-1.08-6orc.src.rpm perl-Test-Portability-Files-0.05-6orc.src.rpm perl-version-0.69-1orc.src.rpm perl-YAML-0.66-3orc.src.rpm razor-agents-2.81-2.fc4.rf.src.rpm repodata spamassassin-3.3.0-0.29.rc1orc.src.rpm spamassassin-3.3.0-5orc.src.rpm spamassassin-3.3.1-2orc.src.rpm [herrold@trap SRPMS]$
note: 'trap' is named for the comment by Admiral Ackbar in the first Star Wars, as in: "It's a ..."
I discontinued making signed binary content generally available, and withdrew general anonymous FTP access to such except as required by license, as a general rule, since before I captured this content [1] in '00 as part of implementing the strategy we came up with at the ORC Project 2000 retreat [2] or for a former ORC 'Live Wire' project. Certainly by RHL 6.2 days. What a nice release that was
The statement on the CentOS site, seemingly placed by donovan in late 2004, relates to CentOS [and contains some spam whch I'll go kill off shortly]. Donovan came to CentOS via Lance as I recall, ex WhiteBox, and I do not know particularly that that I was aware of that content. If I were, I would have corrected the form and capitalization of 'redhat' to an accurate one
-- Russ herrold
[1] http://www.owlriver.com/clippings/2000-10-17.309.html [2] http://www.owlriver.com/2000/
On 23/07/10 05:00, R P Herrold wrote:
On Fri, 23 Jul 2010, Ned Slider wrote:
Tough. Not me, thank you. This is a labor of love, and if you want commercial SLA's you'll have to buy them from me. Prices on request of a serious offer to purchase http://www.owlriver.com/wings/
I'm confused as to exactly what you are saying here. The CentOS Project FAQ states:
Q. How long after redhat publishes a fix does it take for CentOS to publish a fix?
A. Our goal is to have individual RPM packages available on the mirrors within 72 hours of their release, and normally they are available within 24 hours.
Are you implying that you will provide security updates under a paid SLA agreement but not to the wider CentOS Community?
Stop being coy and a trolling Bozo -- Of course I do, and have for many many years, long predating CentOS -- if you are unaware of that you have not thought through the timing and the history
Then let me be a little less coy and and put some substance around my question.
I started this thread, entitled "Missing security updates", because the CentOS documentation indicates that it is the Project's goal to provide updates within 1-3 days (notwithstanding we all appreciate this is a voluntary effort conducted in peoples free time). I and others have filed bug reports as requested about such missing updates once the indicated time period has elapsed. People currently expect updates within 72 hours, and normally within 24 hours, not because they are greedy leechers who simply take from your wonderful FOSS project, but because you have created that expectation within your own documentation.
My question to you arises from the fact that when I and others have again raised the issue, your reply which I quoted above appears to be in direct contradiction to the perceived current position. To my reading, you imply you don't care about the timeliness of updates and that if one does care about such things then one should purchase an SLA agreement from your private consulting company. And it was sent from an @centos.org address. Now that's fine, just that it's in contradiction to what most people currently perceive to be the case and as is stated on the CentOS website, hence why I seek clarification. I'm sorry if you feel that is coy or trolling. I'm asking a simple question - please clarify the policy on security updates. If the answer is we don't care, that's also fine but lets update the website FAQ/documentation to reflect that position. If the position remains as stated on the website then your response quoted above to my thread is inaccurate, impolite and confusing an important issue which requires clarity.
I ask because it's important to me. I know it's important to others too. I suspect it's important to many others.
It's *not* important to me because I *need* CentOS security updates quickly - I don't. As I and others have been told many times before, I have Red Hat entitlements where needed, and I can and do build my own security updates for those machines not covered by RHEL licences. It's important to me because I want to see the CentOS project succeed and I care about the millions of unprotected CentOS servers on the Internet that are missing security updates at any given time. It hurts the reputation of the project, it affects the (online) neighbourhood I live in; so I care deeply.
It's immensely frustrating when we see that security updates are missing, we get publicly berated for asking when we might expect them to be delivered, we get told the issue doesn't exist unless a bug is filed, bugs get filed that go unanswered and unacknowledged. Inevitably every few months it comes to a head in a thread like this and the response is CentOS developers becoming defensive (or even offensive) to those that ask. All it really takes it a little communication. The only people that have really communicated anything useful in this whole thread is Tru who has held his hands up and said he's been busy with real life (thanks Tru - much appreciated and we all understand that), and Karan who as informed us he is doing his best to cover for Tru but acknowledges that by his own very high standards that he isn't currently doing as good a job as he might have hoped. Again, we understand that, that's fine and all we have any right to expect. Is it really so difficult to communicate that on a regular basis? These things all stem from not knowing/a lack of information.
- shrug *
But, not under a CentOS signing key.
The rest of your posting is largely irrelevant to this thread and the issue of missing CentOS updates IMHO.
On Thu, 22 Jul 2010, R P Herrold wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
timeliness *appears* not to be important to the CentOS project, hence this discussion.
Not intended to be a smear - please see timeline @
One person comes to mind who stomped off the project very publicly, and will not be invited back. Their choice. I would not try to stop them, and will respect my relationship with the others who comprise the core of the CentOS process. We may not agree on all matters, but I think that those who remain there all agree that we will celebrate success publicly, and address failures privately
Russ,
If you are talking about me, you are twisting history quite a bit. It's one thing to fiercly stand behind your herd, but it's another if this goes against the goals of the project and benefits/expectations of its users.
Case in point, the core is reduced to maybe 4 active people, there is no governance model, there is no transparancy, internally important matters are minimized and/or delayed (for years!), a lot of (active) people in the community are tired of the (lack of) progress but have no means to do anything about it, I can go on...
The statement that there is a lack of people that want to actively contribute may be true, but if you cannot engage the people that show a willingness to do so, if there is no transparancy and there is no active process for people to contribute, then it's very painful for those people that do want to contribute.
If people are not allowed to speak up (or are being excommunicated if they do) then you are alienating all people that want to actively contribute (even in the core team). This thread is yet another example of that same recurring theme.
And that is exactly what happened to me inside the core team. There was a clear distrust and important matters were _not_ addressed. Those same items are still unaddressed. If I don't feel I am useful in the core team, if I cannot make a difference, if I cannot fix the things that matter to the community, it is my duty to quit. At least it gives the opportunity to someone else to try and do better. If I don't stand behind the project, I cannot stay in a core team in clear conscience and keep my opinions to myself in return for personal benefits. What you portret as a weakness, I consider a great strength.
The fact that you pretend I want to be invited back is laughable, but fits nicely into the excommunicated role you have me play, I guess :-)
PS As a reminder, my resignation letter summarized some of the pain points:
http://dag.wieers.com/blog/leaving-centos-team-not-centos-community
which are still valid today. If I will be known as the guy who couldn't make a blind man see, then so be it ;-)
Kind regards,
On Jul 22, 2010, at 4:11 PM, Charlie Brady wrote:
While of the above may seem obvious, the specific points are
- there are no steps and there is no process. Instead
its savvy guesses and spot checks and triple checks.
I would hope that there are some standard steps, rather than a totally ad-hoc process.
Results from an ad hoc or organized process are indistinguishible. But "security" fixes are intrinsically ad hoc and unplanned by their nature.
- the bottleneck _IS_ in some sense the testing team,
who are expected to achieve the pretense of "perfection" in spite of the "out-of-band" QA procedures involved. You really start to think hard and carefully before claiming WORKSFORME when your reputation is at stake. Its embarassing when some silly error has to be re-released or re-re-re-re-released to achieve the desired "security" fix goal.
I have seen no evidence that the testing team is the bottleneck here.
We likely have different meanings for "testing team" which should be clear from comments and context.
But if you mean the formal community cadre that tests new packages for CentOS before they are called "released" (my meaning was different), then what are you waiting for? When @redhat releases security fixes there is _ALWAYS_ a SRPM involved. What stops the "testing team" from attempting rebuilds and i9nstall directly from what @redhat releases? And what stops gathering the security fixes on some web site for additional vetting?
In short: What's the beef with CentOS "security" releases and testing teams and community involvement?
If the existing CentOS processes aren't moving as fast or smoothly as one would like, why not spend the energy doing an end-around rather than droning on criticism?
I personally know a large number of the people involved with CentOS (even if I don't directly use or participate with the CentOS project). None of them are gonna stop anyone from trying to do whatever seems needed IMHO. YMMV.
Security "fixes" are a hard problem to solve in _ALL_ distros, not just CentOS.
My expectation is that it is actually an easier problem for CentOS. They don't need to consider whether it is the correct or best fix, just whether it has been built correctly, and produces build output "sufficiently similar" to that produced by upstream.
This is the same QA process for "security" releases that I described. The "fix" assumes a cookie cutter gear turning build system, and that typically isn't the case, there's a fair amount of additional effort needed to ensure that "security" fixes are rebuilt perfectly.
Go grab "security" fixes SRPM's from @redhat and rebuild, install, test, on all supported platforms if you wish to see what effort is involved.
73 de Jeff
On 07/22/2010 09:11 PM, Charlie Brady wrote:
timeliness *appears* not to be important to the CentOS project, hence this discussion.
It is important to us, to everyone. But CentOS is a best-effort setup, always has been and will remain so. No one on the core-team is paid to work here, and we all have day jobs that need attention as well, add to that that most of us dont have any commercial gain from the many many hours that we put in either.
- KB
On 07/22/2010 07:29 PM, Charlie Brady wrote:
As I stated earlier, I think there is systematic process issue that the CentOS project should address. I'm not sure whether you are saying that there isn't a problem, or that the problem exists but is not solveable. I
I am not saying that there isnt an issue. but I dont agree with you that the problem is delayed updates. The delayed updates is a consequence of the issues that we are working with. Both Tru and I have had personal issues that have kept us away from the machines for a bit. I dont really have a machine that I can use reliably as this time either, but I'm working on that.
If you are now expecting that a bunch of people automagically get signing rights - thats not going to happen. The trust factor will need to get built up.
don't think either response is appropriate. Wouldn't it be more useful to admit that there is a problem, and discuss exactly what needs to be done to solve it?
Sure, there are plenty of issues that need resolution - but that resolution needs to be along the lines that are inclined towards real problem solving. If you wont see the real issue under the hood, you are not only missing the point, but also wasting everyone's time.
- KB
Karanbir Singh wrote:
If you are now expecting that a bunch of people automagically get signing rights - thats not going to happen. The trust factor will need to get built up.
As an outsider, I'm having trouble understanding how you will ever be able to solve this trust issue if you wait until you are short-handed to start. And expecting to never be short-handed doesn't seem realistic.
On 07/23/2010 02:10 PM, Les Mikesell wrote:
As an outsider, I'm having trouble understanding how you will ever be able to solve this trust issue if you wait until you are short-handed to start. And expecting to never be short-handed doesn't seem realistic.
What makes you think its a case of waiting till the problem strikes before we look for people ? I think its a case of working out and making sure there are 'enough' people around to handle the 'process'. What is that number ? I dont know myself. But 1 is a good number to work with. We only really need no-more than 1 person around most times.
Also, I wonder if people on this list realise that only about 10%[1] of our time and effort is oriented towards packages. There is a whole lot of other stuff we do too! Like the mirror setup, infra stuff, the forums are well looked after, there are over a dozen services that are exposed from *.centos.org
- KB
[1]: figure off the top of my head, havent actually measured things
On 7/23/2010 9:06 AM, Karanbir Singh wrote:
As an outsider, I'm having trouble understanding how you will ever be able to solve this trust issue if you wait until you are short-handed to start. And expecting to never be short-handed doesn't seem realistic.
What makes you think its a case of waiting till the problem strikes before we look for people ?
All I know is what I've seen on the mail list which has seemed fairly hostile to any offers to help or even questions to better understand the process.
I think its a case of working out and making sure there are 'enough' people around to handle the 'process'. What is that number ? I dont know myself. But 1 is a good number to work with. We only really need no-more than 1 person around most times.
If you were designing a reliable computing process would you ever say that 1 instance is enough - or even one location?
Also, I wonder if people on this list realise that only about 10%[1] of our time and effort is oriented towards packages. There is a whole lot of other stuff we do too! Like the mirror setup, infra stuff, the forums are well looked after, there are over a dozen services that are exposed from *.centos.org
No one is saying you don't work hard enough. The questions are about whether the resources are balanced with the tasks (with some evidence that they aren't...) and what can be done to improve that. Or perhaps how to adjust expectations to match reality if resources are overcommitted and going to stay that way.
On 07/23/2010 05:56 PM, Les Mikesell wrote:
I think its a case of working out and making sure there are 'enough' people around to handle the 'process'. What is that number ? I dont know myself. But 1 is a good number to work with. We only really need no-more than 1 person around most times.
If you were designing a reliable computing process would you ever say that 1 instance is enough - or even one location?
Its not a case of having only 1 person who can do something, its a case of making sure there are enough people involved so that when there is a need to do something, atleast 1 is available.
- KB
Dear Karan.
Yes, thats about right. The idea of testing stuff within CentOS has a very finite end point. With very few exceptions the only people trying to get onto the testing team are people looking for early access. There have only ever been a small number of people who actually do anything. I would love, more than anything else at this time, to have a large and productive testing team - but one that actually does something.
Opening up the list to public and opening up access to the testing repo's and hoping for the best is not only a stupid idea, its also a massive waste of resources. But still its the only solution people seem to come up with when I pitch this problem to them. So we carry on with our solution in place right now -> invite people we know and recognise to be people interested in helping. So visibility cluefull people from the community here. And dont be mistaken : plenty have declined. Which is fine, everyone has their own agenda and life to live.
There is even no clear process of how (trusted) ppl could join up. It's all about 'Expect to get invited when free slots in the testing team are available'.
I also think that you loose nothing with opening up the testing process. But I personally never really cared about that 'early access' thing. And yes, I know your arguments but I just don't share them and other projects which already have open processes work quite well (even if they are enterprise related).
I don't personally see any of those frames changing too far at the moment, but then I've been surprised in the past and am quite open to being surprised again :)
I just wait for the moment to be surprised by changes within the project infrastructure. One thing I have learned within the past few years in CentOS is that nothing will change (which maybe isn't that bad for an enterprise OS but it has not much to do with community)
Greets Marcus
On Jul 22, 2010, at 2:51 PM, Marcus Moeller wrote:
Dear Karan.
Yes, thats about right. The idea of testing stuff within CentOS has a very finite end point. With very few exceptions the only people trying to get onto the testing team are people looking for early access. There have only ever been a small number of people who actually do anything. I would love, more than anything else at this time, to have a large and productive testing team - but one that actually does something.
Opening up the list to public and opening up access to the testing repo's and hoping for the best is not only a stupid idea, its also a massive waste of resources. But still its the only solution people seem to come up with when I pitch this problem to them. So we carry on with our solution in place right now -> invite people we know and recognise to be people interested in helping. So visibility cluefull people from the community here. And dont be mistaken : plenty have declined. Which is fine, everyone has their own agenda and life to live.
There is even no clear process of how (trusted) ppl could join up. It's all about 'Expect to get invited when free slots in the testing team are available'.
The key issue is "trusted", not "join up". Credentials are earned, not handed out. Calling this a "process" is like calling a queue at the cash register a "process". Sure its linear, and moves forward, and can be modeled accoring to objective measurements like cash in-flow or residence time in queue and all those metrics miss the point that Credentials like "trusted" are earned, not otherwise.
I also think that you loose nothing with opening up the testing process. But I personally never really cared about that 'early access' thing. And yes, I know your arguments but I just don't share them and other projects which already have open processes work quite well (even if they are enterprise related).
What exactly is "closed" about the process? Sausages from the @redhat.com factory arrive on lthe CentOS oading dock, are examined, tallied, listed, stamped, processed, and re-distributed. The entire process for CentOS release engineering is easily seen, been the same since forever. There's nothing stopping anyone from grabbing the sausages in the "security release", building, installing, testing, and reporting "worksforme" to assist in expediting a "security release".
And if you want early access, you de facto have that by just building and installing the "security" fix directly.
I don't personally see any of those frames changing too far at the moment, but then I've been surprised in the past and am quite open to being surprised again :)
I just wait for the moment to be surprised by changes within the project infrastructure. One thing I have learned within the past few years in CentOS is that nothing will change (which maybe isn't that bad for an enterprise OS but it has not much to do with community)
All the vultures wait for dehydration to lead to demise before dining on the carcass.
And if you already "know" nothing will change, you already have an answer that works for you.
No community needs to be involved in your decisions.
73 de Jeff
On Thu, 22 Jul 2010, Jeff Johnson wrote:
What exactly is "closed" about the process? Sausages from the @redhat.com factory arrive on lthe CentOS oading dock, are examined, tallied, listed, stamped, processed, and re-distributed. The entire process for CentOS release engineering is easily seen, been the same since forever.
Do you have any references for the "examined, tallied, listed, stamped" part of these processes? I was unaware that there was any external visibility on these internal CentOS processes. There's nothing here, for instance:
http://bugs.centos.org/view.php?id=4386
Is the information available elsewhere?
There's nothing stopping anyone from grabbing the sausages in the "security release", building, installing, testing, and reporting "worksforme" to assist in expediting a "security release".
I'm not sure how that would help. We already know that Red Hat have built and presumably tested these packages. If I say that I've built and tested them, does that churn them through the CentOS process any quicker? Does it add any assurance to the packages *as built by CentOS*?
--- Charlie
On Jul 22, 2010, at 4:26 PM, Charlie Brady wrote:
On Thu, 22 Jul 2010, Jeff Johnson wrote:
What exactly is "closed" about the process? Sausages from the @redhat.com factory arrive on lthe CentOS oading dock, are examined, tallied, listed, stamped, processed, and re-distributed. The entire process for CentOS release engineering is easily seen, been the same since forever.
Do you have any references for the "examined, tallied, listed, stamped" part of these processes? I was unaware that there was any external visibility on these internal CentOS processes. There's nothing here, for instance:
http://bugs.centos.org/view.php?id=4386
Is the information available elsewhere?
All I have is 7 years of experience doing 14+ RHL releases and years of meetups with most of the CentOS team @FOSDEM.
So no, I can't give a URI to a documented, formal, typeset, wiki or web-page for what is involved.
Feel free to try the process yourself and see what is involved. The entire process is quite simple to understand even if tedious.
There's nothing stopping anyone from grabbing the sausages in the "security release", building, installing, testing, and reporting "worksforme" to assist in expediting a "security release".
I'm not sure how that would help. We already know that Red Hat have built and presumably tested these packages. If I say that I've built and tested them, does that churn them through the CentOS process any quicker? Does it add any assurance to the packages *as built by CentOS*?
And again there's the assumption that there's nothing to do because the release process is just cookie cutter gear turning.
The reality is quite different in my experience (but second-hand, I've never personally experienced the CentOS "security" release process).
73 de Jeff
Charlie _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thu, 22 Jul 2010, Jeff Johnson wrote:
On Jul 22, 2010, at 4:26 PM, Charlie Brady wrote:
On Thu, 22 Jul 2010, Jeff Johnson wrote:
What exactly is "closed" about the process? Sausages from the @redhat.com factory arrive on lthe CentOS oading dock, are examined, tallied, listed, stamped, processed, and re-distributed. The entire process for CentOS release engineering is easily seen, been the same since forever.
Do you have any references for the "examined, tallied, listed, stamped" part of these processes? I was unaware that there was any external visibility on these internal CentOS processes. There's nothing here, for instance:
http://bugs.centos.org/view.php?id=4386
Is the information available elsewhere?
All I have is 7 years of experience doing 14+ RHL releases and years of meetups with most of the CentOS team @FOSDEM.
So no, I can't give a URI to a documented, formal, typeset, wiki or web-page for what is involved.
Feel free to try the process yourself and see what is involved. The entire process is quite simple to understand even if tedious.
Whatever process I would create if I were doing this is irrelevant. What the CentOS developers actually do and don't do is what is relevant.
You apparently know exactly what they do, via some combination of intuition, personal experience and gossip collected at conferences. But that doesn't make it an open process, and doesn't make it well known.
There's nothing stopping anyone from grabbing the sausages in the "security release", building, installing, testing, and reporting "worksforme" to assist in expediting a "security release".
I'm not sure how that would help. We already know that Red Hat have built and presumably tested these packages. If I say that I've built and tested them, does that churn them through the CentOS process any quicker? Does it add any assurance to the packages *as built by CentOS*?
And again there's the assumption that there's nothing to do because the release process is just cookie cutter gear turning.
There's no such assumption. My assertion is that me building something on my dev system does nothing to accellerate the production of binaries by CentOS.
The reality is quite different in my experience (but second-hand, I've never personally experienced the CentOS "security" release process).
The key questions, Jeff, are whether the process can be improved, and if so, how? Statements about how complex the process is or might be don't help. Neither do suggestions that we all go home and do it ourselves.
On Jul 22, 2010, at 4:49 PM, Charlie Brady wrote:
You apparently know exactly what they do, via some combination of intuition, personal experience and gossip collected at conferences. But that doesn't make it an open process, and doesn't make it well known.
Well that also doesn't make it a closed process (other than I haven't bothered to implant an http intracranially).
In fact you asked a question and I tried to provide some reasonable answers.
But what -- in fact -- are you asking for?
You want which of the following: a) instant release of @redhat.com "security" releases through CentOS? b) a documented process flow for what is involved with a "security" release c) a reliable ETA for CentOS security xies d) the ability to participate in CentOS testing e) more community involvement in CentOS f) a whole different distro management team, or even a whole different distro g) something else ... ?
There's nothing stopping anyone from grabbing the sausages in the "security release", building, installing, testing, and reporting "worksforme" to assist in expediting a "security release".
I'm not sure how that would help. We already know that Red Hat have built and presumably tested these packages. If I say that I've built and tested them, does that churn them through the CentOS process any quicker? Does it add any assurance to the packages *as built by CentOS*?
And again there's the assumption that there's nothing to do because the release process is just cookie cutter gear turning.
There's no such assumption. My assertion is that me building something on my dev system does nothing to accellerate the production of binaries by CentOS.
Apologies for not carefully reading. My guesstimate (fwiw) is that assistance rebuilding packages, with credible (as in at least summarize what you did) WORKSFORME, particularly on odd-ball corener cases like z390 and or ppc, will not only help expedite a CentOS security release, but also earn you (at a bare minimum) a thank you! from CentOS developers.
I'm quite sure that someone will correct any detail that I have mis-guessed (based solely on my personaly/private/closed experiences).
The reality is quite different in my experience (but second-hand, I've never personally experienced the CentOS "security" release process).
The key questions, Jeff, are whether the process can be improved, and if so, how? Statements about how complex the process is or might be don't help. Neither do suggestions that we all go home and do it ourselves.
I hardly said "Go home and do it yourself" by any stretch of the imagination.
All processes can be improved. You started this thread by claiming not to know the process. Figger the CentOS process, and you will know how it can be improved.
And the process (generally) for "security" releases is not that hard to learn. The CentOS process is no different.
73 de Jeff
On Thu, 22 Jul 2010, Jeff Johnson wrote:
Apologies for not carefully reading. My guesstimate (fwiw) is that assistance rebuilding packages, with credible (as in at least summarize what you did) WORKSFORME, particularly on odd-ball corener cases like z390 and or ppc, will not only help expedite a CentOS security release, but also earn you (at a bare minimum) a thank you! from CentOS developers.
AFAIK, there is no way to provide "assistance rebuilding packages".
All processes can be improved. You started this thread by claiming not to know the process.
I didn't start the thread, and wasn't the first to mention the opacity of the process.
Figger the CentOS process, and you will know how it can be improved.
Yes, and that is why we are asking what the extant CentOS process is, and how, perhaps, we can help with it.
Jeff, with respect, I don't think you are any more capable of changing the current process from the outside than I am. It is time for the CentOS team to speak.
--- Charlie
On Thu, 22 Jul 2010, Charlie Brady wrote:
Jeff, with respect, I don't think you are any more capable of changing the current process from the outside than I am.
heh -- Jeff has consistently 'played fair' even in the face of libel and provocation for far longer than I can count. a person following #rpm and engaging in thoughtful and even vapid communication gets courteous and well written replies.
Additionally, if he asked, I would lobby for his addition to the core CentOS cadre and innermost councils without hesitation -- but from riding to and from OLS with him, from sleeping in his guest bedroom and he in mine, from providing him free space for a 'wild hare' exploration he wanted to do [see: http://www.pmman.com/ ]and from talking on the phone often with him, I know he hears a different drum than I
You know better than this. Of course he influences already; the build system model I have documented ftp://ftp.owlriver.com/pub/local/ORC/ is in part based on my talking with him about 'beehive' and 'Prospector' http://www.owlriver.com/projects/packaging/reproduceable-builds.txt
It is time for the CentOS team to speak.
Some choose to not hear the answer (or perhaps not liked it) when I have spoken
- Russ herrold
On 22 July 2010 23:35, R P Herrold herrold@centos.org wrote:
Some choose to not hear the answer (or perhaps not liked it) when I have spoken
And others do. Those with good memories (or good archival systems) can cross-reference your verbiage. ;-)
Alan.
On Thu, 22 Jul 2010, R P Herrold wrote:
On Thu, 22 Jul 2010, Charlie Brady wrote:
Jeff, with respect, I don't think you are any more capable of changing the current process from the outside than I am.
heh -- Jeff has consistently 'played fair' even in the face of libel and provocation for far longer than I can count. a person following #rpm and engaging in thoughtful and even vapid communication gets courteous and well written replies.
While I can take your word that this is true, I don't see how that is relevant here. I'm not accusing him of unfair play (or anything else).
You know better than this. Of course he influences already; the build system model I have documented ftp://ftp.owlriver.com/pub/local/ORC/ is in part based on my talking with him about 'beehive' and 'Prospector' http://www.owlriver.com/projects/packaging/reproduceable-builds.txt
Jeff's influence is indeed pervasive. But I maintain that he is not able to enforce change within the CentOS dev team from the outside. And neither am I.
It is time for the CentOS team to speak.
Some choose to not hear the answer (or perhaps not liked it) when I have spoken
I'm not sure whether you are being disingenuous here.
--- Charlie
On Jul 22, 2010, at 9:32 PM, Charlie Brady wrote:
Jeff's influence is indeed pervasive. But I maintain that he is not able to enforce change within the CentOS dev team from the outside. And neither am I.
Well I'm not much able to influence _ANYTHING_, but you are. Study the process and "fix" it in CentOS is all that I tried to encourage.
Any other meaning was not my intent. You did ask ;-)
73 de Jeff
On Thu, 22 Jul 2010, Jeff Johnson wrote:
On Jul 22, 2010, at 9:32 PM, Charlie Brady wrote:
Jeff's influence is indeed pervasive. But I maintain that he is not able to enforce change within the CentOS dev team from the outside. And neither am I.
Well I'm not much able to influence _ANYTHING_, but you are. Study the process
Jeff, the process is hidden. It cannot be studied. There is a black box called CentOS. SRPMS from Red Hat go in, and some time later binary rpms pop out.
and "fix" it in CentOS is all that I tried to encourage.
It can't be fixed either, except by the select few.
Any other meaning was not my intent. You did ask ;-)
73 de Jeff _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Jul 22, 2010, at 10:35 PM, Charlie Brady wrote:
On Thu, 22 Jul 2010, Jeff Johnson wrote:
On Jul 22, 2010, at 9:32 PM, Charlie Brady wrote:
Jeff's influence is indeed pervasive. But I maintain that he is not able to enforce change within the CentOS dev team from the outside. And neither am I.
Well I'm not much able to influence _ANYTHING_, but you are. Study the process
Jeff, the process is hidden. It cannot be studied. There is a black box called CentOS. SRPMS from Red Hat go in, and some time later binary rpms pop out.
Oh well ...
Millions of documentable downloads, used everywhere, and exactly zero revenue for CentOS. Truly astonishing.
Time to buy an iPad methinks, and queue up for IOS4. Android doesn't impress.
and "fix" it in CentOS is all that I tried to encourage.
It can't be fixed either, except by the select few.
Perhaps ...
73 de Jeff
Dear Jeff.
Yes, thats about right. The idea of testing stuff within CentOS has a very finite end point. With very few exceptions the only people trying to get onto the testing team are people looking for early access. There have only ever been a small number of people who actually do anything. I would love, more than anything else at this time, to have a large and productive testing team - but one that actually does something.
Opening up the list to public and opening up access to the testing repo's and hoping for the best is not only a stupid idea, its also a massive waste of resources. But still its the only solution people seem to come up with when I pitch this problem to them. So we carry on with our solution in place right now -> invite people we know and recognise to be people interested in helping. So visibility cluefull people from the community here. And dont be mistaken : plenty have declined. Which is fine, everyone has their own agenda and life to live.
There is even no clear process of how (trusted) ppl could join up. It's all about 'Expect to get invited when free slots in the testing team are available'.
The key issue is "trusted", not "join up". Credentials are earned, not handed out. Calling this a "process" is like calling a queue at the cash register a "process". Sure its linear, and moves forward, and can be modeled accoring to objective measurements like cash in-flow or residence time in queue and all those metrics miss the point that Credentials like "trusted" are earned, not otherwise.
This is quite good in theory but reality is different at least within the CentOS project. First of all the process of 'earning' is not described anywhere. Besides that there are not that many areas which are open for contributions. It's quite hard to earn money without a job.
And all this wouldn't be necessary if the process is open. I would like to suggest to create a updates-testing repo which should be available on every box but disabled by default. The packages should be pushed from buildsys (after succesfull builds) to this repository. The buildsys should be monitorable by everyone like the one of RPMFusion e.g.: http://buildsys.rpmfusion.org/
Besides that Karan already started to document the build process which should be extended a bit.
But that are just my 2 Franks
Greets Marcus
Hi Marcus,
On 07/22/2010 07:51 PM, Marcus Moeller wrote:
There is even no clear process of how (trusted) ppl could join up. It's all about 'Expect to get invited when free slots in the testing team are available'.
Afaik, its not related to 'free slots' at all. And the process is clear, you get recommended in by someone who is presently on the QA team and thats that.
We have, in the past, thought about having a more formal recruitment process - thats still on the cards - for various specific niche roles that need attention in the project. Lets see how we can accelerate that process a bit in the near future.
- KB
On Fri, 2010-07-23 at 13:59 +0100, Karanbir Singh wrote:
Hi Marcus,
On 07/22/2010 07:51 PM, Marcus Moeller wrote:
There is even no clear process of how (trusted) ppl could join up. It's all about 'Expect to get invited when free slots in the testing team are available'.
Afaik, its not related to 'free slots' at all. And the process is clear, you get recommended in by someone who is presently on the QA team and thats that.
We have, in the past, thought about having a more formal recruitment process - thats still on the cards - for various specific niche roles that need attention in the project. Lets see how we can accelerate that process a bit in the near future.
- KB
Hello I am normally a watcher here but I am afraid I cannot stay out of this one. And I would like to call BALDERDASH! All this nonsense about not being able to find volunteers is a bunch of baloney. I'm sure I can search my archives the forums and even IRC logs where people have been more than willing to help out. So it isn't that there is a lack of volunteers at all. It may be that the core group doesn't like the volunteers they are getting and if that is so then so be it they call the shots so there is nothing I or anyone else can do about this.
The fact is a thread like this starts about every 3 months or so and goes on and on and on. And points on both sides I do agree with. I do in some ways think that things are not very open in the cent camp. Coming from other projects where things have been much more open I can see where people are coming from. But I can also see where the core team is coming from as well. They have a good thing going and it is their free time they are contributing and to let just anyone run amuck in the system they have created could bring forth less than stellar results.
As I don't follow rhel security releases very closely I could not tell you if one was released yesterday and I got it today. I would agree though that security releases should be a priority and that 24-72 hours does seem very agreeable to me. And as far as I know this is mostly true of Tru when he is able to be around and devote more of his time to the project. Now if the man has things to do and life is busy then KB steps in and takes over I see no problem with that either. Granted things may be a bit slower than normal but is that really such a huge deal. I mean cmon give people a break. It has been well stated that you can download the src.rpms and build them for yourself if you feel that it is imperative to get the security update as fast as possible.
To sum this mess up I feel that some changes would be nice and I would like to see some things change but in the end so far my user and personal experience with cent has been very good between the ML, forums and IRC I have met alot of great people who are more than willing to help out. Things may not be perfect but are they ever really.
These long drawn out threads of people throwing stones at each other really accomplish nothing. I really saw nothing productive come out of this thread at all just alot of pissing and moaning. We simply have a few choices be productive and contribute, be creative offer solutions not accusations. LISTEN when someone tells you something LISTEN before speaking or typing for that matter. take into account all points before making a decision. I for one enjoy cent do I agree with everything of course not will I still continue to try and contribute positively where I can and when I can of course I will.
Your other solution pack your bags and move along for there is nothing for you to see here.
my 2 freakn cents!
On 10/07/10 18:55, Karanbir Singh wrote:
On 10/07/2010 00:41, Ned Slider wrote:
Any news on the pending security updates?
As posted on the irc channel, the backlog will clear by monday.
- KB
Thanks for getting that one out (perl-Archive-Tar) - any news on the rest?
-
Akemi Yagi -
Alan Bartlett -
Charlie Brady -
Dag Wieers -
David Hrbáč -
didi -
Gordon Messmer -
Jean-Marc Liger -
Jeff Johnson -
Karanbir Singh -
Les Mikesell -
lostson -
Marcus Moeller -
Ned Slider -
R P Herrold -
R P Herrold -
Tru Huynh