Hello, Just today I read in LWN( https://lwn.net/Articles/435744/ ) about the problems with CentOS.
I want to offer hardware (build servers) and I also want to volunteer time for cleaning up packages.
Is there a page giving some guidelines? How can I start helping ?
I'm packaging my own software with RPM for more then an year now so I think I have the required knowledge.
On Tue, Mar 29, 2011 at 12:50:51PM +0300, Marian Marinov wrote:
Just today I read in LWN( https://lwn.net/Articles/435744/ ) about the problems with CentOS.
Posting restricted content links that are available to paying subscribers only is, shall we say, useless in the general case.
John
I'm sorry, its a follow up from this story: http://lwn.net/Articles/429364/
Here is the first part of the article( the one that made me ask if I can help):
There are rumors suggesting that the CentOS 5.6 release is imminent - though that is something we have heard before. This release will certainly be welcome to numerous CentOS users, but there can be no doubt that its tardiness - and, in particular, the absence of CentOS 5 security updates caused by its delay - has been a bit of a wakeup call for those users. If this much-used distribution is to remain viable into the future, some important changes will need to be made and those who depend on it will have to step up their support.
There will be no shortage of CentOS users who would like to get their hands on the improvements and added hardware support to be found in the RHEL 5.6 and 6.0 releases. But the real problem is not delayed gratification; it is that there have been no CentOS 5 security updates since January 6, and only one since December 14, 2010. During this time, RHEL 5, on which CentOS 5 is based, has seen updates for dbus, exim, firefox (twice), gcc, hplip, java-openjdk, kernel (thrice), krb5, libtiff, libuser, mailman, openldap, pango, php, postgresql, python, samba, subversion (twice), tomcat5, vsftpd, and wireshark (twice). Since these updates are based on the 5.6 release, CentOS cannot easily pass them on to its users until they, too, have a 5.6 base. Since that base has been slow in coming, all those security updates have been blocked.
Some of these vulnerabilities are more severe than others, but there can be no contesting the fact that every CentOS 5 system out there is currently running with a significant set of known holes. That is not the sort of solidity and support that CentOS users will have been hoping for. Many of those users will, by now, be wondering whether CentOS is the right distribution to base their systems on.
On Tuesday 29 March 2011 13:03:55 John R. Dennison wrote:
On Tue, Mar 29, 2011 at 12:50:51PM +0300, Marian Marinov wrote:
Just today I read in LWN( https://lwn.net/Articles/435744/ ) about the problems with CentOS.
Posting restricted content links that are available to paying subscribers only is, shall we say, useless in the general case.
John
On Tue, 29 Mar 2011, Marian Marinov wrote:
Here is the first part of the article( the one that made me ask if I can help): ...
Now please read the thread 'polite request' from last Thursday in the list's archive
Then please read the post 'how can we help' on the main mailing list the day before
People who wander in after reading a month old article and do not 'do the homework' of learning the culture of a project and its history before posting are probably not going to be particularly productive, and would represent a net expenditure of effort to 'bring up to speed'. This is not the time for such efforts, and as indicated by the first post mentioned, not the venue, either
-- Russ herrold
R P Herrold wrote on 03/29/2011 09:10 AM:
On Tue, 29 Mar 2011, Marian Marinov wrote:
Here is the first part of the article( the one that made me ask if I can help): ...
Now please read the thread 'polite request' from last Thursday in the list's archive
Then please read the post 'how can we help' on the main mailing list the day before
People who wander in after reading a month old article and do not 'do the homework' of learning the culture of a project and its history before posting are probably not going to be particularly productive, and would represent a net expenditure of effort to 'bring up to speed'. This is not the time for such efforts, and as indicated by the first post mentioned, not the venue, either
Russ,
I cannot understand why someone coming in with an offer of substantial help, to provide both hardware and labor, should get this abusive response. I understand that there is overhead to get someone up to speed, but the current lateness of 5.6 and 6.0 seems to underscore the need for more and better help. Some guidance about how to get involved or even, "Yes we could use help, but are too busy right not to talk about it." would be understandable. Telling a potential contributor in essence - "Go away and don't bother us." defies logic and common courtesy.
If this is not the proper venue for volunteers wanting to help with resources to be applied to DEVELOPMENT to come to, then what is? I see no relevance of the "polite request" from Karanbir to this situation. It was in apparently targeted at some participants in the wandering thread "Why not a fusion between CentOS and SL?". This type of abusive treatment of potential contributors is exactly what many users complain about on other CentOS venues; the other major complaint being lack of information, or misinformation, about timing of the release of critical security updates, and to a lesser extent, new releases.
It seems apparent to me that CentOS is badly in need of some fresh blood and new approaches to conducting business. If all comers are to be turned away and there is no change in a positive direction, then perhaps some of the doomsayers predicting the demise of CentOS are correct. I sincerely hope that is not the case.
Phil
Ok, I'm sorry. I didn't know where to start.
Thank you for the pointers Russ. I already started reading. When I finish I'll write again.
Sometimes its just faster to ask instead of losing a few days wondering.
Regards, Marian Marinov
On Tue, 29 Mar 2011, Phil Schaffner wrote:
I cannot understand why someone coming in with an offer of substantial help, to provide both hardware and labor, should get this abusive response.
... and did the inquirant do any reading of posts less than a week old in either venue? Is this list the place for non-developmental matter discussions?
In each case, the answer remains no -- I won't be pulled off topic here by your misreading of what I said
-- Russ herrold
On Tue, 29 Mar 2011, R P Herrold wrote:
... and did the inquirant do any reading of posts less than a week old in either venue? Is this list the place for non-developmental matter discussions?
No, but you can certainly do it in a much kinder way so as not to scare off people who wish to contribute and become highly valued members.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
R P Herrold wrote on 03/29/2011 10:54 AM:
... and did the inquirant do any reading of posts less than a week old in either venue?
That is a valid point, but still can be addressed without the negative attitude.
Is this list the place for non-developmental matter discussions?
It was an offer to help with development.
In each case, the answer remains no -- I won't be pulled off topic here by your misreading of what I said
I fail to understand what I misinterpreted, but will not anticipate any response enlightening me as to my shortcomings, as that would be still further OT. :-)
My apologies to the list for my current diversions from centos-devel subject matter, and I will not continue participation in this thread.
Phil
On 3/29/2011 9:10 AM, R P Herrold wrote:
On Tue, 29 Mar 2011, Marian Marinov wrote:
Here is the first part of the article( the one that made me ask if I can help): ...
Now please read the thread 'polite request' from last Thursday in the list's archive
Then please read the post 'how can we help' on the main mailing list the day before
People who wander in after reading a month old article and do not 'do the homework' of learning the culture of a project and its history before posting are probably not going to be particularly productive, and would represent a net expenditure of effort to 'bring up to speed'. This is not the time for such efforts, and as indicated by the first post mentioned, not the venue, either
-- Russ herrold _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Russ,
This type of abusive response is what turns folks away form not only Centos but Linux in general. this individual is willing to donate time, and hardware you hit him with main battle cannons? I think some governance changes are needed from Centos if this is considered acceptable behavior.
On Tue, 29 Mar 2011, R P Herrold wrote:
On Tue, 29 Mar 2011, Marian Marinov wrote:
Here is the first part of the article( the one that made me ask if I can help): ...
People who wander in after reading a month old article and do not 'do the homework' of learning the culture of a project and its history before posting are probably not going to be particularly productive, and would represent a net expenditure of effort to 'bring up to speed'.
The LWN article mentioned is a fresh one. Here it is:
http://lwn.net/SubscriberLink/435744/90e3f3375232094a/
This is not the time for such efforts, and as indicated by the first post mentioned, not the venue, either
If this is not the venue, there is no venue.
And regarding time, the project has missed the opportunities the past 3 years to fix the issues. Besides the issues only appear when it's not the time to discuss them.
On Wed, Mar 30, 2011 at 6:26 AM, Dag Wieers dag@wieers.com wrote:
On Tue, 29 Mar 2011, R P Herrold wrote:
On Tue, 29 Mar 2011, Marian Marinov wrote:
Here is the first part of the article( the one that made me ask if I can help): ...
People who wander in after reading a month old article and do
The LWN article mentioned is a fresh one. Here it is:
To be clear -- the OP posted within a few hours of the article being published. It was hardly a "month old article".
This is not the time for such efforts, and as indicated by the first post mentioned, not the venue, either
If this is not the venue, there is no venue.
Fully agreed.
And regarding time, the project has missed the opportunities the past 3 years to fix the issues. Besides the issues only appear when it's not the time to discuss them.
Excepting the 4.9 release, which was extremely timely, point releases have been slipping more and more. The slippage for 5.6 is now nearly 3 months (RHEL 5.6 was released Jan 13, 2011). The slippage for 6.0 is nearly 5 months (RHEL 6 was released on Nov 10, 2010), and it's pretty much guaranteed that RH will release 6.1 before CentOS releases 6.0.
Claiming that the CentOS dev team does not need help building and that the build process has not become more complicated would appear to be untrue. But those of us on the outside have to guess at this because there is absolutely no transparency about the build process. All we've been told about the 5.6 delays are that there were "niggles". That's great -- exactly what niggles? What's blown up? Why is none of this public? THAT is what people are becoming increasingly discontent about -- a Community project that does not have any real interaction with the community. Too much is happening behind closed doors, and while I don't expect anything to change for 5.6 or 6.0 (or 6.1 at this point), there needs to be work done toward rectifying this when everyone is not busy as hell with new releases.
Rejecting offers for help in such an offhand way is really just poisoning the well -- I know several people who are extremely qualified for rebuilding efforts that will not work with CentOS because of such offhand dismissals. And, frankly, it's becoming extremely reminiscent of the final days of Whitebox before the CentOS project began. Yes, that's harsh, but the parallels are there.
Tom Sorensen
Greetings,
----- Original Message -----
If this is not the venue, there is no venue.
Fully agreed.
I agree also. I guess if they don't like it, they can kick us off the mailing list. I won't be offend if I'm kicked off because I don't really contribute and joined just to get some incite into what is going on... and we all know how well that has been working. :)
I must acknowledge that I do appreciate the work the CentOS developers do and that I haven't not found a way to contribute back.
I did see the huge under-appreciated thread asking if the Scientific Linux folks and the CentOS folks could work together. I read it for a few dozen postings and then gave up. I'm sure I'm probably repeating much that came from that thread... and as a result will be annoying to those who were annoyed by that thread... but anyway.
Ok, the CentOS and SL projects have different goals. DUH. But their goals are similar. They have similar tasks when they go about their building of and maintenance of their projects. The SL guys appear to have adopted much of the development environment from the Fedora folks. It seems to be that the CentOS developers could learn from the SL developers experience... and then alter that to meet their different needs. The good thing about the Fedora development environment is that it makes it possible to distribute the work. Right now the problem is that, and correct me if I'm wrong, the work is NOT distributed because the current build environment doesn't really allow for it... with regards to the building of packages and verifying them, etc.
Yes, I know the CentOS devels can't do anything about changing their system in mid-stream as it would delay even longer the the release of 5.6 and 6.0... and 6.1 is just around the corner... so we justifiably give them a pass. What remains to be seen is what they will do after the crunch time is over... and how burnt out they may or may not be as a result. Will they have the energy and desire to investigate a more open, distributed, community-enabling devel system after this go round? Will we have thrown so much salt in the wounds that they will want to take a break for a few months and then forget about it? The real question is, are they really going to be open to changing things at all? So far, I'm not sure.
Other than the complaining they have been getting about the delays from the "community of non-developers" , and granted a lot of it is the result of misinformation and misunderstandings, I'm not sure if the handful of CentOS developers are unhappy with the way things are (the development environment they are using) or not. I think they see most of these recent volunteers as fly-by-night, johnny-come-latelys are are just trying to get their copy of 5.6 and 6.0 faster... without much in the way of long-term help involved. There doesn't seem to be an infrastructure in place to enable them to easily make the changes that most of us feel are necessary for the future... and I'm not sure how interested they are in putting forth the work needed... when they are already overworked... when they perhaps see it as potentially just creating additional work for them without a guaranteed benefit.
Given the current situation... where the devs are too busy to accept help... I think what might be a direction for those who want to help... is to look into the Scientific Linux devel system... setup up a proof-of-concept clone of it... get it up and running as best as possible... and then try to figure out how it can be modified to add the validation tools the CentOS developers demand / rely on. That might sound like a crazy idea with little reality... but hey... at least it would be something... and if done right perhaps get the developers more interested in the changes we want... and show that the crop of recent volunteers are actually willing and able to do something. Of course it runs the risk of being completely rejected... but at that point it just might be worth having a healthy fork.
All of that stuff is easy for me to comment on because I have NOT volunteered to do anything. :) I also have to admit that I'm not much of a developer so perhaps my ignorance shows and people are laughing at me and this post. That's ok.
I've personally been playing with the SL kickstart files for their live media and making my own remixes.
In any event... thank you CentOS developers for the work you have done and continue to do. It is appreciated. I just wish I could wave a magic wand and fix all of the issues... give everyone unlimited free time... and some form of compensation they would be happy with.
And regarding time, the project has missed the opportunities the past 3 years to fix the issues. Besides the issues only appear when it's not the time to discuss them.
Excepting the 4.9 release, which was extremely timely, point releases have been slipping more and more. The slippage for 5.6 is now nearly 3 months (RHEL 5.6 was released Jan 13, 2011). The slippage for 6.0 is nearly 5 months (RHEL 6 was released on Nov 10, 2010), and it's pretty much guaranteed that RH will release 6.1 before CentOS releases 6.0.
Claiming that the CentOS dev team does not need help building and that the build process has not become more complicated would appear to be untrue. But those of us on the outside have to guess at this because there is absolutely no transparency about the build process. All we've been told about the 5.6 delays are that there were "niggles". That's great -- exactly what niggles? What's blown up? Why is none of this public? THAT is what people are becoming increasingly discontent about -- a Community project that does not have any real interaction with the community. Too much is happening behind closed doors, and while I don't expect anything to change for 5.6 or 6.0 (or 6.1 at this point), there needs to be work done toward rectifying this when everyone is not busy as hell with new releases.
Rejecting offers for help in such an offhand way is really just poisoning the well -- I know several people who are extremely qualified for rebuilding efforts that will not work with CentOS because of such offhand dismissals. And, frankly, it's becoming extremely reminiscent of the final days of Whitebox before the CentOS project began. Yes, that's harsh, but the parallels are there.
Tom Sorensen _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
on 3/30/2011 3:26 AM Dag Wieers spake the following:
On Tue, 29 Mar 2011, R P Herrold wrote:
On Tue, 29 Mar 2011, Marian Marinov wrote:
Here is the first part of the article( the one that made me ask if I can help): ...
People who wander in after reading a month old article and do not 'do the homework' of learning the culture of a project and its history before posting are probably not going to be particularly productive, and would represent a net expenditure of effort to 'bring up to speed'.
The LWN article mentioned is a fresh one. Here it is:
http://lwn.net/SubscriberLink/435744/90e3f3375232094a/This is not the time for such efforts, and as indicated by the first post mentioned, not the venue, either
If this is not the venue, there is no venue.
And regarding time, the project has missed the opportunities the past 3 years to fix the issues. Besides the issues only appear when it's not the time to discuss them.
I wouldn't be surprised if RedHat was seeding the src rpms with more bad links and flaws just to make it more difficult for Oracle and others to profit as easily from their work... We might just be the unfortunate collateral damage... The GPL says they have to release source, not ready to build rpms.
On Wednesday, March 30, 2011 06:26:40 pm Scott Silva wrote:
I wouldn't be surprised if RedHat was seeding the src rpms with more bad links and flaws just to make it more difficult for Oracle and others to profit as easily from their work... We might just be the unfortunate collateral damage... The GPL says they have to release source, not ready to build rpms.
Naw, I don't think so. Otherwise they wouldn't fix the bug reports of those missing buildreqs. And while those aren't high-priority to fix, they do get fixed. And it's too easy to just modify the spec file in the source RPM and make them build; a very low hurdle, in other words. The kernel source package's pre-patched source code tarball is a much larger hurdle, not for just rebuilding the package, but for modifying and properly (commercially) supporting those packages.
It's likely a simple case of developers missing the dependencies and not quickly fixing them; and, well, they're in the repository for their buildroots, so it doesn't impact them rebuilding out of their private koji. Buildreqs have always been low priority 'bugs' even before the end of the Red Hat Linux Boxed Sets.
On Thursday, March 31, 2011 12:02:12 pm Lamar Owen wrote:
The kernel source package's pre-patched source code tarball is a much larger hurdle, not for just rebuilding the package, but for modifying and properly (commercially) supporting those packages.
In re-reading what I posted, I realized that it could be misunderstood to mean that simple rebuilding is made more difficult by the pre-patched tarball being the source; that wasn't what I meant, and I apologize for the error. 'just rebuilding' in this case should be read as 'simply rebuilding' or 'straight rebuilding' or similar; unfortunately English is a rather ambiguous language, and my particular choice of the word 'just' in this instance was particularly ambiguous.
On Thu, Mar 31, 2011 at 10:31 AM, Lamar Owen lowen@pari.edu wrote:
On Thursday, March 31, 2011 12:02:12 pm Lamar Owen wrote:
The kernel source package's pre-patched source code tarball is a much larger hurdle, not for just rebuilding the package, but for modifying and properly (commercially) supporting those packages.
In re-reading what I posted, I realized that it could be misunderstood to mean that simple rebuilding is made more difficult by the pre-patched tarball being the source; that wasn't what I meant, and I apologize for the error. 'just rebuilding' in this case should be read as 'simply rebuilding' or 'straight rebuilding' or similar; unfortunately English is a rather ambiguous language, and my particular choice of the word 'just' in this instance was particularly ambiguous.
Interesting. I did not see any 'error' in your original writing. It was quite clear to me. If it was "not only for rebuilding", that would have been incorrect. :-) But then my native language is .ja, so ...
Akemi
On Thu, 31 Mar 2011, Lamar Owen wrote:
The kernel source package's pre-patched source code tarball is a much larger hurdle, not for just rebuilding the package, but for modifying and properly (commercially) supporting those packages.
Not only a hurdle for commercial competitors, there were people (like me) tracking the RHEL kernel builds between releases. In the past they were available (they still are for RHEL5, but have been removed for RHEL6) so this move impacts everyone interested in testing those kernel releases or relied on them for certain hardware support or bugfix.
I don't know that if you have Red Hat support you can still access these releases, but they were quite useful to CentOS users as well.
References:
http://people.redhat.com/jwilson/el5/ http://people.redhat.com/arozansk/el6/
Dag,
----- Original Message -----
I don't know that if you have Red Hat support you can still access these releases, but they were quite useful to CentOS users as well.
I don't know if it was what you were referring to or not... but yes, supposedly with a RHN account, you have access to the individual patches for the RHEL6 kernel... although I don't think they have a traditional package as before.
TYL,
On Thu, 31 Mar 2011, Scott Dowdle wrote:
I don't know that if you have Red Hat support you can still access these releases, but they were quite useful to CentOS users as well.
I don't know if it was what you were referring to or not... but yes, supposedly with a RHN account, you have access to the individual patches for the RHEL6 kernel... although I don't think they have a traditional package as before.
Scott,
I am not interested in the individual patches, just the binary kernel RPM packages Red Hat used to make available in between releases. Call it their test or beta kernel releases working up to the next RHEL release. Often one or two releases every week.
The RHEL5 link should make it clear what I mean.
It gives a nice view on what to expect kernel-wise for the next release, but also provided a way to test and report any problems quickly.
On Thu, 31 Mar 2011, Scott Dowdle wrote:
I don't know that if you have Red Hat support you can still access these releases, but they were quite useful to CentOS users as well.
I don't know if it was what you were referring to or not... but yes, supposedly with a RHN account, you have access to the individual patches for the RHEL6 kernel... although I don't think they have a traditional package as before.
Scott,
I am not interested in the individual patches, just the binary kernel RPM packages Red Hat used to make available in between releases. Call it their test or beta kernel releases working up to the next RHEL release. Often one or two releases every week.
The RHEL5 link should make it clear what I mean.
It gives a nice view on what to expect kernel-wise for the next release, but also provided a way to test and report any problems quickly.
That's true, I was using those kernels as a base for my own kernels with some stuff added. I also reported some issues and solutions for those kernels and they have been integrated and can be found in RHEL5.6/5.7. So, that's really missing for EL6 and even with a RHN account I don't know how I should be able to have access to kernels for EL6.
Simon
On Tue, Mar 29, 2011 at 05:03:55AM -0500, John R. Dennison wrote:
Just today I read in LWN( https://lwn.net/Articles/435744/ ) about the problems with CentOS.
Posting restricted content links that are available to paying subscribers only is, shall we say, useless in the general case.
The content will be available for free in two weeks.
Within that time, subscribers can generate links to a free version of the content to share with others. LWN is a valuable resource that I highly encourage _anyone_ interested in or dependent on Linux to subscribe. But if anyone in the CentOS development community would like access to this article, please e-mail me off-list. (It would be abusive of their trust to just post it to the list, of course, but since this seems like an important article for the project I'd like people who need timely access to be able to see it.)
On 03/29/2011 10:50 AM, Marian Marinov wrote:
I want to offer hardware (build servers) and I also want to volunteer time for cleaning up packages.
Because this comes up again and again and again I just want to quantify that buildservers are only helpful if you can ship them out to be located next to or very near the existing setup. Unless the resource itself can be assured to / with the same level of trust as the existing platform, the chances of that resource getting used are very slim.
Consider this: would you run packages that were built on $random site, with little or zero assurance of what, why and who has access to the machines ? I wont :)
Welcome to some of the strange and wonderful issues that are needed to be dealt with on a regular basis in .centos.org
- KB
On Mon, Apr 4, 2011 at 10:26 AM, Karanbir Singh mail-lists@karan.org wrote:
On 03/29/2011 10:50 AM, Marian Marinov wrote:
I want to offer hardware (build servers) and I also want to volunteer time for cleaning up packages.
Because this comes up again and again and again I just want to quantify that buildservers are only helpful if you can ship them out to be located next to or very near the existing setup. Unless the resource itself can be assured to / with the same level of trust as the existing platform, the chances of that resource getting used are very slim.
Consider this: would you run packages that were built on $random site, with little or zero assurance of what, why and who has access to the machines ? I wont :)
Welcome to some of the strange and wonderful issues that are needed to be dealt with on a regular basis in .centos.org
- KB
I would certainly want the final builds done on an "official" build server, but there's no reason there can't be "extended" build servers that contributors could use to test build packages to find problems. Once problems are found, patches could be generated and then vetted, applied, and built on the official trusted servers.
// Brian Mathis
On 04/04/2011 06:46 PM, Brian Mathis wrote:
Consider this: would you run packages that were built on $random site, with little or zero assurance of what, why and who has access to the machines ? I wont :)
I would certainly want the final builds done on an "official" build server, but there's no reason there can't be "extended" build servers that contributors could use to test build packages to find problems. Once problems are found, patches could be generated and then vetted, applied, and built on the official trusted servers.
given that plenty of mirrors already carry the stuff that peculates down from upstream, there should be no real issue for people to setup mock build environs and be doing private builds themselves anyway.
- KB
On Mon, Apr 4, 2011 at 5:41 PM, Karanbir Singh mail-lists@karan.org wrote:
On 04/04/2011 06:46 PM, Brian Mathis wrote:
Consider this: would you run packages that were built on $random site, with little or zero assurance of what, why and who has access to the machines ? I wont :)
I would certainly want the final builds done on an "official" build server, but there's no reason there can't be "extended" build servers that contributors could use to test build packages to find problems. Once problems are found, patches could be generated and then vetted, applied, and built on the official trusted servers.
given that plenty of mirrors already carry the stuff that peculates down from upstream, there should be no real issue for people to setup mock build environs and be doing private builds themselves anyway.
And while I'd still like to see some more clarity in the build process (such as, what packages are failing), after my earlier rant I did discover that the build process is reasonably well documented:
http://wiki.centos.org/FAQ/General/RebuildReleaseProcess
So I suspect that if you wanted to help identify build problems, go down that path.
Tom Sorensen
-
Akemi Yagi -
Brian Mathis -
Dag Wieers -
Gilbert Sebenste -
John R. Dennison -
Karanbir Singh -
Lamar Owen -
Marian Marinov -
Matthew Miller -
Phil Schaffner -
R P Herrold -
Scott Dowdle -
Scott Silva -
Simon Matter -
Tom Sorensen -
William Warren