2011/4/5 Dag Wieers dag@wieers.com:
You are one of the few who care to give updates, so thanks for that.
Nobody else really can give an update, the process is pretty much closed to the general public. So if the only person why can provide information is off by 2 months, I'd rather have no information at all.
Now is the time to change that.
Maybe CentOS just needs a new leadership?
-- Hendrik
On Tue, 5 Apr 2011, Hendrik wrote:
2011/4/5 Dag Wieers dag@wieers.com:
You are one of the few who care to give updates, so thanks for that.
Nobody else really can give an update, the process is pretty much closed to the general public. So if the only person why can provide information is off by 2 months, I'd rather have no information at all.
Now is the time to change that.
Maybe CentOS just needs a new leadership?
Try to convince UN first, ask questions later ;-)
On Apr 4, 2011, at 3:28 PM, Hendrik wrote:
2011/4/5 Dag Wieers dag@wieers.com:
You are one of the few who care to give updates, so thanks for that.
Nobody else really can give an update, the process is pretty much closed to the general public. So if the only person why can provide information is off by 2 months, I'd rather have no information at all.
Now is the time to change that.
Maybe CentOS just needs a new leadership?
Gimme a break.
Like who, you?
What a doschbag, as in a bag filled with a solution that is used to clean vaginas.
- aurf
"Gimme a break.
Like who, you?
What a doschbag, as in a bag filled with a solution that is used to clean vaginas.
- aurf"
Since we as a list are obviously incapable of having an adult conversation without resorting to ignorant / childish attacks, lets drop it already.
On Mon, Apr 04, 2011 at 03:42:35PM -0700, David Brian Chait wrote:
Since we as a list are obviously incapable of having an adult conversation without resorting to ignorant / childish attacks, lets drop it already.
Is it too much to ask that you learn how to quote and maintain attribution properly?
John
On 04/04/2011 06:42 PM, David Brian Chait wrote:
"Gimme a break.
Like who, you?
What a doschbag, as in a bag filled with a solution that is used to clean vaginas.
- aurf"
Since we as a list are obviously incapable of having an adult conversation without resorting to ignorant / childish attacks, lets drop it already.
+1
On Tue, 5 Apr 2011, Hendrik wrote:
Now is the time to change that.
Maybe CentOS just needs a new leadership?
Maybe its users need to realize that:
1. This entire thing is run by volunteers
2. This has been a very difficult release because of various apparent RedHat changes
3. Some releases were be faster---or slower--- than others
4. Centos 4.9, 5.6 and 6.0 hit at pretty much the same time
5. A properly configured firewall and the latest 5.5 patches, along with smart web browsing, indicates that there should be few if any security problems with C5.5 as it is now (sure, there are bugs, most of them local or DOS attacks, and I have yet to hear of one yet)
6. When it seems like they are close, another bug or issue(s) is/are found
7. I'm beta testing software done by volunteers and people are complaining about "when's the new release", when there are multiple issues evolving/changing externally that hamper our release.
So with #7, I personally get why this has been "late", as defined by some users. But, as Karanbir and others have stated: there is no timeline, it's when we can get to it. Typically 4-8 weeks, but this one has proven problematic. And again, more fingers in the honeypot can make things worse, especially when a release is trying to get pushed out the door.
Now, Karanbir does realize that communication needed to be improved, and when there's new developments, he posts it now on Twitter. But I'd rather him solve the issues, than dealing with the repeated "um, hey guys, you're REALLY late now!". I'm sure they wanted it out the door two months ago. During a release is not when a project needs help. It's starting on the next one...thinking CentoS 5.7/6.1.
Otherwise, some people really need to sit down and think if CentOS is what is needed, or RHEL. And as RedHat throws more monkey wrenches into their source, which could force anyone making a distro from RHEL harder and harder in the future, are you willing to wait 12-16 weeks for a new release? If not, head to RHEL in your next budget cycle, or something else. But having "been there, done that", the only thing I would have done differently with C5.6 is posted a few times "still have issues we're working on, no release date in sight yet", or words to that effect, and Karanbir is doing that now. Well, did; he said it should be syncing to the mirrors soon. Yay! Can't wait to upgrade.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On 04/04/2011 06:45 PM, Gilbert Sebenste wrote:
Maybe its users need to realize that:
This entire thing is run by volunteers
This has been a very difficult release
because of various apparent RedHat changes
- Some releases were be faster---or slower---
than others
Centos 4.9, 5.6 and 6.0 hit at pretty much the same time
A properly configured firewall and the latest 5.5 patches,
along with smart web browsing, indicates that there should be few if any security problems with C5.5 as it is now (sure, there are bugs, most of them local or DOS attacks, and I have yet to hear of one yet)
When it seems like they are close, another bug or issue(s) is/are found
I'm beta testing software done by volunteers and people are complaining
about "when's the new release", when there are multiple issues evolving/changing externally that hamper our release.
So with #7, I personally get why this has been "late", as defined by some users. But, as Karanbir and others have stated: there is no timeline, it's when we can get to it. Typically 4-8 weeks, but this one has proven problematic. And again, more fingers in the honeypot can make things worse, especially when a release is trying to get pushed out the door.
Now, Karanbir does realize that communication needed to be improved, and when there's new developments, he posts it now on Twitter. But I'd rather him solve the issues, than dealing with the repeated "um, hey guys, you're REALLY late now!". I'm sure they wanted it out the door two months ago. During a release is not when a project needs help. It's starting on the next one...thinking CentoS 5.7/6.1.
Otherwise, some people really need to sit down and think if CentOS is what is needed, or RHEL. And as RedHat throws more monkey wrenches into their source, which could force anyone making a distro from RHEL harder and harder in the future, are you willing to wait 12-16 weeks for a new release? If not, head to RHEL in your next budget cycle, or something else. But having "been there, done that", the only thing I would have done differently with C5.6 is posted a few times "still have issues we're working on, no release date in sight yet", or words to that effect, and Karanbir is doing that now. Well, did; he said it should be syncing to the mirrors soon. Yay! Can't wait to upgrade.
Thank you. :)
As an aside, does the CentOS build environment (understanding that it needs to be built, too), able to tweet something like "last build; X packages OK, Y packages failed"?
The reason I ask is that this would relieve some workload for the devs, and people who "need to know the progress" could simply follow the tweets. No more requests for "when is it ready?" No more needing to explain "we ran into problems" or what not. Heck, someone could even chart the progress by feeding the build stats into a graph.
So this way, no one would have to give time lines, make guesses or wonder. It just magically appears and users can interpret it any way they wish.
An idea that is freely discarded. :P
On Mon, 4 Apr 2011, Digimer wrote:
As an aside, does the CentOS build environment (understanding that it needs to be built, too), able to tweet something like "last build; X packages OK, Y packages failed"?
This was done on a trailling basis for a couple side arch's builders by me and another. It turns out to be a lot of chatter and 'noise', and not much 'signal'
-- Russ herrold
On Monday, April 04, 2011 10:43:08 PM R P Herrold wrote:
On Mon, 4 Apr 2011, Digimer wrote:
As an aside, does the CentOS build environment (understanding that it needs to be built, too), able to tweet something like "last build; X packages OK, Y packages failed"?
This was done on a trailling basis for a couple side arch's builders by me and another. It turns out to be a lot of chatter and 'noise', and not much 'signal'
Very true but, at least in my experience, signal doesn't matter in such a case cause most people that waited and complained anyway don't know what to really look for. They just want a progress meter of some form... A simple countdown of package numbers would probably be sufficient.
Peter.
centos-bounces@centos.org wrote:
On Mon, 4 Apr 2011, Digimer wrote:
As an aside, does the CentOS build environment (understanding that it needs to be built, too), able to tweet something like "last build; X packages OK, Y packages failed"?
This was done on a trailling basis for a couple side arch's builders by me and another. It turns out to be a lot of chatter and 'noise', and not much 'signal'
I would venture: It would be more polite and civil chatter than what this thread has put into the CentOS mailing list archives.
*cringes at the difficulty that strangers face, wading through our slop looking for helpful tidbits of know-how*
Thought for posting guidelines for this list: "If it's not a request for help with a CentOS component, or an answer thereto, it probably doesn't belong on this list"
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
This was done on a trailling basis for a couple side arch's builders by me and another. It turns out to be a lot of chatter and 'noise', and not much 'signal'
Although it might not be of any real use in indicating when a version would be ready, I think it helps a lot psychologically when people can see that something is being done, even if it's discovering bugs that will push back the release.
A lot of the anxiety seems to be about the silence about any kind of progress. A tweet or post of that nature once a week takes maybe all of 1 minute to send but would reduce a lot of the unpleasant noise I see being tossed up on the forum and lists. I suspect it would be less frustrating for the devs as well by reducing the amount of bitching and offers of help they don't want at this point.
On 04/05/11 11:32 PM, Emmanuel Noobadmin wrote:
A lot of the anxiety seems to be about the silence about any kind of progress.
there's a fair amount of traffic on centos-devel
archives here, http://lists.centos.org/pipermail/centos-devel/2011-April/thread.html
On 4/6/11, John R Pierce pierce@hogranch.com wrote:
On 04/05/11 11:32 PM, Emmanuel Noobadmin wrote:
A lot of the anxiety seems to be about the silence about any kind of progress.
there's a fair amount of traffic on centos-devel
archives here, http://lists.centos.org/pipermail/centos-devel/2011-April/thread.html
Apologies, I wasn't subscribed to the dev list since I didn't think I would had been able to contribute anything. Fortunately, I'm also not fixated about when exactly is Centos 6 coming out.
Maybe the standard reply to those chasing for status on Centos 6 should be "Please subscribe to devel list to follow updates" since chances are the majority of them are only checking the site or the user list.
Le 06/04/2011 09:08, Emmanuel Noobadmin a écrit :
Apologies, I wasn't subscribed to the dev list since I didn't think I would had been able to contribute anything. Fortunately, I'm also not fixated about when exactly is Centos 6 coming out.
Maybe the standard reply to those chasing for status on Centos 6 should be "Please subscribe to devel list to follow updates" since chances are the majority of them are only checking the site or the user list.
Hi Emmanuel,
You don't have to subscribe to dev's mailing list, only consult the archives : http://lists.centos.org/pipermail/centos-devel/
Alain
on 4/5/2011 11:46 PM John R Pierce spake the following:
On 04/05/11 11:32 PM, Emmanuel Noobadmin wrote:
A lot of the anxiety seems to be about the silence about any kind of progress.
there's a fair amount of traffic on centos-devel
archives here, http://lists.centos.org/pipermail/centos-devel/2011-April/thread.html
Most of the traffic lately is the same "is it done yet" stuff on here. The rest is developer and distro bashing/defending.
On 04/06/2011 07:32 AM, Emmanuel Noobadmin wrote:
Although it might not be of any real use in indicating when a version would be ready, I think it helps a lot psychologically when people can see that something is being done, even if it's discovering bugs that will push back the release.
As Russ already pointed out, the build status indicator isnt really of much value. However, something that *might* be of some value is if people can actually get a perspective on present state. Thats something I'm working on and hope to have in place once we get 6 out of the door.
Part of the reason why people think I'm out of sync in my estimates is down to the fact that package change and implications of those packages include downwards deps as well. So we can be at 95% done, with 1 package change taking us down to 75% and it goes on. I guess people like Dag and Hendrik just done understand these sort of things very well.
- KB
Em 04-04-2011 23:45, Gilbert Sebenste escreveu:
Maybe its users need to realize that:
- This entire thing is run by volunteers
How can a company dedicate a few man-hours per week to help CentOS?
I mean this in a more official way, rather than just a person dropping by at the -devel list.
Rui
On 04/06/2011 02:54 AM, Rui Miguel Silva Seabra wrote:
Em 04-04-2011 23:45, Gilbert Sebenste escreveu:
Maybe its users need to realize that:
- This entire thing is run by volunteers
How can a company dedicate a few man-hours per week to help CentOS?
I mean this in a more official way, rather than just a person dropping by at the -devel list.
Rui _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Check the archive for the past month - this has been brought up numerous times. To elegantly put it: wait to ask this once 6.0 is finished (and perhaps 6.1) as the whole process needs to be looked into a bit (in terms of opening it up / being able to utilize community help).
On 04/06/2011 07:54 AM, Rui Miguel Silva Seabra wrote:
How can a company dedicate a few man-hours per week to help CentOS? I mean this in a more official way, rather than just a person dropping by at the -devel list.
Thats a very good question, and something more people should be asking : here is a terse reply : adopt a part of the distro, contribute tests and take ownership of driving support for those components forward ( so, wiki content, support in irc channels and support for users on those components in the mailing lists ). Start with a package or two, then move that forward. Start with whats already in the distro.
Its easy to fixate on the idea of CentOS being the distro and the distro alone - however, a very large part of what the users see value in is the user base around CentOS - and focused, specialised help with those areas would go a long way in 'helping' CentOS.
- KB
On Wed, 2011-04-06 at 10:33 +0100, Karanbir Singh wrote:
On 04/06/2011 07:54 AM, Rui Miguel Silva Seabra wrote:
How can a company dedicate a few man-hours per week to help CentOS? I mean this in a more official way, rather than just a person dropping by at the -devel list.
Thats a very good question, and something more people should be asking : here is a terse reply : adopt a part of the distro, contribute tests and take ownership of driving support for those components forward ( so, wiki content, support in irc channels and support for users on those components in the mailing lists ). Start with a package or two, then move that forward. Start with whats already in the distro.
Ah! I like the sound of this. This can be a start. What I understand by this, is adopt a package, test it out, and update the community via wiki, hanging in the IRC channels and answering questions on the mailing list.
What about having some users adopt a package, say maybe in teams of 3 with different responsibilities. So for example, if someone 'adopts' package foo - two others should join in and they can split the load between them, so one guy can be in charge of watching the list, and giving a 'nudge' offlist to the 'parent' of foo, another can post twitter updates, or list announcments to a timetable - It's just an idea, but i believe with a touch of visibility, to the workload on a package level will shut up everyone, and change the argument from when will it be READY, to DAMN we gots loads of work to do to help out to get it READY. We can then even really measure of well the community can get new releases out the door. We can eventually streamline the process, come on, don't we consider ourselves kick ass?
Can't we use something like launchpad? There *must* be some collaborative tools that we can leverage, after all, they all run on CENTOS do they not!?
On 04/06/2011 10:57 AM, Mister IT Guru wrote:
Ah! I like the sound of this. This can be a start. What I understand by this, is adopt a package, test it out, and update the community via wiki, hanging in the IRC channels and answering questions on the mailing list.
... amongst other things.
Can't we use something like launchpad? There *must* be some collaborative tools that we can leverage, after all, they all run on CENTOS do they not!?
Step,1 would be working out what is really needed, you dont need job designations to do stuff :) the bugs.c.o / lists / forums / irc channels are all open to anyone / everyone who wants in.
- KB
On Wed, 6 Apr 2011, Karanbir Singh wrote:
On 04/06/2011 07:54 AM, Rui Miguel Silva Seabra wrote:
How can a company dedicate a few man-hours per week to help CentOS? I mean this in a more official way, rather than just a person dropping by at the -devel list.
Thats a very good question, and something more people should be asking : here is a terse reply : adopt a part of the distro, contribute tests and take ownership of driving support for those components forward ( so, wiki content, support in irc channels and support for users on those components in the mailing lists ). Start with a package or two, then move that forward. Start with whats already in the distro.
Its easy to fixate on the idea of CentOS being the distro and the distro alone - however, a very large part of what the users see value in is the user base around CentOS - and focused, specialised help with those areas would go a long way in 'helping' CentOS.
But there's no problem with all of these things where people can help already. The wiki is working fine, the mailinglist is helping people, I never heard anyone complain about this.
None of this is fixing where people want the project to improve. People want to help with where the problems are, which is fixing builds so a release can be more timely.
Why are we avoiding this again and again ?
On 04/06/2011 09:57 PM, Dag Wieers wrote:
But there's no problem with all of these things where people can help already. The wiki is working fine, the mailinglist is helping people, I never heard anyone complain about this.
There is no problem that people can help there, sure - but how many are ? Look at the whole picture not just specific isolated points.
None of this is fixing where people want the project to improve. People want to help with where the problems are, which is fixing builds so a release can be more timely.
Why are we avoiding this again and again ?
I am not sure who you refer to as 'we' - you for one are trying too hard to look down narrow corridors without consider what the efforts are targeted at. eg. If people were to adopt parts of the package tree's would that then not be a good reason to let them take ownership within the distro as well ? You seem quite keen on either ignoring that aspect, or just dont see it.
I also realise that you want things to change Dag, however doing the right thing is more important than just doing random things and hoping something will stick ( and unfortunately the only thing you have been able to come up with are the random sorts ). How about making a bit of an effort and trying to work through what efforts are being directed at rather than standing on the sidelines and sniping ?
- KB
Em 06-04-2011 10:33, Karanbir Singh escreveu:
On 04/06/2011 07:54 AM, Rui Miguel Silva Seabra wrote:
How can a company dedicate a few man-hours per week to help CentOS? I mean this in a more official way, rather than just a person dropping by at the -devel list.
Thats a very good question, and something more people should be asking : here is a terse reply : adopt a part of the distro, contribute tests and take ownership of driving support for those components forward ( so, wiki content, support in irc channels and support for users on those components in the mailing lists ). Start with a package or two, then move that forward. Start with whats already in the distro.
Didn't you read the part where I said...
«I mean this in a more official way, rather than just a person dropping by at the -devel list.»
?
You just gave me examples of more "person Foo dropping by Bar"... I'm not sure how that can shorten the gap between upstream and CentOS releases. It seems more in the way of giving user support.
The main support *I* need is timely updates and releases.
It's obvious there is a man-power issue. It is obvious to me you're in denial :)
Rui
centos-bounces@centos.org wrote:
The main support *I* need is timely updates and releases.
This is the key indicator that says you want RHEL not CentOS.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On 4/11/2011 10:55 AM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
The main support *I* need is timely updates and releases.
This is the key indicator that says you want RHEL not CentOS.
That's only true if you think the CentOS team is incapable of matching some definition of 'timely'.
On 04/11/11 9:14 AM, Les Mikesell wrote:
The main support*I* need is timely updates and releases.
This is the key indicator that says you want RHEL not CentOS.
That's only true if you think the CentOS team is incapable of matching some definition of 'timely'.
well, whatever your definition, you can't deny that RHEL will be 'more' timely than any downstream rebuild.
centos-bounces@centos.org wrote:
On 4/11/2011 10:55 AM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
The main support *I* need is timely updates and releases.
This is the key indicator that says you want RHEL not CentOS.
That's only true if you think the CentOS team is incapable of matching some definition of 'timely'.
Proved to be so, with great pain for some.
To take a relativistic approach, entities (people or corporations) who are uncomfortable with CentOS's notion of "timely" will be less so with RH's notion of "timely", since RHEL defines the product for which we're waiting. RH is the Time(0) of the process.
Speed costs money, time costs money and/or patience.
You must either shell out the money for RHEL, or you must shell out time for CentOS.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Mon, 11 Apr 2011, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
On 4/11/2011 10:55 AM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
The main support *I* need is timely updates and releases.
This is the key indicator that says you want RHEL not CentOS.
That's only true if you think the CentOS team is incapable of matching some definition of 'timely'.
Proved to be so, with great pain for some.
To take a relativistic approach, entities (people or corporations) who are uncomfortable with CentOS's notion of "timely" will be less so with RH's notion of "timely", since RHEL defines the product for which we're waiting. RH is the Time(0) of the process.
Speed costs money, time costs money and/or patience.
You must either shell out the money for RHEL, or you must shell out time for CentOS.
Considering you follow the "it's released when it's ready" mantra, what are you comfortable with ? A one month delay between upstream and CentOS ? Two months ? Three months (CentOS 5.6) ? Four months ? Five months ? Six months (CentOS 6.0) ? When it's ready ?
Regarding CentOS 5.6, all users using it should not have a problem if the security updates are 3 months behind ? Maybe in 12 months Karanbir has a kid, Johnny disappears again. Would four months be acceptable ? Maybe five months ?
No no, it's released when it's ready. Even if it takes 6 months and the next release is out before CentOS is ready ? 3 months is halfway through the release, so you're vulnerable to security problems 50% of the time.
If you graph the releases since 2005, you can see it's becoming longer and longer. It never took 3 months before. A new base release never took 5 months.
http://en.wikipedia.org/wiki/CentOS
I have been ringing the alarm-bell 2 years ago (CentOS 4.8) and nothing has changed. But hey, don't let me spoil your dinner, there is no problem. It's free, so questioning things is out of order.
http://dag.wieers.com/blog/centos-48-finally-there
The comments I got both came from the CentOS team, so you know where you stand if you provide a critical voice. I no longer expect any change.
On Mon, Apr 11, 2011 at 08:19:22PM +0200, Dag Wieers wrote:
Considering you follow the "it's released when it's ready" mantra, what
[ ... ]
I no longer expect any change.
Then why are you always coming back here to voice your concerns if you don't expect any change?
Tru
On Mon, Apr 11, 2011 at 2:49 PM, Tru Huynh tru@centos.org wrote:
On Mon, Apr 11, 2011 at 08:19:22PM +0200, Dag Wieers wrote:
Considering you follow the "it's released when it's ready" mantra, what
[ ... ]
I no longer expect any change.
Then why are you always coming back here to voice your concerns if you don't expect any change?
Tru
I for one am glad about it as it is obvious that it needs to be addressed. The constant retorts against anyone asking is just unbelievable. Maybe if the questions can be read as:
I know you release when ready, so how can I help it be ready faster?
It really is an achievement to have alienated such a luminary as Dag, especially when KB specifically mentions that the project only wants to deal with such luminaries in the FLOSS interview.
// Brian Mathis
On Mon, Apr 11, 2011 at 03:03:05PM -0400, Brian Mathis wrote:
I for one am glad about it as it is obvious that it needs to be addressed.
we all agree that it can be done better/faster/...
The constant retorts against anyone asking is just unbelievable. Maybe if the questions can be read as:
I know you release when ready, so how can I help it be ready faster?
1) what about "stop breathing over my neck?"
I would not like a "helping hand" stabbing me everyday to remind me that things could be better, but ymmv.
2) 4.9 is out, 5.6 is nearly released (SRPMS still being pushed), work on 6 will resume...
3) Releasing is one goal, keep thing running is another.
C4 csgfs needs testing, who is helping? http://bugs.centos.org/view.php?id=4754
4) back to your genuine inquiry "how can I help it be ready faster?"
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
[... anything usefull for your CentOS community ...]
Tru
On 4/11/2011 2:33 PM, Tru Huynh wrote:
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
So having everyone repeat the same mistakes with no coordination is your idea of doing things faster? I guess parallel computing really is a hard problem.
On Mon, Apr 11, 2011 at 02:44:03PM -0500, Les Mikesell wrote:
On 4/11/2011 2:33 PM, Tru Huynh wrote:
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
So having everyone repeat the same mistakes with no coordination is your idea of doing things faster?
who is everyone?
I guess parallel computing really is a hard problem.
I guess so.
On 4/11/2011 2:59 PM, Tru Huynh wrote:
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
So having everyone repeat the same mistakes with no coordination is your idea of doing things faster?
who is everyone?
I might throw some time and equipment at it if I knew I wasn't re-inventing square wheels (or even round ones for that matter). And I suspect that others smarter than I am would do the same and maybe even improve the approach by coming up with ways to predict the build environment needed to reproduce a given binary to reduce the trial-and-error time. But I don't see this happening if the process stays closed any more than I think there would be a useful Linux today - or most of the packages comprising Red Hat's product - if development had not been open and shared.
On Mon, Apr 11, 2011 at 03:37:28PM -0500, Les Mikesell wrote:
On 4/11/2011 2:59 PM, Tru Huynh wrote:
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
So having everyone repeat the same mistakes with no coordination is your idea of doing things faster?
who is everyone?
I might throw some time and equipment at it if I knew I wasn't re-inventing square wheels (or even round ones for that matter). And I suspect that others smarter than I am would do the same and maybe even improve the approach by coming up with ways to predict the build environment needed to reproduce a given binary to reduce the trial-and-error time.
Same answer for you than I made for Dag, volonteer to coordinate, build, write scripts, publish *your* work and you will be helping your fellows.
But I don't see this happening if the process stays closed any more than I think there would be a useful Linux today - or most of the packages comprising Red Hat's product - if development had not been open and shared.
I only see wasted time talking, no actions. I will be happy to be proven wrong.
Tru
Tru Huynh wrote:
On Mon, Apr 11, 2011 at 03:37:28PM -0500, Les Mikesell wrote:
On 4/11/2011 2:59 PM, Tru Huynh wrote:
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
So having everyone repeat the same mistakes with no coordination is your idea of doing things faster?
who is everyone?
I might throw some time and equipment at it if I knew I wasn't re-inventing square wheels (or even round ones for that matter). And I suspect that others smarter than I am would do the same and maybe even improve the approach by coming up with ways to predict the build environment needed to reproduce a given binary to reduce the trial-and-error time.
Same answer for you than I made for Dag, volonteer to coordinate, build, write scripts, publish *your* work and you will be helping your fellows.
<snip> I must be missing something here. If it had been someone I didn't know, that's one thing, but Dag's been contributing to Linux as a whole for a lotta years, and his site is a major repository.
mark
centos-bounces@centos.org wrote:
Tru Huynh wrote:
Same answer for you than I made for Dag, volunteer to coordinate, build, write scripts, publish *your* work and you will be helping
your fellows.
<snip> I must be missing something here. If it had been someone I didn't know, that's one thing, but Dag's been contributing to Linux as a whole for a lotta years, and his site is a major repository.
This is perhaps the most poignant comment.
If it were me, wiser you are to listen to frogs and crickets. Dag is saying "I want to help but your system is closed". I believe him more than anybody in CentOS. CentOS folks apparently believe their entire system is open and transparent enough that anybody of Dag's skills and experience could help with no trouble at all. He says differently.
The only thing I can point out in CentOS's favor is that they have said a few things about how helpers (can) help; and that this discussion belongs on CentOS-Devel.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Mon, Apr 11, 2011 at 05:27:13PM -0400, Brunner, Brian T. wrote:
If it were me, wiser you are to listen to frogs and crickets. Dag is saying "I want to help but your system is closed". I believe him more than anybody in CentOS.
Except for the whole "I resign" issue with Dag and the project.
He's stirring up trouble for the sake of stirring up trouble.
John
On Mon, 11 Apr 2011, John R. Dennison wrote:
On Mon, Apr 11, 2011 at 05:27:13PM -0400, Brunner, Brian T. wrote:
If it were me, wiser you are to listen to frogs and crickets. Dag is saying "I want to help but your system is closed". I believe him more than anybody in CentOS.
Except for the whole "I resign" issue with Dag and the project.
He's stirring up trouble for the sake of stirring up trouble.
Yes, and CentOS does not have issues ! It's all Dag that's making it up.
Without Dag releases would be more timely :) Pigs can fly !
On Tue, Apr 12, 2011 at 12:08:29AM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, John R. Dennison wrote:
Except for the whole "I resign" issue with Dag and the project.
He's stirring up trouble for the sake of stirring up trouble.
Yes, and CentOS does not have issues ! It's all Dag that's making it up.
These are not mutually exclusive. It is possible for CentOS to have problems and for you to stir up trouble at the same time. Whether you mean it to or not, your posts come off as bitter sniping, and not as constructive criticisms of CentOS.
--keith
On Mon, 11 Apr 2011, Keith Keller wrote:
On Tue, Apr 12, 2011 at 12:08:29AM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, John R. Dennison wrote:
Except for the whole "I resign" issue with Dag and the project.
He's stirring up trouble for the sake of stirring up trouble.
Yes, and CentOS does not have issues ! It's all Dag that's making it up.
These are not mutually exclusive. It is possible for CentOS to have problems and for you to stir up trouble at the same time. Whether you mean it to or not, your posts come off as bitter sniping, and not as constructive criticisms of CentOS.
You can read into my statements what you like, but do also read the facts I bring up and the deafening silence from the project about some real issues. None of these are new by the way.
BTW tell me how one can be constructive if:
- the project does not plan to discuss why it took 84 days for CentOS 5.6 and 5 months for CentOS 6.0
- the project has QA closed to a limited group of people and the development process closed
- the project is not interested to allow more people to collaborate
- no other team members actually dare to speak up other than the three people that have sign-access
This is not a community project. A community shares information for the benefit of everyone.
On Mon, Apr 11, 2011 at 04:19:37PM -0700, Keith Keller wrote:
Oy, I am very sorry for this post--my fumblefingers asked mutt to encrypt my post instead of simply signing it. List admins, is it possible to have the post deleted? (If not, it won't be the first or last time my clumsiness is on public display.)
--keith
On Tue, Apr 12, 2011 at 12:08:29AM +0200, Dag Wieers wrote:
Yes, and CentOS does not have issues ! It's all Dag that's making it up.
Without Dag releases would be more timely :) Pigs can fly !
Oh, stop it. I never once said that there were no issues; we all know that there are. But you rehashing the same tired arguments over and over and over hasn't changed anything yet and it is quite unlikely to do so in the future.
Your constant drive-by snipes don't do much to give the devs additional motivation to correct any of the issues that are present. You come across as just another ungrateful consumer more often than not of late, Dag. To be honest, I expected better of you.
I know you've a history; I know that there might well be some bad blood present; I also know that you did much at one time to promote the project. But that doesn't give you a right to pollute this list with the _same_ thing, over and over. It's monotonous, it's not productive, and at some point it just becomes noise.
John
John R. Dennison wrote on 04/11/2011 07:48 PM:
Your constant drive-by snipes don't do much to give the devs additional motivation to correct any of the issues that are present.
I don't think anyone with the constant presence Dag has exhibited can be characterized as a drive-by poster, and he has certainly helped stimulate some constructive discussion. It remains to be seen if any real change will result from the interchange.
I hope it will.
Phil
On Mon, 2011-04-11 at 18:48 -0500, John R. Dennison wrote:
On Tue, Apr 12, 2011 at 12:08:29AM +0200, Dag Wieers wrote:
Yes, and CentOS does not have issues ! It's all Dag that's making it up.
Without Dag releases would be more timely :) Pigs can fly !
Oh, stop it. I never once said that there were no issues; we all know that there are. But you rehashing the same tired arguments over and over and over hasn't changed anything yet and it is quite unlikely to do so in the future.
Your constant drive-by snipes don't do much to give the devs additional motivation to correct any of the issues that are present. You come across as just another ungrateful consumer more often than not of late, Dag. To be honest, I expected better of you.
I know you've a history; I know that there might well be some bad blood present; I also know that you did much at one time to promote the project. But that doesn't give you a right to pollute this list with the _same_ thing, over and over. It's monotonous, it's not productive, and at some point it just becomes noise.
---- I think his point is well taken. If the developers don't change the methodology of building, each release will be later and later given the current trends. It's pretty hard to argue anything else. RHEL 6 was released on November 10th, 2010 and here it is more than 5 months later and nada.
My perspective is that Dag's packages have contributed greatly to the success of CentOS. In fact, Dag has a long history of packaging software for many different Linux distributions especially RedHat/Fedora. To characterize him as a drive-by sniper demonstrates ignorance of all of his contributions.
Craig
your constantly recurring ignorance and blindness is way more monotonously then everything dag wrote so far.
2011/4/12 John R. Dennison jrd@gerdesas.com:
On Tue, Apr 12, 2011 at 12:08:29AM +0200, Dag Wieers wrote:
Yes, and CentOS does not have issues ! It's all Dag that's making it up.
Without Dag releases would be more timely :) Pigs can fly !
Oh, stop it. I never once said that there were no issues; we all know that there are. But you rehashing the same tired arguments over and over and over hasn't changed anything yet and it is quite unlikely to do so in the future.
Your constant drive-by snipes don't do much to give the devs additional motivation to correct any of the issues that are present. You come across as just another ungrateful consumer more often than not of late, Dag. To be honest, I expected better of you.
I know you've a history; I know that there might well be some bad blood present; I also know that you did much at one time to promote the project. But that doesn't give you a right to pollute this list with the _same_ thing, over and over. It's monotonous, it's not productive, and at some point it just becomes noise.
John
-- Be thankful we're not getting all the government we're paying for.
-- Will Rogers (1879-1935), American humorist and entertainer, as quoted in The Wordsworth Dictionary of Quotations (1998) by Connie Robertson
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Apr 12, 2011 at 02:32:36AM +0200, Tamada Wilder wrote:
your constantly recurring ignorance and blindness is way more monotonously then everything dag wrote so far.
DO NOT TOP POST. THIS IS NOT ROCKET SCIENCE.
Sorry to shout, but you've been asked in the past to stop it and adhere to the guidelines of this mailing list.
Now... Who the hell are you to accuse me of ignorance and blindness? What makes you think you are in any position to accuse anyone of ignorance when _YOU_ can't even master the concept of adhering to published mailing list guidelines?
Please, go find your bridge and crawl back underneath it and troll elsewhere.
John
On 04/11/11 5:41 PM, John R. Dennison wrote:
DO NOT TOP POST.
sadly, gmail/googlemail is very hostile to proper quoting practices. it hides quoted text, while leaving the whole previous message appended, without any form of > quoting. The only workable way around this is to use a imap/pop client like Thunderbird with it, which then disables a lot of the web functionality of gmail... meanwhile, yahoomail still can't seem to get the concept of 'references' right, so every message reply via yahoo breaks teh thread quoting on systems that rely on References headers to maintain the proper threading. cellphone email is just awful, promoting one line top posted messages. Sadly, its a lost battle. these people are better off on facebook.
sadly, gmail/googlemail is very hostile to proper quoting practices. it hides quoted text, while leaving the whole previous message appended, without any form of > quoting. The only workable way around this is to use a imap/pop client like Thunderbird with it, which then disables a lot of the web functionality of gmail...
Just poking my head up here but how is GMail hostile? It's defaults aren't exactly friendly to lists like CentOS but I'm busy writing this in Gmail, it's not top posted, quoted correctly, doesn't break threading, is addressed to you and the list, and is plain text AFAIK. All I've done is applied the list's etiquette rules and am careful not to break them. So what are an extra mouse click or two here and there?
On 4/12/11, John R Pierce pierce@hogranch.com wrote:
On 04/11/11 5:41 PM, John R. Dennison wrote:
DO NOT TOP POST.
sadly, gmail/googlemail is very hostile to proper quoting practices. it hides quoted text, while leaving the whole previous message appended, without any form of > quoting. The only workable way around this is to use a imap/pop client like Thunderbird with it, which then disables a lot of the web functionality of gmail...
I have to admit gmail's defaults didn't help. But it can be set properly... at least nobody's screamed at me for posting wrongly since the last time a couple of years back :D
Not sure if the same defaults still apply now since I haven't touched my settings for ages.
On 04/11/2011 10:27 PM, Brunner, Brian T. wrote:
If it were me, wiser you are to listen to frogs and crickets. Dag is saying "I want to help but your system is closed".
Just to be clear, Dag isnt saying that at all. What he is saying is that 'I dont want to help by actually doing anything, but I am sure other people do' and his reason for that is that he's done a lot for CentOS in the past. I don't doubt he has, but others have done more and continue to do more.
- KB
On Tue, 12 Apr 2011, Karanbir Singh wrote:
On 04/11/2011 10:27 PM, Brunner, Brian T. wrote:
If it were me, wiser you are to listen to frogs and crickets. Dag is saying "I want to help but your system is closed".
Just to be clear, Dag isnt saying that at all. What he is saying is that 'I dont want to help by actually doing anything, but I am sure other people do' and his reason for that is that he's done a lot for CentOS in the past. I don't doubt he has, but others have done more and continue to do more.
Eeerrm, that's not been what I have been saying. Nice to know where you are coming from.
I also don't see what the size of my (past) contributions to CentOS has to do with this whole discussion. I would much rather discuss why the QA process needs to be closed, why you think opening up the process will not help fix issues faster (while obviously that's the whole point of Open Source) and what the analysis is of the CentOS 5.6 release taking 3 months to complete.
It's obvious that most of the people arguing in this thread would like more timely releases, especially because those releases take longer and longer.
At the moment four CentOS developers (Karanbir, Johnny, Tru and Russ) are arguing that more transparency in the build process and QA process is not going to help speed up the process and have clearly articulated that they do not plan to make the process more transparent, and that anyone willing to learn, what the project already knows, are going to have to start from scratch.
After Johnny and Tru's disappointing messages, I twittered yesterday as my hope for a true CentOS community is fading. I rather spend my energy on something that is truly Open Source, transparent and honest.
I guess that's what Johnny has been saying all along. There is no wish to change how the project is taking care of things.
On Tue, 12 Apr 2011, Dag Wieers wrote:
I also don't see what the size of my (past) contributions to CentOS has to do with this whole discussion. I would much rather discuss why the QA process needs to be closed, why you think opening up the process will not help fix issues faster (while obviously that's the whole point of Open Source) and what the analysis is of the CentOS 5.6 release taking 3 months to complete.
CentOS at its core is NOT a development project; it is a way to rebuild source content, and distribute trustable binary content in a fashion that replicates a third party's binary API, that is suitable for enterprise grade use. It is a misnomer to call MOST of what is issued as binaries as 'developed' -- rather they are simply BUILT.
There are exceptions -- early on, the addition and stabilization of yum and the mirror dispatch network WERE original development; solving 'self-hosting' where it was not a goal upstream IS development; the back building tools ARE developed; the ABI comparisons ARE new work rather than derivative works
It's obvious that most of the people arguing in this thread would like more timely releases, especially because those releases take longer and longer.
These are conflicting goals -- faster, more like upstream, more side product coverage, status and progress bars to look at. But at the end of the day, adding more cruft, bells and whistles, makes for more places for rot, more distraction to 'fix' the widget that is not performing either as one intends or at all, and will net SLOW a release because the total quantum of work by trusted parties needs to be performed has grown if such are adopted
At the moment four CentOS developers (Karanbir, Johnny, Tru and Russ) are arguing that more transparency in the build process and QA process is not going to help speed up the process and have clearly articulated that they do not plan to make the process more transparent, and that anyone willing to learn, what the project already knows, are going to have to start from scratch.
I scarcely think my outline earlier today, taken with all the content I've published over the years back to cAos days are 'starting from scratch' I've helped three or four folks privately with private rebuild efforts of the 6 sources since November. There was a post earlier this afternoon to the effect that my encouragement on these lists helped another person 'become a builder'. You overstate your case in seeking to tar me with your brush
So that it is clear, my objection to 'open QA' has ALWAYS been that careless users will treat QA interim content as production ready, and then seek support in general channels to repair what they improvidently broke. CentOS does not need reputational damage of that sort. Ever.
CentOS ships production ready enterprise binaries, to the extent of its capabilities, and has down a darn fine job over the with the existing system. There is no compelling reason to tamper with a system that works that I have seen so far.
If a person 'NEEDS' binaries faster, they need someone to provide SLA's to them. That usually implies contracts and an exchange of value for the SLA promise. Contracts are not within the scope of CentOS -- why would the project compete with the upstream? CentOS can not be that entity
I mentioned some months ago that I provide for my clients private updates (not CentOS content) and provoked wails and gnashing of teeth from some one of the Forum 'crew'; it seems I have instructed and motivated 'Cal Webster' to do the same. Johnny made it clear he could be hired for such in the last couple weeks without such outrage being expressed; you, Dag, have run consulting services, and your sig line seems it advertise it every time I see you post. Don't you consider that repetition to be in poor taste here?
After Johnny and Tru's disappointing messages, I twittered yesterday as my hope for a true CentOS community is fading. I rather spend my energy on something that is truly Open Source, transparent and honest.
Explain away your twitter remark if you will, but it left a bad taste with me in light of your posts here the last few days, and your ongoing 'attitude'
I guess that's what Johnny has been saying all along. There is no wish to change how the project is taking care of things.
Seems to me that KB's solicitation of testing cases, and the vast silence in reply makes it clear that the 'community' of centos is largely a community of takers and talkers, rather than 'do-ers'. That's okay, but please don't pretend it is some caged animal, eager to break free into creative expression that the CentOS bug tracker, wiki, or closely allied Fedora does not already provide an outlet for
-- Russ herrold
On 04/13/2011 12:40 AM, R P Herrold wrote:
On Tue, 12 Apr 2011, Dag Wieers wrote:
I guess that's what Johnny has been saying all along. There is no wish to change how the project is taking care of things.
Seems to me that KB's solicitation of testing cases, and the vast silence in reply makes it clear that the 'community' of centos is largely a community of takers and talkers, rather than 'do-ers'. That's okay, but please don't pretend it is
because currently there is no way to become do-ers...
On Tue, 12 Apr 2011, R P Herrold wrote:
On Tue, 12 Apr 2011, Dag Wieers wrote:
I also don't see what the size of my (past) contributions to CentOS has to do with this whole discussion. I would much rather discuss why the QA process needs to be closed, why you think opening up the process will not help fix issues faster (while obviously that's the whole point of Open Source) and what the analysis is of the CentOS 5.6 release taking 3 months to complete.
CentOS at its core is NOT a development project; it is a way to rebuild source content, and distribute trustable binary content in a fashion that replicates a third party's binary API, that is suitable for enterprise grade use. It is a misnomer to call MOST of what is issued as binaries as 'developed' -- rather they are simply BUILT.
Nowhere did I mention 'developed'. Why are you replying to something I DID NOT say ?
But to reply to something you DID say. Why would only development projects benefit from an Open Source attitude ? I don't understand why that makes any difference.
Groklaw is not a development project either, neither is Wikipedia, but they do benefit from an open and transparent process, and contributions from a community. Yes, even randomly drive-by (sic) contributions.
It's obvious that most of the people arguing in this thread would like more timely releases, especially because those releases take longer and longer.
These are conflicting goals -- faster, more like upstream, more side product coverage, status and progress bars to look at. But at the end of the day, adding more cruft, bells and whistles, makes for more places for rot, more distraction to 'fix' the widget that is not performing either as one intends or at all, and will net SLOW a release because the total quantum of work by trusted parties needs to be performed has grown if such are adopted
You say that, but there's not been an analysis of what took 3 months.
To me it seems quite obvious that finding and fixing build problems, doing QA, looking for trademarks, are all tasks that can be distributed quite easily. If the process is open and transparent, and if clearly communicated and managed. I fully understand that this may not be what interests the current developers, but that shouldn't be an excuse for not doing what's best for the project and its users.
At the moment four CentOS developers (Karanbir, Johnny, Tru and Russ) are arguing that more transparency in the build process and QA process is not going to help speed up the process and have clearly articulated that they do not plan to make the process more transparent, and that anyone willing to learn, what the project already knows, are going to have to start from scratch.
I scarcely think my outline earlier today, taken with all the content I've published over the years back to cAos days are 'starting from scratch' I've helped three or four folks privately with private rebuild efforts of the 6 sources since November. There was a post earlier this afternoon to the effect that my encouragement on these lists helped another person 'become a builder'. You overstate your case in seeking to tar me with your brush
How's helping people privately making a difference to more transparency with the CentOS build and QA process ? I sympathize with what you do in private, but I don't see how it helps with the case at hand.
So that it is clear, my objection to 'open QA' has ALWAYS been that careless users will treat QA interim content as production ready, and then seek support in general channels to repair what they improvidently broke. CentOS does not need reputational damage of that sort. Ever.
You didn't consider reputational damage when a release is 3 months, or 6 months late ? There are technical solutions that would minimize the risk to careless users, while still allowing for an open QA.
So you basically confirm my statement above. Thanks for that.
CentOS ships production ready enterprise binaries, to the extent of its capabilities, and has down a darn fine job over the with the existing system. There is no compelling reason to tamper with a system that works that I have seen so far.
Despite lacking security updates for 3 months. Did you realize that if it takes 3 months to create a minor release, you are vulnerable 50% of the time ? RHEL 5.7 is likely scheduled for July.
If a person 'NEEDS' binaries faster, they need someone to provide SLA's to them. That usually implies contracts and an exchange of value for the SLA promise. Contracts are not within the scope of CentOS -- why would the project compete with the upstream? CentOS can not be that entity
There's a difference between 1 month and 3 months. But hey, you once again make my point that you don't see more timely releases as a priority.
That is perfectly fine. Let's make sure everyone understands that 3 months (or 6 months) are expected and normal for CentOS.
My personal believe is that if people knew that 3 years ago, CentOS would not have been as popular as it is now. But don't believe me, ask around.
I mentioned some months ago that I provide for my clients private updates (not CentOS content) and provoked wails and gnashing of teeth from some one of the Forum 'crew'; it seems I have instructed and motivated 'Cal Webster' to do the same. Johnny made it clear he could be hired for such in the last couple weeks without such outrage being expressed; you, Dag, have run consulting services, and your sig line seems it advertise it every time I see you post. Don't you consider that repetition to be in poor taste here?
Are you saying there's a financial benefit to you and Johnny if CentOS releases are delayed ? Is that why it's important to the CentOS team to not share information and open up processes ?
After Johnny and Tru's disappointing messages, I twittered yesterday as my hope for a true CentOS community is fading. I rather spend my energy on something that is truly Open Source, transparent and honest.
Explain away your twitter remark if you will, but it left a bad taste with me in light of your posts here the last few days, and your ongoing 'attitude'
Right, I have an attitude problem and CentOS has no issues :) Regardless, thanks to that tweet I received plenty of feedback of users/stakeholders that share my frustration. So maybe something materializes from that, who knows ?
If it leaves a bad taste with you, maybe that is actually good sign ?
I guess that's what Johnny has been saying all along. There is no wish to change how the project is taking care of things.
Seems to me that KB's solicitation of testing cases, and the vast silence in reply makes it clear that the 'community' of centos is largely a community of takers and talkers, rather than 'do-ers'.
Well, KB's soliciation of testing cases is not how Open Source works. That you still use that as an excuse to NOT open up the process tells a lot about the project's position.
Could you all please now leave me be ? I'd like to spend my time on something worthwhile :)
On 4/12/2011 5:40 PM, R P Herrold wrote:
There is no compelling reason to tamper with a system that works that I have seen so far.
Is there any amount of elapsed time that will convince you otherwise?
I'll refrain from calling this passage of time a delay, since that would imply some sort of schedule, but it would nice if the project web site set expectations appropriately.
And wouldn't the same 'system that works' comment have applied to WhiteBox for some bounded period of time?
On 04/13/2011 10:24 AM, Les Mikesell wrote:
On 4/12/2011 5:40 PM, R P Herrold wrote:
There is no compelling reason to tamper with a system that works that I have seen so far.
Is there any amount of elapsed time that will convince you otherwise?
I'll refrain from calling this passage of time a delay, since that would imply some sort of schedule, but it would nice if the project web site set expectations appropriately.
And wouldn't the same 'system that works' comment have applied to WhiteBox for some bounded period of time?
Our goals have not changed, they are still what they were and what are posted. Sometimes it takes longer than we want.
People have a choice. They can use CentOS or they can use something else.
We do not need to say the same things over and over again.
There is no "time limit" that we would go past where I would allow people who I do not know and trust to commit items into the CentOS tree. I have to use this in production and it has to be done correctly. It does not matter how long it takes if it is done right.
Whitebox is not, nor was it ever, deployed on 29% of all Linux webserver servers worldwide. CentOS is ... right now ... deployed on 29% of web servers on the Internet that use Linux. That is more than RHEL and Ubuntu combined: http://w3techs.com/technologies/details/os-linux/all/all
CentOS is also deployed on 8 of the top 500 supercomputers in the world (actually more than 8, because many that use CentOS instead just say Linux as a generic name): http://www.top500.org/stats/list/36/os
Specifically Ranger: http://blogs.sun.com/jonathan/entry/lone_ranger
CentOS is in use in hundreds of Universities all over the world.
CentOS is a major player on the Amazon Cloud: http://news.idg.no/cw/art.cfm?id=BE5C04FE-1A64-6A71-CEBD76121F6F5495
We must be doing something right.
On 04/13/2011 07:55 PM, Johnny Hughes wrote:
On 04/13/2011 10:24 AM, Les Mikesell wrote:
On 4/12/2011 5:40 PM, R P Herrold wrote:
There is no compelling reason to tamper with a system that works that I have seen so far.
Is there any amount of elapsed time that will convince you otherwise?
I'll refrain from calling this passage of time a delay, since that would imply some sort of schedule, but it would nice if the project web site set expectations appropriately.
And wouldn't the same 'system that works' comment have applied to WhiteBox for some bounded period of time?
Our goals have not changed, they are still what they were and what are posted. Sometimes it takes longer than we want.
People have a choice. They can use CentOS or they can use something else.
We do not need to say the same things over and over again.
There is no "time limit" that we would go past where I would allow people who I do not know and trust to commit items into the CentOS tree. I have to use this in production and it has to be done correctly. It does not matter how long it takes if it is done right.
I don't think that's what we are discussing here about. I think we are discussing about making it all open, so that everybody can setup a build environment easily and start working on the real issues, not working on the build environment itself. You replied to one of my questions, and gave me plenty of information. I thank you for that. That's useful. However, if I want to start troubleshooting packages right away, and help CentOS, I can't do that. I will first have to loop through emails from you on this list. Find hints on the build environment. Loop through bugs.centos find hints there as well. Probably it will take me much more time setting things up, than actually debugging the trouble package. So, what I think we (we = some of us) are asking, is make it easy for anybody to set this up and start debugging. The way things are right now, no wonder few people help. People who can actually help here, have little time. If you don't give them some resources, thy won't bother figuring it out.
Whitebox is not, nor was it ever, deployed on 29% of all Linux webserver servers worldwide. CentOS is ... right now ... deployed on 29% of web servers on the Internet that use Linux. That is more than RHEL and Ubuntu combined: http://w3techs.com/technologies/details/os-linux/all/all
CentOS is also deployed on 8 of the top 500 supercomputers in the world (actually more than 8, because many that use CentOS instead just say Linux as a generic name): http://www.top500.org/stats/list/36/os
Specifically Ranger: http://blogs.sun.com/jonathan/entry/lone_ranger
CentOS is in use in hundreds of Universities all over the world.
CentOS is a major player on the Amazon Cloud: http://news.idg.no/cw/art.cfm?id=BE5C04FE-1A64-6A71-CEBD76121F6F5495
We must be doing something right.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Radu Gheorghiu wrote:
On 04/13/2011 07:55 PM, Johnny Hughes wrote:
On 04/13/2011 10:24 AM, Les Mikesell wrote:
On 4/12/2011 5:40 PM, R P Herrold wrote:
<snip>
There is no "time limit" that we would go past where I would allow people who I do not know and trust to commit items into the CentOS tree. I have to use this in production and it has to be done correctly. It does not matter how long it takes if it is done right.
I don't think that's what we are discussing here about. I think we are discussing about making it all open, so that everybody can setup a build environment easily and start working on the real issues, not working on the build environment itself. You replied to one of my questions, and gave me plenty of information. I thank you for that. That's useful. However, if I want to start troubleshooting packages right away, and help CentOS, I can't do that. I will first have to loop through emails from you on this list. Find hints on the build environment. Loop through bugs.centos find hints there as well. Probably it will take me much more time setting things up, than actually debugging the trouble package. So, what I think we (we = some of us) are asking, is make it easy for anybody to set this up and
<snip> I'll chime in again: is there not a full build environment that can be checked out of the CentOS version control system? Or an rpm to install it?
mark
centos-bounces@centos.org wrote:
Radu Gheorghiu wrote:
On 04/13/2011 07:55 PM, Johnny Hughes wrote:
On 04/13/2011 10:24 AM, Les Mikesell wrote:
On 4/12/2011 5:40 PM, R P Herrold wrote:
<snip> >> There is no "time limit" that we would go past where I would allow >> people who I do not know and trust to commit items into the CentOS >> tree. I have to use this in production and it has to be done >> correctly. It does not matter how long it takes if it is done >> right.
I don't think that's what we are discussing here about. I think we are discussing about making it all open, so that everybody can setup a build environment easily and start working on the real issues, not working on the build environment itself.
<snip> I'll chime in again: is there not a full build environment that can be checked out of the CentOS version control system? Or an rpm to install it?
mark
Yum --enablerepos=Centos-Builder install CentOS-Build-Environment
No, it seems to me this doesn't yet exist.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
Radu Gheorghiu wrote:
On 04/13/2011 07:55 PM, Johnny Hughes wrote:
On 04/13/2011 10:24 AM, Les Mikesell wrote:
On 4/12/2011 5:40 PM, R P Herrold wrote:
<snip> >> There is no "time limit" that we would go past where I would allow >> people who I do not know and trust to commit items into the CentOS >> tree. I have to use this in production and it has to be done >> correctly. It does not matter how long it takes if it is done >> right.
I don't think that's what we are discussing here about. I think we are discussing about making it all open, so that everybody can setup a build environment easily and start working on the real issues, not working on the build environment itself.
<snip> I'll chime in again: is there not a full build environment that can be checked out of the CentOS version control system? Or an rpm to install it?
Yum --enablerepos=Centos-Builder install CentOS-Build-Environment
No, it seems to me this doesn't yet exist.
Fifteen years ago, when I worked for Ameritech (one of the now-swallowed Baby Bells), I built a set of makefiles to build our entire project to the "architecture team"'s specs (let's not discuss the opinions of that team that all the rest of us had). I was the *first* person to manage it (and we had 26 other teams all working on it)... and that was after it ate my entire life, 12, 14, 16 hour days, for two and a half months.
So, *maybe*, after my own current personal life settles down, I might be willing to look at the job....
mark "in addition to my real job, that pays the bills, and my family...."
On 4/13/2011 11:55 AM, Johnny Hughes wrote:
People have a choice. They can use CentOS or they can use something else.
Or they can try to convince the project not to follow the Whitebox example of not matching resources to the task.
There is no "time limit" that we would go past where I would allow people who I do not know and trust to commit items into the CentOS tree. I have to use this in production and it has to be done correctly. It does not matter how long it takes if it is done right.
No one has suggested any of these things. I don't understand why you keep repeating that as if it were a contradiction. Or why you are so convinced that CentOS could not be both timely and correct. In fact, I thought one of your other postings implied that it was possible.
Whitebox is not, nor was it ever, deployed on 29% of all Linux webserver servers worldwide. CentOS is ... right now ... deployed on 29% of web servers on the Internet that use Linux. That is more than RHEL and Ubuntu combined: http://w3techs.com/technologies/details/os-linux/all/all
OK, if you are going to use that as an example, please tell me how many of those people made that choice knowing that updates were going to be months behind upstream. There's certainly nothing on the project web site to imply that.
On 04/13/2011 12:28 PM, Les Mikesell wrote:
On 4/13/2011 11:55 AM, Johnny Hughes wrote:
People have a choice. They can use CentOS or they can use something else.
Or they can try to convince the project not to follow the Whitebox example of not matching resources to the task.
There is no "time limit" that we would go past where I would allow people who I do not know and trust to commit items into the CentOS tree. I have to use this in production and it has to be done correctly. It does not matter how long it takes if it is done right.
No one has suggested any of these things. I don't understand why you keep repeating that as if it were a contradiction. Or why you are so convinced that CentOS could not be both timely and correct. In fact, I thought one of your other postings implied that it was possible.
Whitebox is not, nor was it ever, deployed on 29% of all Linux webserver servers worldwide. CentOS is ... right now ... deployed on 29% of web servers on the Internet that use Linux. That is more than RHEL and Ubuntu combined: http://w3techs.com/technologies/details/os-linux/all/all
OK, if you are going to use that as an example, please tell me how many of those people made that choice knowing that updates were going to be months behind upstream. There's certainly nothing on the project web site to imply that.
How about I just use YOU as an example.
You CERTAINLY know how long the updates take.
How many INSTALLS of CentOS do you still choose to have?
On 4/13/2011 12:47 PM, Johnny Hughes wrote:
OK, if you are going to use that as an example, please tell me how many of those people made that choice knowing that updates were going to be months behind upstream. There's certainly nothing on the project web site to imply that.
How about I just use YOU as an example.
You CERTAINLY know how long the updates take.
How many INSTALLS of CentOS do you still choose to have?
I think you know the answer for CentOS 6. I haven't deployed any new services on CentOS since the 5.4 release, and am generally losing to the guy who favors SUSE here - and even the horde that favors Windows which has always been our largest deployment. It's not a 'no-brainer' anymore.
On Apr 13, 2011, at 10:55 AM, Les Mikesell wrote:
On 4/13/2011 12:47 PM, Johnny Hughes wrote:
OK, if you are going to use that as an example, please tell me how many of those people made that choice knowing that updates were going to be months behind upstream. There's certainly nothing on the project web site to imply that.
How about I just use YOU as an example.
You CERTAINLY know how long the updates take.
How many INSTALLS of CentOS do you still choose to have?
I think you know the answer for CentOS 6. I haven't deployed any new services on CentOS since the 5.4 release, and am generally losing to the guy who favors SUSE here - and even the horde that favors Windows which has always been our largest deployment.
Gross, Winblowz!
We use it as a workstation VM in a pretty large scale but since its a VM, doesn't seem so bad as our host and primary OS is Centos.
We've had some traction on Suse but since there is no comparable project like Centos in the Suse realm, its Centos all the way baby! - aurf
On 4/13/2011 1:01 PM, aurfalien@gmail.com wrote:
How many INSTALLS of CentOS do you still choose to have?
I think you know the answer for CentOS 6. I haven't deployed any new services on CentOS since the 5.4 release, and am generally losing to the guy who favors SUSE here - and even the horde that favors Windows which has always been our largest deployment.
Gross, Winblowz!
We use it as a workstation VM in a pretty large scale but since its a VM, doesn't seem so bad as our host and primary OS is Centos.
My gut feeling is the same, but it goes back to Win2k and earlier days. I can't think of anything that has been a problem with 64-bit win 2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
We've had some traction on Suse but since there is no comparable project like Centos in the Suse realm, its Centos all the way baby!
The SUSE-favoring guy has some tests that he says shows that their real-time kernel is essential for what his programs do - which is probably true for one particular instance.
On Apr 13, 2011, at 11:22 AM, Les Mikesell wrote:
On 4/13/2011 1:01 PM, aurfalien@gmail.com wrote:
How many INSTALLS of CentOS do you still choose to have?
I think you know the answer for CentOS 6. I haven't deployed any new services on CentOS since the 5.4 release, and am generally losing to the guy who favors SUSE here - and even the horde that favors Windows which has always been our largest deployment.
Gross, Winblowz!
We use it as a workstation VM in a pretty large scale but since its a VM, doesn't seem so bad as our host and primary OS is Centos.
My gut feeling is the same, but it goes back to Win2k and earlier days. I can't think of anything that has been a problem with 64-bit win 2003/2008
True dat.
I'm pleased with the 64 bit versions of XP and on (when compared to there 32 bit cousins).
- aurf
Les Mikesell wrote on 04/13/2011 02:22 PM:
I can't think of anything that has been a problem with 64-bit win 2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
http://wiki.centos.org/HowTos/CentOS5ConvertToRAID
Phil
On 4/13/2011 4:11 PM, Phil Schaffner wrote:
Les Mikesell wrote on 04/13/2011 02:22 PM:
I can't think of anything that has been a problem with 64-bit win 2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
Where the operative part of the bazillion step process is copy the data to the new device while running from a rescue CD, then making it bootable. This isn't really specific to CentOS - but on Windows (server versions) it is a mouse click to make a file system dynamic and then another one or two to add a mirror - with the system still running. Or you could use a few command line commands instead.
On Thursday, April 14, 2011 05:57 AM, Les Mikesell wrote:
On 4/13/2011 4:11 PM, Phil Schaffner wrote:
Les Mikesell wrote on 04/13/2011 02:22 PM:
I can't think of anything that has been a problem with 64-bit win2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
Where the operative part of the bazillion step process is copy the data to the new device while running from a rescue CD, then making it bootable. This isn't really specific to CentOS - but on Windows (server versions) it is a mouse click to make a file system dynamic and then another one or two to add a mirror - with the system still running. Or you could use a few command line commands instead.
Oh please don't tell the lads how great the gui and its backend are. You will see the hordes leave for Windows 200X Server!
On Apr 13, 2011, at 3:50 PM, Christopher Chan wrote:
On Thursday, April 14, 2011 05:57 AM, Les Mikesell wrote:
On 4/13/2011 4:11 PM, Phil Schaffner wrote:
Les Mikesell wrote on 04/13/2011 02:22 PM:
I can't think of anything that has been a problem with 64-bit win 2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
Where the operative part of the bazillion step process is copy the data to the new device while running from a rescue CD, then making it bootable. This isn't really specific to CentOS - but on Windows (server versions) it is a mouse click to make a file system dynamic and then another one or two to add a mirror - with the system still running. Or you could use a few command line commands instead.
Oh please don't tell the lads how great the gui and its backend are. You will see the hordes leave for Windows 200X Server!
Yea rite, gui/management tools are one thing but foot print, stability and cost to support are another.
- aurf
On 4/13/2011 5:50 PM, Christopher Chan wrote:
I can't think of anything that has been a problem with 64-bit win2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
Where the operative part of the bazillion step process is copy the data to the new device while running from a rescue CD, then making it bootable. This isn't really specific to CentOS - but on Windows (server versions) it is a mouse click to make a file system dynamic and then another one or two to add a mirror - with the system still running. Or you could use a few command line commands instead.
Oh please don't tell the lads how great the gui and its backend are. You will see the hordes leave for Windows 200X Server!
The GUI-ness isn't the point here. As I mentioned, you can use a command line in windows too. The point is that the underlying filesystem/raid has functionality that Linux versions lack and it turns out to be useful when you haven't done your planning well and don't want to be down for a while fixing it. I'd like to see even a rough approximation of this capability in Centos, like SME-server's ability to install on a 'broken' raid where you can add/sync the mirror later (but as an option, not your only choice...).
Les Mikesell wrote on 04/13/2011 07:22 PM: ...
I can't think of anything that has been a problem with 64-bit win2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
...
The GUI-ness isn't the point here.
We are already way OT, for both the list and the thread, and could get into the whole discussion about closed versus open source solutions; but your point was that you could decide to change after the fact in Windows, and my point was that the CentOS Wiki tells you how to do so for CentOS.
We are agreed that "The GUI-ness isn't the point here."
I'm done with this sub-thread.
Phil
On Apr 13, 2011, at 4:51 PM, Phil Schaffner wrote:
Les Mikesell wrote on 04/13/2011 07:22 PM: ...
I can't think of anything that has been a problem with 64-bit win 2003/2008 as production servers and I sort of like the way you can decide after-the-fact that you want to convert a disk to software raid.
...
The GUI-ness isn't the point here.
We are already way OT, for both the list and the thread, and could get into the whole discussion about closed versus open source solutions; but your point was that you could decide to change after the fact in Windows, and my point was that the CentOS Wiki tells you how to do so for CentOS.
We are agreed that "The GUI-ness isn't the point here."
I'm done with this sub-thread.
I like Twinkies.
Comments any one?
Johnny Hughes wrote on 04/13/2011 12:55 PM:
CentOS is ... right now ... deployed on 29% of web servers on the Internet that use Linux.
That 28.9% is down from the high of 33.5% in Oct. 2010 or a 13.8% decrease. http://w3techs.com/technologies/history_details/os-linux
Phil
On 4/14/11, Phil Schaffner Philip.R.Schaffner@nasa.gov wrote:
Johnny Hughes wrote on 04/13/2011 12:55 PM:
CentOS is ... right now ... deployed on 29% of web servers on the Internet that use Linux.
That 28.9% is down from the high of 33.5% in Oct. 2010 or a 13.8% decrease. http://w3techs.com/technologies/history_details/os-linux
It coincides very nicely with a similar increase in Debian and Ubuntu usage. Anybody knows what happened around/before that period that might had initiated the migrations? Since it's based on web servers, surely it can't be the multi-touch support in Ubuntu 10.10 :)
[Donning my Nomex/Kevlar/non-friable asbestos suit here....]
On Thursday, April 14, 2011 12:25:49 AM Emmanuel Noobadmin wrote:
On 4/14/11, Phil Schaffner Philip.R.Schaffner@nasa.gov wrote:
Johnny Hughes wrote on 04/13/2011 12:55 PM:
CentOS is ... right now ... deployed on 29% of web servers on the Internet that use Linux.
That 28.9% is down from the high of 33.5% in Oct. 2010 or a 13.8% decrease. http://w3techs.com/technologies/history_details/os-linux
It coincides very nicely with a similar increase in Debian and Ubuntu usage. Anybody knows what happened around/before that period that might had initiated the migrations? Since it's based on web servers, surely it can't be the multi-touch support in Ubuntu 10.10 :)
As much as I like CentOS, and as much as I appreciate the CentOS team's work, I can't help but see a correlation in the timeframes of the beginning of the latest round of 'intense discussions' on the list and the decrease in that percentage.
People have been told to go elsewhere if they didn't like the status quo, and it seems that they have. It might not be the reason; but it could be the reason.
Just stating a simple correlation; not making a judgment call from that correlation, and not giving a detailed, dramatic, commentary on it either.
And I plan to stick with CentOS for the foreseable future, unless events cause a need to change things (similar to the events that caused me to take our WhiteBox machines to CentOS years ago).
On 4/11/2011 4:04 PM, m.roth@5-cent.us wrote:
I must be missing something here. If it had been someone I didn't know, that's one thing, but Dag's been contributing to Linux as a whole for a lotta years, and his site is a major repository.
Heh, I suppose we could have approximately the same conversion about getting all the stuff in various 3rd party rpm repositories coordinated so they never cause conflicts during updates. Or maybe we have...
On Mon, 11 Apr 2011, Les Mikesell wrote:
On 4/11/2011 4:04 PM, m.roth@5-cent.us wrote:
I must be missing something here. If it had been someone I didn't know, that's one thing, but Dag's been contributing to Linux as a whole for a lotta years, and his site is a major repository.
Heh, I suppose we could have approximately the same conversion about getting all the stuff in various 3rd party rpm repositories coordinated so they never cause conflicts during updates. Or maybe we have...
We have :-) When the Fedora project started there was a big discussion. There was no interest in doing RHEL packages together with RPMForge back then, the Fedora project then saw this additional task a risk to their new Fedora Extras repository.
4 years after that they did start EPEL, but too much conflicts for us to even attempt to fix any issues. And here we are :-/
On Mon, 11 Apr 2011, Tru Huynh wrote:
I only see wasted time talking, no actions. I will be happy to be proven wrong.
We are more alike than it seems at first. I don't see actions either, I only see the output of actions because the process is deliberately closed.
On 4/11/2011 3:54 PM, Tru Huynh wrote:
I might throw some time and equipment at it if I knew I wasn't re-inventing square wheels (or even round ones for that matter). And I suspect that others smarter than I am would do the same and maybe even improve the approach by coming up with ways to predict the build environment needed to reproduce a given binary to reduce the trial-and-error time.
Same answer for you than I made for Dag, volonteer to coordinate, build, write scripts, publish *your* work and you will be helping your fellows.
I don't have any illusions about being able to do it better than the existing group. How would a bunch of beginners publishing how to do things badly help anyone? Besides, if I were doing it myself I'd have very little interest in the time-consuming details that make it easy to convert to a supported upstream instance.
On 04/11/2011 11:54 PM, Tru Huynh wrote:
On Mon, Apr 11, 2011 at 03:37:28PM -0500, Les Mikesell wrote:
On 4/11/2011 2:59 PM, Tru Huynh wrote:
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
So having everyone repeat the same mistakes with no coordination is your idea of doing things faster?
who is everyone?
I might throw some time and equipment at it if I knew I wasn't re-inventing square wheels (or even round ones for that matter). And I suspect that others smarter than I am would do the same and maybe even improve the approach by coming up with ways to predict the build environment needed to reproduce a given binary to reduce the trial-and-error time.
Same answer for you than I made for Dag, volonteer to coordinate, build, write scripts, publish *your* work and you will be helping your fellows.
Oh really? If each tech would do his own rebuild and then publish it we would end up with a few thousand more distributions. I doubt we all can then follow all that work. I think we are having this discussion since we want to improve CentOS, not have our own distro. I think if somebody wants his own, he already has it or he is working on it behind closed doors (ahem...).
But I don't see this happening if the process stays closed any more than I think there would be a useful Linux today - or most of the packages comprising Red Hat's product - if development had not been open and shared.
I only see wasted time talking, no actions. I will be happy to be proven wrong.
Tru
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 11 Apr 2011, Tru Huynh wrote:
- back to your genuine inquiry "how can I help it be ready faster?"
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
[... anything usefull for your CentOS community ...]
Yes, let's all do the same thing, and stumble over the same problems, while they may already have fixed in the closed QA builds.
Sounds like one crazy plan !
On Mon, Apr 11, 2011 at 09:48:18PM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
- back to your genuine inquiry "how can I help it be ready faster?"
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
[... anything usefull for your CentOS community ...]
Yes, let's all do the same thing, and stumble over the same problems, while they may already have fixed in the closed QA builds.
Sounds like one crazy plan !
right: you are locked inside a maze, there is one exit somewhere. Everyone start from the same place, eveyone benefit from the person who find the exit. We don't have the solution at the moment, You get the QA builds once we find the exit. If you finish before us let us know how you did it.
On Mon, 11 Apr 2011, Tru Huynh wrote:
On Mon, Apr 11, 2011 at 09:48:18PM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
- back to your genuine inquiry "how can I help it be ready faster?"
Make your own experiment (i.e rebuild your own clone) and document/report back what you find out as the proper order of rebuild of the upstream SRPMS ?
[... anything usefull for your CentOS community ...]
Yes, let's all do the same thing, and stumble over the same problems, while they may already have fixed in the closed QA builds.
Sounds like one crazy plan !
right: you are locked inside a maze, there is one exit somewhere. Everyone start from the same place, eveyone benefit from the person who find the exit. We don't have the solution at the moment, You get the QA builds once we find the exit. If you finish before us let us know how you did it.
No, you have 2500 mazes, and you have to finish each of them before you can start the next one. In the meantime, other people (including the CentOS people) are getting lost in that same (but copied) maze, so you cannot help each other find the exit, until you do.
Let's waste time together fixing something that someone may already have fixed, who wouldn't be excited about that !
On Mon, Apr 11, 2011 at 10:00:57PM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
right: you are locked inside a maze, there is one exit somewhere. Everyone start from the same place, eveyone benefit from the person who find the exit. We don't have the solution at the moment, You get the QA builds once we find the exit. If you finish before us let us know how you did it.
No, you have 2500 mazes, and you have to finish each of them before you can start the next one. In the meantime, other people (including the CentOS people) are getting lost in that same (but copied) maze, so you cannot help each other find the exit, until you do.
My maze is the build order (ie dependancy order of the SRPMS), What are yours? how do you get to that number of mazes?
Feel free to coordinate, we will all profit from your coordination skills.
Let's waste time together fixing something that someone may already have fixed, who wouldn't be excited about that !
Is this kind of useless discussion better?
[free troll feeding is over for me]
On Mon, Apr 11, 2011 at 10:13 PM, Tru Huynh tru@centos.org wrote:
[free troll feeding is over for me]
Do you want payment for your troll feeding now? ;)
On Mon, 11 Apr 2011, Tru Huynh wrote:
On Mon, Apr 11, 2011 at 10:00:57PM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
right: you are locked inside a maze, there is one exit somewhere. Everyone start from the same place, eveyone benefit from the person who find the exit. We don't have the solution at the moment, You get the QA builds once we find the exit. If you finish before us let us know how you did it.
No, you have 2500 mazes, and you have to finish each of them before you can start the next one. In the meantime, other people (including the CentOS people) are getting lost in that same (but copied) maze, so you cannot help each other find the exit, until you do.
My maze is the build order (ie dependancy order of the SRPMS), What are yours? how do you get to that number of mazes?
The build order is not what took 86 days, was it ?
Feel free to coordinate, we will all profit from your coordination skills.
We don't need the coordination anymore, you have the secret now for CentOS 5.6 (and the previous builds) I am certain that if more people understood the basic problems with building CentOS, more people would be skilled to help in the next iteration.
Now every release that is closed, is a lost opportunity to attract more people.
Let's waste time together fixing something that someone may already have fixed, who wouldn't be excited about that !
Is this kind of useless discussion better?
If it would help to get more people the skills to help with the release, absolutely ! No community project thrives by keeping potential contributors ignorant.
It's only useless if there's no change.
On Mon, Apr 11, 2011 at 10:20:59PM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
...
My maze is the build order (ie dependancy order of the SRPMS), What are yours? how do you get to that number of mazes?
The build order is not what took 86 days, was it ?
it's too easy to answer my question by yet another stab.
So where are these thousands of mazes?
On Mon, 11 Apr 2011, Tru Huynh wrote:
On Mon, Apr 11, 2011 at 10:20:59PM +0200, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
...
My maze is the build order (ie dependancy order of the SRPMS), What are yours? how do you get to that number of mazes?
The build order is not what took 86 days, was it ?
it's too easy to answer my question by yet another stab.
It's not a stab. Although if you take everything personal, you might think it is.
You implied that only the build order is what makes it hard. I doubt that build order is what took 86 days. But I don't know what exactly took 86 days, because the build process and the problems are closed.
So this discussion may seem to you as trolling, but I cannot be more specific, can I ? Transparancy would actually make this discussion worthwhile, maybe even exciting, and solutions possible.
So where are these thousands of mazes?
Well, every package that needs to be rebuild is a maze. If you require everyone to rebuild the same package and potentially troubleshoot that package, you are duplicating A LOT OF work, and you may be introducing differences in builds (due to build order) that make problems unique to a specific build.
So not only would that be unworkable, it would be deliberatly harder to release sooner.
All when CentOS is already doing some of that work, behind doors.
On Mon, 11 Apr 2011, Tru Huynh wrote:
On Mon, Apr 11, 2011 at 08:19:22PM +0200, Dag Wieers wrote:
Considering you follow the "it's released when it's ready" mantra, what
[ ... ]
I no longer expect any change.
Then why are you always coming back here to voice your concerns if you don't expect any change?
Convince me otherwise. These concerns are not just my concerns, I have had companies calling me for more information or advice because these questions go unanswered.
But few people dare to raise their voice on this list.
There have been interviews by CentOS developers on popular websites in the past promising improvements to how the project is organized, but releases take longer and development/QA stays closed. Why is that ?
On 04/11/2011 03:10 PM, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
On Mon, Apr 11, 2011 at 08:19:22PM +0200, Dag Wieers wrote:
Considering you follow the "it's released when it's ready" mantra, what
[ ... ]
I no longer expect any change.
Then why are you always coming back here to voice your concerns if you don't expect any change?
Convince me otherwise. These concerns are not just my concerns, I have had companies calling me for more information or advice because these questions go unanswered.
But few people dare to raise their voice on this list.
There have been interviews by CentOS developers on popular websites in the past promising improvements to how the project is organized, but releases take longer and development/QA stays closed. Why is that ?
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
Perhaps the tact to take is to apply pressure to the upstream provider to release the build details? I am sure that many folks who start with CentOS, grow to be large and move to RH proper. So there is, I would venture, an argument to be made that RH providing this info to CentOS and helping CentOS thrive would be beneficial for their business.
centos-bounces@centos.org wrote:
/putting on asbestos pants.
Not needed... And they itch.
Perhaps the tack to take is to apply pressure to the upstream provider to release the build details? I am sure that many folks who start with CentOS, grow to be large and move to RH proper. So there is, I would venture, an argument to be made that RH providing this info to CentOS and helping CentOS thrive would be beneficial for their business.
I should think to agree; if the CentOS folks are under a non-disclosure to "any entity selling support other than RH", I don't see how this is anything but in RH's best interests.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Mon, 11 Apr 2011, Digimer wrote:
On 04/11/2011 03:10 PM, Dag Wieers wrote:
On Mon, 11 Apr 2011, Tru Huynh wrote:
On Mon, Apr 11, 2011 at 08:19:22PM +0200, Dag Wieers wrote:
Considering you follow the "it's released when it's ready" mantra, what
[ ... ]
I no longer expect any change.
Then why are you always coming back here to voice your concerns if you don't expect any change?
Convince me otherwise. These concerns are not just my concerns, I have had companies calling me for more information or advice because these questions go unanswered.
But few people dare to raise their voice on this list.
There have been interviews by CentOS developers on popular websites in the past promising improvements to how the project is organized, but releases take longer and development/QA stays closed. Why is that ?
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
Not true for eg. CentOS 4.8 and CentOS 5.6, the complexity of those two or no more different than CentOS 4.7 or CentOS 5.5. Besides that, if you open up the QA and problems, there are more people that can jump in and help fix one issue.
I have compared it to the development of the Linux kernel, either you try to do everything by 3 people, or you open it up and let the community provide you with issues and provide pull requests. So that those 3 people simply have to merge those pull requests. It's a lot less work by the core, and it scales better because all those people waiting for the new release to be ready can actively participate and _make_ that release faster.
I would basicly make the whole discussion void, because anyone complaining could actively help the release go forward. Now we both know exactly what the issue was, we can guess or have to accept vague information.
Perhaps the tact to take is to apply pressure to the upstream provider to release the build details? I am sure that many folks who start with CentOS, grow to be large and move to RH proper. So there is, I would venture, an argument to be made that RH providing this info to CentOS and helping CentOS thrive would be beneficial for their business.
Well, that could be useful too, but why sit and wait for something you cannot control to happen. Or take a decision that the project can implement today.
On 11/04/11 20:16, Digimer wrote:
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
Perhaps the tact to take is to apply pressure to the upstream provider to release the build details? I am sure that many folks who start with CentOS, grow to be large and move to RH proper. So there is, I would venture, an argument to be made that RH providing this info to CentOS and helping CentOS thrive would be beneficial for their business.
On 4/11/2011 4:02 PM, Ned Slider wrote:
On 11/04/11 20:16, Digimer wrote:
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple... They don't ship until they reproduce something that they consider 'binary compatible' to the upstream binaries, which depends on a build environment containing some things that don't match the sources. Some of this is documented for the similar SL build but they aren't as picky about library linkage versions (which may not matter functionally anyway).
On Mon, 11 Apr 2011, Les Mikesell wrote:
On 4/11/2011 4:02 PM, Ned Slider wrote:
On 11/04/11 20:16, Digimer wrote:
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple... They don't ship until they reproduce something that they consider 'binary compatible' to the upstream binaries, which depends on a build environment containing some things that don't match the sources. Some of this is documented for the similar SL build but they aren't as picky about library linkage versions (which may not matter functionally anyway).
Les,
It's unfair to Scientific Linux to imply that Scientific Linux does not care about compatibility. The issues reported on this list by Johnny to discredit SL were found in the 5.6 alpha release, already fixed by SL and improperly used to discredit SL.
Johnny found those packages when comparing his own build-issues against Scientific's Linux release, while the Scientific Linux project has no such means to do the same because CentOS does not provide public alpha and beta releases.
It's one thing to find an issue in a competing product, but it's another to bring it up on this mailinglist to discredit a competing product (just because it is truly open and has a public alpha release).
CentOS obviously looks at how Scientific Linux is fixing issues, but keeping their own fixes secret.
PS The notion that Scientific Linux does not care about compatbility is a false claim and it needs to stop.
On 04/11/2011 05:07 PM, Dag Wieers wrote:
On Mon, 11 Apr 2011, Les Mikesell wrote:
On 4/11/2011 4:02 PM, Ned Slider wrote:
On 11/04/11 20:16, Digimer wrote:
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple... They don't ship until they reproduce something that they consider 'binary compatible' to the upstream binaries, which depends on a build environment containing some things that don't match the sources. Some of this is documented for the similar SL build but they aren't as picky about library linkage versions (which may not matter functionally anyway).
Les,
It's unfair to Scientific Linux to imply that Scientific Linux does not care about compatibility. The issues reported on this list by Johnny to discredit SL were found in the 5.6 alpha release, already fixed by SL and improperly used to discredit SL.
Johnny found those packages when comparing his own build-issues against Scientific's Linux release, while the Scientific Linux project has no such means to do the same because CentOS does not provide public alpha and beta releases.
It's one thing to find an issue in a competing product, but it's another to bring it up on this mailinglist to discredit a competing product (just because it is truly open and has a public alpha release).
CentOS obviously looks at how Scientific Linux is fixing issues, but keeping their own fixes secret.
PS The notion that Scientific Linux does not care about compatbility is a false claim and it needs to stop.
I did not do anything to discredit anyone and I take exception to that term.
I published an example of WHY CentOS does not release anything until we check it via QA. Once something is released, it can not "come back".
What I said was what CentOS does if we have a problem (look at other distros to see if they have the same problem).
I did not say that SL does not care about compatibility, nor did I make any claims that CentOS was more or less compatible than SL. If users what to find out the answer to that, then they can take the time to run the tests.
SL is a great product. If I did not use CentOS, I would use it.
However, CentOS is locked in a battle with Debian as the "Leader of Webservers" on the top 1 million websites for the world. 29% of the Linux websites in the world use CentOS:
http://w3techs.com/technologies/history_details/os-linux
CentOS has been the "Market Leader" for web server installs on the top 1 million websites for the last year.
You can like it CentOS or dislike it, however the numbers do not lie.
We will, therefore, release our products after we QA test them as we have to maintain the quality that people have come to expect.
And I have known that all of YOUR concern about the process has always been so you can try to steal our users Dag. If you want to steal our users for your rebuild then you can do that.
On Tue, 12 Apr 2011, Johnny Hughes wrote:
On 04/11/2011 05:07 PM, Dag Wieers wrote:
On Mon, 11 Apr 2011, Les Mikesell wrote:
On 4/11/2011 4:02 PM, Ned Slider wrote:
On 11/04/11 20:16, Digimer wrote:
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple... They don't ship until they reproduce something that they consider 'binary compatible' to the upstream binaries, which depends on a build environment containing some things that don't match the sources. Some of this is documented for the similar SL build but they aren't as picky about library linkage versions (which may not matter functionally anyway).
It's unfair to Scientific Linux to imply that Scientific Linux does not care about compatibility. The issues reported on this list by Johnny to discredit SL were found in the 5.6 alpha release, already fixed by SL and improperly used to discredit SL.
Johnny found those packages when comparing his own build-issues against Scientific's Linux release, while the Scientific Linux project has no such means to do the same because CentOS does not provide public alpha and beta releases.
It's one thing to find an issue in a competing product, but it's another to bring it up on this mailinglist to discredit a competing product (just because it is truly open and has a public alpha release).
CentOS obviously looks at how Scientific Linux is fixing issues, but keeping their own fixes secret.
PS The notion that Scientific Linux does not care about compatbility is a false claim and it needs to stop.
I did not do anything to discredit anyone and I take exception to that term.
I published an example of WHY CentOS does not release anything until we check it via QA. Once something is released, it can not "come back".
Johnny, you are right. I have to apologize for those remarks, they were out of line. Still the notion exists (and has been repeated) that Scientific Linux does not care about binary compatibility. Even if this was not what you intended.
What I said was what CentOS does if we have a problem (look at other distros to see if they have the same problem).
But you have to agree that Scientific Linux does not have that (reverse) privilege.
And I have known that all of YOUR concern about the process has always been so you can try to steal our users Dag. If you want to steal our users for your rebuild then you can do that.
There is no such rebuild at this time. That twitter message was started with 'Wouldn't it be nice...', but I ran out of 140 characters to make a statement :)
I was surprised by the reaction though, although I won't be able to pull that off by myself, hopefully I can add my support to such a project. Even when being part of the team I have stated that the best thing that could happen to CentOS is more competition, and I still stand by that.
I know you have been telling people to roll their own too.
On 04/12/2011 07:24 AM, Dag Wieers wrote:
On Tue, 12 Apr 2011, Johnny Hughes wrote:
On 04/11/2011 05:07 PM, Dag Wieers wrote:
On Mon, 11 Apr 2011, Les Mikesell wrote:
On 4/11/2011 4:02 PM, Ned Slider wrote:
On 11/04/11 20:16, Digimer wrote:
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple... They don't ship until they reproduce something that they consider 'binary compatible' to the upstream binaries, which depends on a build environment containing some things that don't match the sources. Some of this is documented for the similar SL build but they aren't as picky about library linkage versions (which may not matter functionally anyway).
It's unfair to Scientific Linux to imply that Scientific Linux does not care about compatibility. The issues reported on this list by Johnny to discredit SL were found in the 5.6 alpha release, already fixed by SL and improperly used to discredit SL.
Johnny found those packages when comparing his own build-issues against Scientific's Linux release, while the Scientific Linux project has no such means to do the same because CentOS does not provide public alpha and beta releases.
The issue is that people are using those releases in production and claiming that they are "production ready". Whether that is the intention of the SL team or not, that is what is happening. People get on these lists and claim that those packages are the security updates from SL and that they have "released before CentOS" because they exist. They are instead Beta or Alpha and should not be used in production (IMHO) ... but everyone gets to control their own servers.
The CentOS team does not think that is the best approach. We do not think that packages floating around in the general public with the same EVR that will be released in final form (as we can not change the EVR for the vast majority of our packages) is the way to go. Because of this, the QA process is controlled, not closed. You control submission to your repos ... not everyone can submit directly into your build system. Not everyone can sign your packages.
It's one thing to find an issue in a competing product, but it's another to bring it up on this mailinglist to discredit a competing product (just because it is truly open and has a public alpha release).
CentOS obviously looks at how Scientific Linux is fixing issues, but keeping their own fixes secret.
SL did not tell me anything about their packages ... I looked at their RPM and their SRPM. I looked at the Oracle RPM and SRPM. I looked at the RHEL RPM and SRPM. I looked at the Red Hat bugzilla. Akemi Yagi also looked at the RH bugzilla and found the issue. The issue is a leap year issue. A test fails because there is an extra day in a calculation after Feb 28th 2011 that is not there before that date if you build the package.
PS The notion that Scientific Linux does not care about compatbility is a false claim and it needs to stop.
I did not do anything to discredit anyone and I take exception to that term.
I published an example of WHY CentOS does not release anything until we check it via QA. Once something is released, it can not "come back".
Johnny, you are right. I have to apologize for those remarks, they were out of line. Still the notion exists (and has been repeated) that Scientific Linux does not care about binary compatibility. Even if this was not what you intended.
And I have posted several times about this. What SL does do is they publish lots of things on their main ISOs and tree that are not part of the upstream distro. That can be either good or bad, depending on your point of view. My personal opinion on the matter is that at install time, you should stay within the same universe of packages to the maximum extent practical. In CentOS-2,3, and 4 we added yum {and the necessary dependencies} when they were not in the upstream distro, so we do it as well ... however, I personally think that should be minimized.
What I said was what CentOS does if we have a problem (look at other distros to see if they have the same problem).
But you have to agree that Scientific Linux does not have that (reverse) privilege.
I do not agree with that. They can look at anything we release, just like I can look at anything they release, anything oracle releases, or anything upstream releases. We have an obligation to minimize putting things out there that are wrong. We provided the QA team with access to an initial 5.6 tree a very long time ago. (The first packages showed up there in QA for initial testing on January 26, 2011 ... and we finally got a release on April 8, 2011).
Also, both Connie and Troy are more than welcome to be members of the CentOS QA team. In fact, at one time Connie was a member of the CentOS QA team. We appreciate the fact that they may not have time to do this and build their distro too, so we don't expect them to do so, but they could if they wanted to.
And I have known that all of YOUR concern about the process has always been so you can try to steal our users Dag. If you want to steal our users for your rebuild then you can do that.
There is no such rebuild at this time. That twitter message was started with 'Wouldn't it be nice...', but I ran out of 140 characters to make a statement :)
I was surprised by the reaction though, although I won't be able to pull that off by myself, hopefully I can add my support to such a project. Even when being part of the team I have stated that the best thing that could happen to CentOS is more competition, and I still stand by that.
I know you have been telling people to roll their own too.
If people want to roll their own, they can. I have provided all the information for them to do that in several posts.
I encourage them to do it (if for no other reason than a learning experience). I then encourage them to think about how they can scale a delivery system so it can run on 29% of the world's Linux servers, and how they can maintain that "delivery system" of hundreds of machines to provide a distro to millions of users.
We have an obligation to the "hardware providers" as well, to control/minimize the access to the machines they donate so that they are used only for what the donors intend.
You have said yourself that only you will sign your rpmforge packages. You also understand the need to control some things close to the vest.
I have to use this (CentOS) in production, it has to be right. We do not want bad packages floating around out there.
On Tuesday, April 12, 2011 09:30:43 AM Johnny Hughes wrote:
They are instead Beta or Alpha and should not be used in production (IMHO) ... but everyone gets to control their own servers.
Let me echo this, and state that the alpha and beta announcements I have seen from the SL team say the same thing; their alphas and betas are not intended for production use.
The only disagreement I would have with them is calling the alphas and betas 'releases.' But it's their distribution.
Lamar Owen wrote:
The only disagreement I would have with them is calling the alphas and betas 'releases.' But it's their distribution.
Word "release" means anything send out to the wild. Like you would release some animal after you cured it's broken leg/wing.
I think proper term for what they do is "distribution version" that is released. We all just got spoiled and in the lack of better term shortened it to just "release".
Ljubomir
On Mon, Apr 11, 2011 at 2:38 PM, Les Mikesell lesmikesell@gmail.com wrote:
It's not simple... They don't ship until they reproduce something that they consider 'binary compatible' to the upstream binaries, which depends on a build environment containing some things that don't match the sources. Some of this is documented for the similar SL build but they aren't as picky about library linkage versions (which may not matter functionally anyway).
Are you referring to Johnny's old post? I hope his message is not interpreted to mean that SL is not as conscience about compatibility as CentOS is. As I wrote in:
http://lists.centos.org/pipermail/centos-devel/2011-March/007201.html
the example package that was quoted in Johnny's mail was from SL's _Alpha_ version. As I suspected, those mismatches in the library had been taken care of when SL went from Alpha to Beta (I checked on this). Just for anyone's reference, CentOS did have the same issue early in the QA process which was noticed by a QA member and corrected.
I think that Johnny, in his recent posts, tried to address potential misinterpretation of his earlier post.
Akemi
On 11/04/11 22:38, Les Mikesell wrote:
On 4/11/2011 4:02 PM, Ned Slider wrote:
On 11/04/11 20:16, Digimer wrote:
/putting on asbestos pants.
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple...
Which part isn't simple?
You rebuild a SRPM package in mock - that's simple, largely thanks to mock and rpmbuild.
You compare said rebuilt package to upstream's - that's simple, Johnny even provides a script to do it.
95% plus of packages rebuild perfectly first time, those are really simple.
A small percentage of packages need rebuilding against the correct libraries or package versions. RPM provides you with all the tools you need to figure this out. It's laborious, it's repetitive, it's boring, sometimes it's time-consuming but it's really NOT difficult.
On 4/11/2011 5:32 PM, Ned Slider wrote:
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple...
Which part isn't simple?
The part where you guess why your build doesn't match the upstream binary.
95% plus of packages rebuild perfectly first time, those are really simple.
OK...
A small percentage of packages need rebuilding against the correct libraries or package versions. RPM provides you with all the tools you need to figure this out.
If RPM dependencies were all you needed and the matching targets existed, the question wouldn't even come up.
It's laborious, it's repetitive, it's boring, sometimes it's time-consuming but it's really NOT difficult.
That depends on where and whether you can find the component(s) that were missing or the wrong version. But, it seems that if you have an after-the-build test, there might be a way to predict what you need to pass that test ahead of time - or at least to run all of the possible combinations in parallel if you really have to do trial-and-error.
On Mon, 11 Apr 2011, Les Mikesell wrote:
On 4/11/2011 5:32 PM, Ned Slider wrote:
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple...
Which part isn't simple?
The part where you guess why your build doesn't match the upstream binary.
If it was simple, why would it take 86 days or 6 months ? I would like to have an answer to that. Either it is hard, and more people could help fix issues. Or it is simple and the CentOS developers have been slacking ?
Anyone from the QA team interested to share some information on what happened during QA ?
Dag Wieers wrote on 04/11/2011 07:03 PM: ...
Anyone from the QA team interested to share some information on what happened during QA ?
A very limited group did a lot of work on QA and missed some issues that might have been caught by a more open process.
"Given enough eyeballs, all bugs are shallow." - Linus Torvalds http://en.wikipedia.org/wiki/Linus%27_Law
CentOS is failing to take full advantage of the available and willing eyeballs and other body parts.
Phil
On 12/04/11 00:03, Dag Wieers wrote:
On Mon, 11 Apr 2011, Les Mikesell wrote:
On 4/11/2011 5:32 PM, Ned Slider wrote:
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
It's not simple...
Which part isn't simple?
The part where you guess why your build doesn't match the upstream binary.
If it was simple, why would it take 86 days or 6 months ? I would like to have an answer to that. Either it is hard, and more people could help fix issues. Or it is simple and the CentOS developers have been slacking ?
In fairness, I did say it could be time consuming. I don't know what took 86 days.
Anyone from the QA team interested to share some information on what happened during QA ?
The QA team are not permitted to comment on such matters as QA is a closed process.
Les Mikesell wrote on 04/11/2011 06:58 PM:
On 4/11/2011 5:32 PM, Ned Slider wrote:
...
It's laborious, it's repetitive, it's boring, sometimes it's time-consuming but it's really NOT difficult.
That depends on where and whether you can find the component(s) that were missing or the wrong version. But, it seems that if you have an after-the-build test, there might be a way to predict what you need to pass that test ahead of time - or at least to run all of the possible combinations in parallel if you really have to do trial-and-error.
Sounds a bit too much like AI to me.
Johnny addressed finding the components earlier, and they may not be discoverable.
http://lists.centos.org/pipermail/centos/2011-April/109631.html
If you have a way to do those predictive tests, in serial or parallel, I'm sure that would be a valuable contribution. The possible combinations quickly lead to a combinatorial explosion. Software regression testing is a science in its own right.
I think the best a community project can do on testing such packages is by flagging them for attention in a more open process with more testers.
Phil
Phil Schaffner wrote:
Les Mikesell wrote on 04/11/2011 06:58 PM:
On 4/11/2011 5:32 PM, Ned Slider wrote:
...
It's laborious, it's repetitive, it's boring, sometimes it's time-consuming but it's really NOT difficult.
That depends on where and whether you can find the component(s) that were missing or the wrong version. But, it seems that if you have an after-the-build test, there might be a way to predict what you need to pass that test ahead of time - or at least to run all of the possible combinations in parallel if you really have to do trial-and-error.
Sounds a bit too much like AI to me.
Johnny addressed finding the components earlier, and they may not be discoverable.
http://lists.centos.org/pipermail/centos/2011-April/109631.html
If you have a way to do those predictive tests, in serial or parallel, I'm sure that would be a valuable contribution. The possible combinations quickly lead to a combinatorial explosion. Software regression testing is a science in its own right.
I think the best a community project can do on testing such packages is by flagging them for attention in a more open process with more testers.
Phil
I've already thought about this. When I try to recompile some package from Fedora for CentOS 5.x, I miss having package dependency database that is easy to follow.
I was thinking of creating following:
App that would parse primary.xml, filelists.xml and other.xml from each enabled repository and populate SQLite or MySQL database and would then allow to show tree-like dependencies for selected package. With all dependencies down to the last one, so if package1 depends on package2, package3 and, package4, and package2 depends on package6 and package7, all of those packages would be shown with respective version numbers.
The same XML format is for srpm repo folders, so we can have fast way of checking for dependencies.
Once you populate that database with srpms from all Fedora and RHEL versions (with all versions of every package), you could mix and match easier.
But I seam to be out of free time to start it, and my programming skills on Linux are currently stuck on very advanced bash.
Ljubomir
On 04/12/2011 12:46 AM, Phil Schaffner wrote:
If you have a way to do those predictive tests, in serial or parallel, I'm sure that would be a valuable contribution. The possible combinations quickly lead to a combinatorial explosion.
Quite a large part of the functional tests can be automated - specially if there are going to be 100's of people offering them up. Wihtout a doubt we need more of those.
I think the best a community project can do on testing such packages is by flagging them for attention in a more open process with more testers.
Testers are one part of the equation, what we need more of, imho, is more people in a position to do things before packages hit the testers. Hence, the request for people to step up with relevant experience and exposure to specific parts of the distro.
- KB
Karanbir Singh wrote on 04/12/2011 07:43 AM:
Quite a large part of the functional tests can be automated - specially if there are going to be 100's of people offering them up. Wihtout a doubt we need more of those.
Agree - whatever can be automated should be. It is the predictive part I was questioning more so than automation per se, as well as pointing out that automation has its limits.
Testers are one part of the equation, what we need more of, imho, is more people in a position to do things before packages hit the testers. Hence, the request for people to step up with relevant experience and exposure to specific parts of the distro.
Agree!
Phil
Karanbir Singh wrote:
On 04/12/2011 12:46 AM, Phil Schaffner wrote:
If you have a way to do those predictive tests, in serial or parallel, I'm sure that would be a valuable contribution. The possible combinations quickly lead to a combinatorial explosion.
Quite a large part of the functional tests can be automated - specially if there are going to be 100's of people offering them up. Wihtout a doubt we need more of those.
<snip> Let me *strongly* suggest that tests *should* be automated. Not only is it faster, but for regression tests, a human tester will miss occasional steps, where an automated set will guarantee every step is completed.
And it's a *hell* of a lot less boring. Here we go: a screensaver CentOS regression tester....
mark
On 04/12/2011 02:11 PM, m.roth@5-cent.us wrote:
Let me *strongly* suggest that tests *should* be automated. Not only is it faster, but for regression tests, a human tester will miss occasional steps, where an automated set will guarantee every step is completed.
there is a process and request going for people to contribute tests, why have you not done any as yet ?
- KB
Karanbir Singh wrote:
On 04/12/2011 02:11 PM, m.roth@5-cent.us wrote:
Let me *strongly* suggest that tests *should* be automated. Not only is it faster, but for regression tests, a human tester will miss occasional steps, where an automated set will guarantee every step is completed.
there is a process and request going for people to contribute tests, why have you not done any as yet ?
RW: between work, and moving, and most of my stuff in storage at the moment while I house-hunt, and, oh, yes, worrying about whether we're working Friday, here with the US gov't....
Btw, I've been a programmer and sysadmin, not a tester - that's special skill that I'm not great at. When I was working at AT&T, we had a woman who was *REALLY* good at it, like no one I've ever seen. As I said, that's a separate skill.
mark "oh, yes, copious spare time"
On 04/12/2011 03:33 PM, m.roth@5-cent.us wrote:
RW: between work, and moving, and most of my stuff in storage at the moment while I house-hunt, and, oh, yes, worrying about whether we're working Friday, here with the US gov't....
I hear you, 38 hrs/week at dayjob, then 30hrs/week on CentOS and then a life....
Btw, I've been a programmer and sysadmin, not a tester - that's special skill that I'm not great at. When I was working at AT&T, we had a woman who was *REALLY* good at it, like no one I've ever seen. As I said, that's a separate skill.
I was really hoping for you to reply with something along the lines of 'there isnt enough info about the test process' or 'are there some templates that we can start with' etc. Those things I can try to do something about, finding you more time in the day is a bit harder :D
- KB
Karanbir Singh wrote:
On 04/12/2011 03:33 PM, m.roth@5-cent.us wrote:
RW: between work, and moving, and most of my stuff in storage at the moment while I house-hunt, and, oh, yes, worrying about whether we're working Friday, here with the US gov't....
I hear you, 38 hrs/week at dayjob, then 30hrs/week on CentOS and then a life....
Btw, I've been a programmer and sysadmin, not a tester - that's special skill that I'm not great at. When I was working at AT&T, we had a woman who was *REALLY* good at it, like no one I've ever seen. As I said, that's a separate skill.
I was really hoping for you to reply with something along the lines of 'there isnt enough info about the test process' or 'are there some templates that we can start with' etc. Those things I can try to do something about, finding you more time in the day is a bit harder :D
Sorry. Actually, here's a question along those lines: what are you testing - the build process, or the individual packages?
mark
hi,
On 04/12/2011 04:02 PM, m.roth@5-cent.us wrote:
Sorry. Actually, here's a question along those lines: what are you testing
- the build process, or the individual packages?
At the moment there is automation around the process, not nearly as much as I'd like - but its there and it works just about good enough. There is very limited functional testing of the packages on the other hand, so the aim is to start with the easy wins and plumb in as many functional tests as possible. In some cases, this might be down to a per package thing : eg. testing if vsftpd is doing what it should, and failing when it should. And in some cases it might be non package related as such. eg: a php file, can deliver content retrieved from mysql over http. So a single test that spans multiple packages.
- KB
centos-bounces@centos.org wrote:
I was really hoping for you to reply with something along the lines of 'there isnt enough info about the test process' or 'are there some templates that we can start with' etc. Those things I can try to do something about, finding you more time in the day is a bit harder :D
I think we all need an extra week in every day. Or, is that an extra day in every week? Naw, I got it right the first time.
If compile/test servers are an issue, can we do for CentOS what we do for distributed Prime number/SETI computation serving?
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On 04/12/2011 04:08 PM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote: If compile/test servers are an issue, can we do for CentOS what we do for distributed Prime number/SETI computation serving?
Not as far as I know, ensuring environ sanity across something of this nature would be a massive issue. Not easy to solve, unless the environ as a whole is shipped out.
- KB
Karanbir Singh wrote:
On 04/12/2011 04:08 PM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote: If compile/test servers are an issue, can we do for CentOS what we do for distributed Prime number/SETI computation serving?
Not as far as I know, ensuring environ sanity across something of this nature would be a massive issue. Not easy to solve, unless the environ as a whole is shipped out.
Actually, that is what's needed, perhaps: a repeatable environment, not each one custom built.
mark
On 04/12/2011 04:58 PM, m.roth@5-cent.us wrote:
Not as far as I know, ensuring environ sanity across something of this nature would be a massive issue. Not easy to solve, unless the environ as a whole is shipped out.
Actually, that is what's needed, perhaps: a repeatable environment, not each one custom built.
mock does that for buildtime environments; an automated suite can do that easily for test-time environments.
- KB
On 4/12/2011 10:55 AM, Karanbir Singh wrote:
If compile/test servers are an issue, can we do for CentOS what we do for distributed Prime number/SETI computation serving?
Not as far as I know, ensuring environ sanity across something of this nature would be a massive issue. Not easy to solve, unless the environ as a whole is shipped out.
If the process can be scripted into repeatable builds, all you really need is to return the info needed to repeat the one correct build on sanitized equipment, discarding the actual artifacts built elsewhere.
But Johnny's postings seem pretty insistent on never releasing the actual scripts in a form that can be used elsewhere or by anyone outside the project, so maybe a more productive approach would be some way of coordinating contributions toward purchasing virtual server time in some cloud where your secret scripts could assemble build components from undisclosed places but still do a lot of operations in parallel. That could have a lower bar than donating whole servers and perhaps it could be done without the project itself having to handle any money. Personally, I'd rather run things on my own machines, but so far I don't see any hope of that happening in a productive way.
On 04/12/2011 06:02 PM, Les Mikesell wrote:
On 4/12/2011 10:55 AM, Karanbir Singh wrote:
If compile/test servers are an issue, can we do for CentOS what we do for distributed Prime number/SETI computation serving?
Not as far as I know, ensuring environ sanity across something of this nature would be a massive issue. Not easy to solve, unless the environ as a whole is shipped out.
If the process can be scripted into repeatable builds, all you really need is to return the info needed to repeat the one correct build on sanitized equipment, discarding the actual artifacts built elsewhere.
were not talking about build time environs here.
- KB
On 4/12/2011 12:04 PM, Karanbir Singh wrote:
If compile/test servers are an issue, can we do for CentOS what we do for distributed Prime number/SETI computation serving?
Not as far as I know, ensuring environ sanity across something of this nature would be a massive issue. Not easy to solve, unless the environ as a whole is shipped out.
If the process can be scripted into repeatable builds, all you really need is to return the info needed to repeat the one correct build on sanitized equipment, discarding the actual artifacts built elsewhere.
were not talking about build time environs here.
I don't understand. That has been mentioned as the slow/hard part of the process. What is it that really takes months if not that?
On 04/12/2011 06:14 PM, Les Mikesell wrote:
I don't understand. That has been mentioned as the slow/hard part of the process. What is it that really takes months if not that?
you did read my reply to this question of yours in a different part of the thread right ?
- KB
On 4/12/2011 12:21 PM, Karanbir Singh wrote:
On 04/12/2011 06:14 PM, Les Mikesell wrote:
I don't understand. That has been mentioned as the slow/hard part of the process. What is it that really takes months if not that?
you did read my reply to this question of yours in a different part of the thread right ?
I didn't see anything that meshed with the idea of not changing anything but the build environment between builds that fail QA and ones that pass. Wouldn't building a bunch of stuff in parallel and testing at the same time be a reasonable approach to reducing the time to find the right combination?
On Tue, 12 Apr 2011, Les Mikesell wrote:
But Johnny's postings seem pretty insistent on never releasing the actual scripts in a form that can be used elsewhere or by anyone outside the project, so maybe a more productive approach would be some way of
oh horse puckey, troll -- it is just 'shoulder to the wheel, nose to the grindstone' repetitive work, some of which can be automated with minimal scripting [I have scripts that 'read' buildlogs for perl modules, and for R packages, that 'tell' me what to solve next, for example; most people setting up automated builders use (at first) a grep for 'is needed by' to identify what needs to populate a build chroot for a given target package]
Many of the tools one uses are simple scripts that are 'throwaways' written to investigate something that looks like it may be 'sketchy' Upstream's Fedora project has a partial set in its 'koji' project, but 'Release Engineering' still needs to 'look in' and tweak a build sometimes. 'Solving' circular dependencies is another issue where a couple of 'manual builds' are needed to solve missing BR's -- I mentioned 'valgrind-devel' and 'openpmi-devel' a while ago in the upstream's '6' SRPMS ... there are others and always have been, and always will be (probably) because APIs change over time, and packages get renamed and re-organized
off the top of my head, here is the meta-code
1) acquire a pile of SRPMS; set up lots of drive space, and a secure location for one or more machines in a builder farm
2) optionally sort into a build sequence based on BuildReq's, or just look at an install tset (doing the reverse lookup from package to parent SRPM) of a desired end install state
The '2500 possible paths' complaint earlier in the week makes it clear that the complainer had simply not gotten this far
3) do an initial build pass to see if self-hosting can be attained [it won't in the case of a new major release; it may in the case of updates]; this should be done in clean chroots for each package, whether via mock, or other mechanisms
The initial chroot package list in the chroot is almost irrelevant, as 'Nico' kept whining about, because it will become clear during the build from the buildlogs, if one is reverse-engineering the build environment of another, what they 'assumed' would be present from build failure messages and the BuildRequirements. This environment may not be static, because BR's shift around as packages are re-organized from other archives
4) supplement the initial batch of SRPMs with 'bootstrap' SRPMs / binary archive from 'nearby' versions of CentOS, Fedora, or local packaging
5) attain an initial closure on the rebuild; then 'prove' that it is 'self-hosting' by rebuilding it all again in a second pass with the binary fruit from an earlier pass [this step should be optionally repeatable over and over again at any later step, and it is a problem if it is not]
6) fork, tine a: if replicating another's archive, continue with the rest of the SRPMs in the set until all are built; if building a local custom distribution, add a 'local packagings' SRPM archive, back at step 1
7) fork, tine b: examine each package, possibly looking at prior efforts (ie, prior needs for patches) to apply trademark elidement, and branding changes; re-submit into the buildsystem with patches; if building for local use only, this step can be as formal or as casual as one desires
8) continue using 'diff's' on package contents between a 'master' and a 'candidate' with an eye to 'binary compatability' differences [output from 'ldd' is important here], decide if they are material, and identify 'why' it varies; as needed, re-submit into the buildsystem with patches, or changes to the packages comprising the build environment or the 'options' passed in as discerned from reading the 'spec' file conditionals
9) barrier synchronization point of the fork tines: when all builds complete, and all patches are built to one's satisfaction, attend to 'installer' [anaconda] patches, and build ISOs
Fixing anaconda up will usually necessitate additional rounds of builds, because the installer is a continuously moving target. Later build rounds are already using prior round packages for chroot building, so closure should not be an issue
10) attend to securely signing the packages -- air-gaps are nice
[11) KB has mentioned automated testing --- it would drop in here, once installable images are available in the case of a new major release; signing, and testing can move earlier in the process for minor release updates]
12) stage the packages and images to the master archive, and to a mirroring master; manage the release announcements, and 'flip the bit', etc
-- Russ herrold
On 4/12/2011 12:51 PM, R P Herrold wrote:
off the top of my head, here is the meta-code
Would you really repeat those steps by hand if someone gave you a new server to add to what you use? Maybe things are worse than I'd guessed.
On Tue, 12 Apr 2011, Les Mikesell wrote:
On 4/12/2011 12:51 PM, R P Herrold wrote:
off the top of my head, here is the meta-code
Would you really repeat those steps by hand if someone gave you a new server to add to what you use? Maybe things are worse than I'd guessed.
You did not read the commentary ... much may be automated [I've blogged about using lftp to mirror a pile of SRPMs as in step 1; published the perl build reading scripts, and the chroot building process as long ago as cAos days, and so forth], but much of full distribution building is problem solving skills and 'one off tasks' that vary over time as the SRPMs dictate when one goes to build them
Ther is no substitute for doing it to learn how to do it. Speculation from bystanders is not all that helpful; the process is understood, so 'helpful' attempts on streamlining process are not helpful. If one wants to help, set up a local laboratory and learn how to build --- but this is quite hard, and so we've recommend bug triage, test writing and other 'reputational' building paths into the project ... but people would rather troll and trawl in mailing lists. I've referred to 'do-ers' and 'talkers' over the years. Eventually the 'do-ers' ignroe 'talkers'
Writing the flowchart got me to thinking about the desire someone had for adding 'metering, such as a twitter driven 'progress bar' --- It will not happen, because one does not know what measure of builds represent 'full scale' complete, until one is complete, which is too late for a progress bar [unless one is 'solving' the rebuild yet again, a useless act]. Sadly the effort is not even linear so that one might extrapolate a 'close rate' because the 'hard stuff' tends to pile up and be solved last
-- Russ herrold
On 4/12/2011 1:33 PM, R P Herrold wrote:
off the top of my head, here is the meta-code
Would you really repeat those steps by hand if someone gave you a new server to add to what you use? Maybe things are worse than I'd guessed.
You did not read the commentary ...
I did - and didn't see anything how my mistakes in emulating your process might keep you from repeating them or vice versa. And you didn't answer my question.
Ther is no substitute for doing it to learn how to do it. Speculation from bystanders is not all that helpful; the process is understood, so 'helpful' attempts on streamlining process are not helpful.
'Streamlining' isn't quite the point. Making and identifying as many mistakes as possible concurrently without repeating work would be a closer description.
If one wants to help, set up a local laboratory and learn how to build --- but this is quite hard,
So back to what you would actually do with another server to throw in the mix. Would you really repeat that work by hand and duplicate all the wrong builds the other servers have done? And if that is not what you would do, why do you insist that everyone else should do it that way?
Writing the flowchart got me to thinking about the desire someone had for adding 'metering, such as a twitter driven 'progress bar' --- It will not happen, because one does not know what measure of builds represent 'full scale' complete, until one is complete, which is too late for a progress bar [unless one is 'solving' the rebuild yet again, a useless act]. Sadly the effort is not even linear so that one might extrapolate a 'close rate' because the 'hard stuff' tends to pile up and be solved last
How about something that shows what task(s) are blocking progress and how much time they eventually consumed with/without other things happening in parallel? That seems more useful to know than guessing about completion. If it is clear that those test scripts you suggest writing will clear months off the wait, people will be much more motivated to tackle them.
Hi Ned,
On 04/11/2011 10:02 PM, Ned Slider wrote:
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
He's not completely wrong; getting dep ordering with missing intermediaries isn't trivial. If upstream takes upto 50 days from release to drop a srpm, we need to consider implications in both directions right ? and at that point ( it has happened ) we might be looking at rebuilds from 50+X days. Where X might even be 20 - 45 days itself. in 5.3's release time we had to traceback to a fastrack built package from 5.1's days.
- KB
On 12/04/11 17:04, Karanbir Singh wrote:
Hi Ned,
On 04/11/2011 10:02 PM, Ned Slider wrote:
each release is more complex than the last. The web of dependency grows, so the reverse-engineering takes longer and longer.
This is just complete nonsense. You clearly have no understanding of the processes involved in rebuilding RHEL. CentOS doesn't reverse-engineer anything, they simply rebuild the upstream sources. It's not rocket science.
He's not completely wrong; getting dep ordering with missing intermediaries isn't trivial. If upstream takes upto 50 days from release to drop a srpm, we need to consider implications in both directions right ? and at that point ( it has happened ) we might be looking at rebuilds from 50+X days. Where X might even be 20 - 45 days
Fair point :-)
itself. in 5.3's release time we had to traceback to a fastrack built package from 5.1's days.
Well, I've said it before - if you built the FasTrack packages as they are released upstream then you wouldn't need to track back months trying to build it out of sequence. The same thing happened this time around too with a kde update I believe. Even if you don't release those FasTrack packages, if you at least build them during the life of 5.6 for example, when 5.7 gets released you'll have 10, 20, 50 or however many packages pre-built, tested and ready to ship and not have to maybe go back in time recreating build roots to build them. Generally it's just so much easier to build stuff in sequence as it's released by upstream rather than trying to rebuild it out of sequence 6 months after the event.
On 04/10/2011 07:15 PM, Rui Miguel Silva Seabra wrote:
You just gave me examples of more "person Foo dropping by Bar"... I'm not sure how that can shorten the gap between upstream and CentOS releases. It seems more in the way of giving user support.
No, re-read what I said. Ownership in the distro is quite a different ballgame from userend support.
The main support *I* need is timely updates and releases.
The aim is to solve problems on a much larger scale, like the entire userbase. One of the key areas is this - and its a shared thing, but it an issue that needs to be solved by doing the right thing and not just something random.
It's obvious there is a man-power issue. It is obvious to me you're in denial :)
you are wrong on both counts, and unless you are ready to get your thinking hat on and use it, its going to be quite hard to figure things out.
- KB
Karanbir Singh wrote on 04/11/2011 12:20 PM: ...
No, re-read what I said. Ownership in the distro is quite a different ballgame from userend support.
Yes, but it seems to be rather closely held.
The main support *I* need is timely updates and releases.
The aim is to solve problems on a much larger scale, like the entire userbase. One of the key areas is this - and its a shared thing, but it an issue that needs to be solved by doing the right thing and not just something random.
There has been extensive support and agitation among the user-base for more timely updates, particularly for security issues. It seems obvious to me that there is considerable room for improvement.
you are wrong on both counts, and unless you are ready to get your thinking hat on and use it, its going to be quite hard to figure things out.
A lot of people have been thinking rather hard about how CentOS can be improved. Please share your thoughts on what needs to be done, and carry through with a plan of action to accomplish it. Nobody is in a better position to do that than you are.
Phil
On 04/12/2011 01:21 AM, Phil Schaffner wrote:
Karanbir Singh wrote on 04/11/2011 12:20 PM: ...
No, re-read what I said. Ownership in the distro is quite a different ballgame from userend support.
Yes, but it seems to be rather closely held.
The option I was talking about was how that can change - people can step up to take ownership of various components in the distro - was that not clear in my email ? I can try and put this into a more verbose text and explain how something like this might work.
There has been extensive support and agitation among the user-base for more timely updates, particularly for security issues. It seems obvious to me that there is considerable room for improvement.
sure, I dont deny that. But when there are options available for people to help with that, noone seems really keen on getting on board. The few who do are actively discouraged from doing what they can.
A lot of people have been thinking rather hard about how CentOS can be improved. Please share your thoughts on what needs to be done, and carry through with a plan of action to accomplish it. Nobody is in a better position to do that than you are.
Sure, I am happy to do that.
- KB
On 04/12/2011 02:01 PM, Karanbir Singh wrote:
On 04/12/2011 01:21 AM, Phil Schaffner wrote:
Karanbir Singh wrote on 04/11/2011 12:20 PM: ...
No, re-read what I said. Ownership in the distro is quite a different ballgame from userend support.
Yes, but it seems to be rather closely held.
The option I was talking about was how that can change - people can step up to take ownership of various components in the distro - was that not clear in my email ? I can try and put this into a more verbose text and explain how something like this might work.
I think you are avoiding the real issue here, again and again. It's not about ownership. It's not about taking ownership. It's about making the process open. A simple wiki page describing what you are doing now, and a ftp URL with files to download would do. Then, everybody can contribute. There can be 100 people trying to fix a bug, rather than 1 person who takes "ownership" .. what's this ownership nonsense?
There has been extensive support and agitation among the user-base for more timely updates, particularly for security issues. It seems obvious to me that there is considerable room for improvement.
sure, I dont deny that. But when there are options available for people to help with that, noone seems really keen on getting on board. The few who do are actively discouraged from doing what they can.
A lot of people have been thinking rather hard about how CentOS can be improved. Please share your thoughts on what needs to be done, and carry through with a plan of action to accomplish it. Nobody is in a better position to do that than you are.
Sure, I am happy to do that.
- KB
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 04/12/2011 12:31 PM, Radu Gheorghiu wrote:
I think you are avoiding the real issue here, again and again. It's not about ownership. It's not about taking ownership. It's about making the process open. A simple wiki page describing what you are doing now, and a ftp URL with files to download would do.
There are pages in the wiki that already describe what we are doing right now.
Then, everybody can contribute. There can be 100 people trying to fix a bug, rather than 1 person who takes "ownership" .. what's this ownership nonsense?
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
- Kb
On 04/12/2011 02:37 PM, Karanbir Singh wrote:
On 04/12/2011 12:31 PM, Radu Gheorghiu wrote:
I think you are avoiding the real issue here, again and again. It's not about ownership. It's not about taking ownership. It's about making the process open. A simple wiki page describing what you are doing now, and a ftp URL with files to download would do.
There are pages in the wiki that already describe what we are doing right now.
I think you already stated that the pages about rebuilding are outdated.
Then, everybody can contribute. There can be 100 people trying to fix a bug, rather than 1 person who takes "ownership" .. what's this ownership nonsense?
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
Useless unless I can replicate your build system. We must work on the same thing, not on separate things.
- Kb
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 04/12/2011 12:48 PM, Radu Gheorghiu wrote:
There are pages in the wiki that already describe what we are doing right now.
I think you already stated that the pages about rebuilding are outdated.
Thats not what was said : we might not be using the exact same scripts is more along the lines of what was said. But yes, there is some level of scope to gather the info from various places into a single place. Quite a lot things are scattered around and need people to make an effort. Having a single starting page, as it were, would help.
A couple of days back, someone offered to start that process off. I will help alongside as much as I can.
Useless unless I can replicate your build system. We must work on the same thing, not on separate things.
Ok, so that's a much more tangible question! Replicating the build system isn't hard. Its almost a case of doing a for loop with mock and looking at results of what that turns out. This question has been answered at-least a few dozen times in recent past. Look at mock, look at yum and make sure you understand spec files.
But remember, that building packages is only a small part of what we are doing.
- KB
On 04/12/2011 06:58 AM, Karanbir Singh wrote:
On 04/12/2011 12:48 PM, Radu Gheorghiu wrote:
There are pages in the wiki that already describe what we are doing right now.
I think you already stated that the pages about rebuilding are outdated.
Thats not what was said : we might not be using the exact same scripts is more along the lines of what was said. But yes, there is some level of scope to gather the info from various places into a single place. Quite a lot things are scattered around and need people to make an effort. Having a single starting page, as it were, would help.
A couple of days back, someone offered to start that process off. I will help alongside as much as I can.
Useless unless I can replicate your build system. We must work on the same thing, not on separate things.
Ok, so that's a much more tangible question! Replicating the build system isn't hard. Its almost a case of doing a for loop with mock and looking at results of what that turns out. This question has been answered at-least a few dozen times in recent past. Look at mock, look at yum and make sure you understand spec files.
But remember, that building packages is only a small part of what we are doing.
I have posted again and again example scripts that we use.
We use mock to build packages ... specifically, we use the mock released in CentOS Extras for CentOS 5 to build packages.
Some people keep asking for our mock config files. I gave examples of those (centos-5-i386-os-ft-extrasStaged.cfg, centos-5-x86_64-os-ft-extrasStaged.cfg). They are not rocket science. If you point to the [base] and [updates] directory for CentOS for the thing you are trying to build, then you have it. If you are building extras, add in [extras]. If you are building CentOSPlus, add in [centosplus]. If I provide you the exact file, it does not help. It points to names we do not want to give out because we do not want our internal names to published for security reasons, but we quite simply use [os] and [updates] to build the main OS, and other repos as necessary to build [extras] or [centosplus]. Point to ONLY the CentOS repos, we do not pull in any other items for our builds. If we need a package (in extras or centosplus) then we add it.
We do staged builds (that means when we get a good build, it goes into the build tree). I gave examples of scripts that do that (cp_extrasStaged_live).
We test the RPMs against upstream RPMs. I gave a script of that (tmverifyrpms).
When we have a tree of RPMS, we build the "distro tree". I gave an example of that too. (build.sh.txt).
All of the files I talked about in this post are either here:
http://people.centos.org/hughesjr/buildsystem/
or here:
http://mirror.centos.org/centos-4/4/build/distro/
Also included are actual buildscripts for an ExtrasStaged repo (buildpackages_mock_c5_extrasStaged_i386, buildpackages_mock_c5_extrasStaged_x86_64) and a script that "generates" the order to build packages based on their previous build date generaterpmlist().
All of this is also linked from here:
http://wiki.centos.org/FAQ/General/RebuildReleaseProcess
The point here is that we are not going to share access to our actual build system and we are not going to give you our actual build scripts off that system as they use names that we do not want to publish and contain files that we can not allow people to have access to. But these example scripts give someone who wants to build their own items the starting point that they need to do that.
Thanks, Johnny Hughes
On 04/12/2011 02:37 PM, Karanbir Singh wrote:
On 04/12/2011 12:31 PM, Radu Gheorghiu wrote:
I think you are avoiding the real issue here, again and again. It's not about ownership. It's not about taking ownership. It's about making the process open. A simple wiki page describing what you are doing now, and a ftp URL with files to download would do.
There are pages in the wiki that already describe what we are doing right now.
Then, everybody can contribute. There can be 100 people trying to fix a bug, rather than 1 person who takes "ownership" .. what's this ownership nonsense?
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
Why would anyone care to share knowledge, when apparently you don't care to do so?
Maybe you are just new to the concept of open communities.
- Kb
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 04/12/2011 12:55 PM, Radu Gheorghiu wrote:
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
Why would anyone care to share knowledge, when apparently you don't care to do so?
Maybe you are just new to the concept of open communities.
now you are just trolling, and insulting the dozens of people who already help with these things :/
Its such a shame that people are not only being negative about change, but also actively discouraging those who make the efforts to help.
- KB
On 4/12/11 6:37 AM, Karanbir Singh wrote:
On 04/12/2011 12:31 PM, Radu Gheorghiu wrote:
I think you are avoiding the real issue here, again and again. It's not about ownership. It's not about taking ownership. It's about making the process open. A simple wiki page describing what you are doing now, and a ftp URL with files to download would do.
There are pages in the wiki that already describe what we are doing right now.
Really? Where do I look to see what has been tried with packages that are currently failing QA or not building yet? Or even what are the current time-consuming problems that haven't been solved yet?
Then, everybody can contribute. There can be 100 people trying to fix a bug, rather than 1 person who takes "ownership" .. what's this ownership nonsense?
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
Wouldn't thinking things through have to result in distributing the time consuming work instead of making it wait for any single owner?
On 04/12/2011 02:06 PM, Les Mikesell wrote:
There are pages in the wiki that already describe what we are doing right now.
Really? Where do I look to see what has been tried with packages that are currently failing QA or not building yet? Or even what are the current time-consuming problems that haven't been solved yet?
The process is not the product.
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
Wouldn't thinking things through have to result in distributing the time consuming work instead of making it wait for any single owner?
Exactly, which is where the idea of 'ownership' comes through.
- KB
On Tuesday, April 12, 2011 10:07 PM, Karanbir Singh wrote:
On 04/12/2011 02:06 PM, Les Mikesell wrote:
There are pages in the wiki that already describe what we are doing right now.
Really? Where do I look to see what has been tried with packages that are currently failing QA or not building yet? Or even what are the current time-consuming problems that haven't been solved yet?
The process is not the product.
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
Wouldn't thinking things through have to result in distributing the time consuming work instead of making it wait for any single owner?
Exactly, which is where the idea of 'ownership' comes through.
How are you going to vet the stuff? The QA team will be responsible for that? For all the talk of giving others the exact tools to replicate a Centos distro - just how is the stuff produced by a zillion would be contributors (assuming they don't take off to build their own crap distro) going to be vetted?
On 04/12/2011 03:31 PM, Christopher Chan wrote:
How are you going to vet the stuff? The QA team will be responsible for that? For all the talk of giving others the exact tools to replicate a Centos distro - just how is the stuff produced by a zillion would be contributors (assuming they don't take off to build their own crap distro) going to be vetted?
Yes, the QA team would get to make the final call on release / reject. We would need to put in place a finite and quantifiable set of instructions for the QA team.
Regards,
- KB
On 4/12/2011 9:07 AM, Karanbir Singh wrote:
There are pages in the wiki that already describe what we are doing right now.
Really? Where do I look to see what has been tried with packages that are currently failing QA or not building yet? Or even what are the current time-consuming problems that haven't been solved yet?
The process is not the product.
Exactly, and I don't see anyone complaining about the product - just wondering if some number of months could be shaved off the process.
The bug.centos.org site is open to anyone who might want to get involved and help fix bugs. I'm guessing you are just new to CentOS and dont really know what you are talking about. Try thinking things though for a change.
Wouldn't thinking things through have to result in distributing the time consuming work instead of making it wait for any single owner?
Exactly, which is where the idea of 'ownership' comes through.
So far it isn't clear where the months of process can accumulate. If it is mostly in iterative work on a few packages, how does changing their ownership do anything to speed things up - unless the concept of ownership gives the right to open and distribute the work that is causing the bottleneck in the process?
On 04/12/2011 04:01 PM, Les Mikesell wrote:
The process is not the product.
Exactly, and I don't see anyone complaining about the product - just wondering if some number of months could be shaved off the process.
Fixing the timing of release is something we get from getting the process into the right place. And not the other way around. There seems to be a feeling of 'do whatever' to get packages out faster. And thats where I have an issue with things. Doing the right thing, would mean we get packages in the right state out faster. The 'right state' bit is not really optional, imho.
Exactly, which is where the idea of 'ownership' comes through.
So far it isn't clear where the months of process can accumulate. If it
There are many things, eg. not having the right amount of kit in the same place is a bottleneck. Not being able to run the right sort of tests automatically is another. Upstream not releasing packages in time is yet another. There are plenty of things that are harder to solve. On the other hand, there are things that we can do stuff about : find and promote people who have expertise in specific functionality to help come together and solve the not-enough-eyes issues. And being able to do that within a model that also promotes the persons visibility in the community and therefore have some level of a trust build up in the peer group, is a clear win!
And to be clear, its not about expertise with rpm or packaging as a whole, its expertise in a functional set that is more relevant.
Regards,
- KB
On Tue, Apr 12, 2011 at 11:53 AM, Karanbir Singh mail-lists@karan.org wrote:
On 04/12/2011 04:01 PM, Les Mikesell wrote:
The process is not the product.
Exactly, and I don't see anyone complaining about the product - just wondering if some number of months could be shaved off the process.
Fixing the timing of release is something we get from getting the process into the right place. And not the other way around. There seems to be a feeling of 'do whatever' to get packages out faster. And that's where I have an issue with things. Doing the right thing, would mean we get packages in the right state out faster. The 'right state' bit is not really optional, imho.
This kind of response indicates an almost willful misreading of what pretty much everyone has said on the topic, and I can't believe we are still hearing it.
NO ONE IS SAYING TO PUSH CRAP OUT THE DOOR JUST FOR THE SAKE OF GETTING IT OUT. EVERYONE IS SAYING TO OPEN THE PROCESS SO THEY CAN HELP GET THE HIGH QUALITY STUFF OUT THE DOOR FASTER.
It's completely irresponsible to continue making this argument, so stop it. Please read http://en.wikipedia.org/wiki/Straw_man for a complete explanation of what you are doing here and why it is completely disrespectful against logic to continue using it.
Exactly, which is where the idea of 'ownership' comes through.
So far it isn't clear where the months of process can accumulate. If it
There are many things, eg. not having the right amount of kit in the same place is a bottleneck. Not being able to run the right sort of tests automatically is another. Upstream not releasing packages in time is yet another. There are plenty of things that are harder to solve. On the other hand, there are things that we can do stuff about : find and promote people who have expertise in specific functionality to help come together and solve the not-enough-eyes issues. And being able to do that within a model that also promotes the persons visibility in the community and therefore have some level of a trust build up in the peer group, is a clear win!
And to be clear, its not about expertise with rpm or packaging as a whole, its expertise in a functional set that is more relevant.
Regards,
- KB
This is another area where the project needs to be brought into the 21st century. "find and promote people who have expertise in specific functionality". This is how closed-source corporations run their projects. Open source allows you to tap into the "long tail" of people who might have time to contribute 1 or 2 things, but not become a complete owner of a subsystem. With many people contributing like this, the main project committers would vet and incorporate changes, maintaining the level of trust while reducing their workload. Every open source project in the past 20 years has figured this out; I fail to see why it's so hard for CentOS.
// Brian Mathis
On 04/12/2011 05:19 PM, Brian Mathis wrote:
Fixing the timing of release is something we get from getting the process into the right place. And not the other way around. There seems
NO ONE IS SAYING TO PUSH CRAP OUT THE DOOR JUST FOR THE SAKE OF GETTING IT OUT. EVERYONE IS SAYING TO OPEN THE PROCESS SO THEY CAN HELP GET THE HIGH QUALITY STUFF OUT THE DOOR FASTER.
erm, you seem confused. Because that is sort of the exact point that I was making - get the process right, and if its in the right place we get the free win from faster output.
This is another area where the project needs to be brought into the 21st century. "find and promote people who have expertise in specific functionality". This is how closed-source corporations run their projects. Open source allows you to tap into the "long tail" of
You also seem confused about the idea of the long tail, there are no caps or limits being enforced, as closed source projects do, on the contributions that people make. I'm not proposing that clueless idiots get involved, just that people who do get involved should know what they are doing. And perhaps get enough people involved so that if a few people are not around when needed, there are always enough to pickup on the slack created from that.
people who might have time to contribute 1 or 2 things, but not become a complete owner of a subsystem. With many people contributing like this, the main project committers would vet and incorporate changes, maintaining the level of trust while reducing their workload. Every
Again, either I failed to communicate this or you didnt get it - large part of the plan is to bring this sort of a contributor base into a loop that then feeds into what is the main project committers. It could also mean splitting the QA process into the QA team and Release Team with the core build team taking care of the convert from source to binary process. Also, giving people ownership of something they enjoy doing and allowing them to be productive within that space is'nt something thats either open source or closed source centric - its a nice gesture to recognise people doing the lifting.
Also, if you think that just having something out there that people can randomly drive-by and fix is going to work, you must be either really clueless or just new to open source.
- KB
On 4/12/2011 12:00 PM, Karanbir Singh wrote:
On 04/12/2011 05:19 PM, Brian Mathis wrote:
Fixing the timing of release is something we get from getting the process into the right place. And not the other way around. There seems
NO ONE IS SAYING TO PUSH CRAP OUT THE DOOR JUST FOR THE SAKE OF GETTING IT OUT. EVERYONE IS SAYING TO OPEN THE PROCESS SO THEY CAN HELP GET THE HIGH QUALITY STUFF OUT THE DOOR FASTER.
erm, you seem confused. Because that is sort of the exact point that I was making - get the process right, and if its in the right place we get the free win from faster output.
Yes, we are confused because we don't actually know where the time goes. We are assuming that there is some iterative process that perhaps could be done in parallel, discarding all of the 'wrong' attempts at once instead of waiting until you realize one is wrong to repeat it. Maybe you could estimate the time consumption of the various steps in the process to help us understand. Rounding to the nearest month would be a start...
Also, if you think that just having something out there that people can randomly drive-by and fix is going to work, you must be either really clueless or just new to open source.
I thought that other than removing trademark info, it has been stated that you don't change anything but the build environment between builds/tests. That seems very different from programmers trying to improve code. But, very much like improving code, you can't do much to improve speed without profiling the existing process to see where the time is consumed.
On 04/12/2011 08:00 PM, Karanbir Singh wrote:
On 04/12/2011 05:19 PM, Brian Mathis wrote:
Fixing the timing of release is something we get from getting the process into the right place. And not the other way around. There seems
NO ONE IS SAYING TO PUSH CRAP OUT THE DOOR JUST FOR THE SAKE OF GETTING IT OUT. EVERYONE IS SAYING TO OPEN THE PROCESS SO THEY CAN HELP GET THE HIGH QUALITY STUFF OUT THE DOOR FASTER.
erm, you seem confused. Because that is sort of the exact point that I was making - get the process right, and if its in the right place we get the free win from faster output.
This is another area where the project needs to be brought into the 21st century. "find and promote people who have expertise in specific functionality". This is how closed-source corporations run their projects. Open source allows you to tap into the "long tail" of
You also seem confused about the idea of the long tail, there are no caps or limits being enforced, as closed source projects do, on the contributions that people make. I'm not proposing that clueless idiots get involved, just that people who do get involved should know what they are doing. And perhaps get enough people involved so that if a few people are not around when needed, there are always enough to pickup on the slack created from that.
people who might have time to contribute 1 or 2 things, but not become a complete owner of a subsystem. With many people contributing like this, the main project committers would vet and incorporate changes, maintaining the level of trust while reducing their workload. Every
Again, either I failed to communicate this or you didnt get it - large part of the plan is to bring this sort of a contributor base into a loop that then feeds into what is the main project committers. It could also mean splitting the QA process into the QA team and Release Team with the core build team taking care of the convert from source to binary process. Also, giving people ownership of something they enjoy doing and allowing them to be productive within that space is'nt something thats either open source or closed source centric - its a nice gesture to recognise people doing the lifting.
Also, if you think that just having something out there that people can randomly drive-by and fix is going to work, you must be either really clueless or just new to open source.
1. a LOT of people understand exactly what Brian understood as well.
2. Why do you always have to end with "you must be clueless", "you must be new to CentOS", "you must be new to Open Source". How can you tell? You can tell all this just by reading one email?
- KB
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 04/12/2011 07:53 PM, Radu Gheorghiu wrote:
- Why do you always have to end with "you must be clueless", "you must
be new to CentOS", "you must be new to Open Source". How can you tell? You can tell all this just by reading one email?
thats a good question, I was asking myself the same thing. End of the day, it comes down to the fact that I feel we go over the same thing again and again all the time. And when people offer to help, I try and create a mechanism for them to do so, but there is little or no real feedback on that, and traction is even harder to get.
suspect this is, at least in some part, down to the fact that we don't have a wiki or a web page that could perhaps accumulate some/much of whats been said already and point people at that - so if they are new to the process, they have a single resource to look at and perhaps get 'upto speed' as it were.
- KB
Karanbir Singh wrote on 04/12/2011 04:07 PM:
suspect this is, at least in some part, down to the fact that we don't have a wiki or a web page that could perhaps accumulate some/much of whats been said already and point people at that - so if they are new to the process, they have a single resource to look at and perhaps get 'upto speed' as it were.
That would help a lot.
Phil
On Tue, Apr 12, 2011 at 4:07 PM, Karanbir Singh mail-lists@karan.org wrote:
On 04/12/2011 07:53 PM, Radu Gheorghiu wrote:
- Why do you always have to end with "you must be clueless", "you must
be new to CentOS", "you must be new to Open Source". How can you tell? You can tell all this just by reading one email?
thats a good question, I was asking myself the same thing. End of the day, it comes down to the fact that I feel we go over the same thing again and again all the time. And when people offer to help, I try and create a mechanism for them to do so, but there is little or no real feedback on that, and traction is even harder to get.
We go over the same things because the issues are clear and the suggestions seem to fall on deaf ears over and over again. Most of the responses rely on logical fallacies or things that can obviously be resolved with just an ounce of thought, creativity, or discussion.
As for offers of help, I don't see any of the recent offers as offers of *real* help to get people involved. Real steps to open things are: - bug tracker with up to date status of the R6 packages and all outstanding issues - git repo with the scripts being used to do things and the patch files required to be applied to SRPMS - web pages with procedures on how to do things using those scripts and anything else that is not/cannot be scripted
All of these need to be done by the dev team first. Maybe someone can setup the git repo and have it prepped for the devs to use. Johnny mentioned some internal names that can't be released for security reasons. This seems dubious, but still can be handled quite easily on the "trusted" final build servers.
suspect this is, at least in some part, down to the fact that we don't have a wiki or a web page that could perhaps accumulate some/much of whats been said already and point people at that - so if they are new to the process, they have a single resource to look at and perhaps get 'upto speed' as it were.
- KB
"in some part"...?! I would say that is the ENTIRE part, as everyone except for the chosen few is "new to the process". I have seen a few postings from Devs saying how they helped some other people to build packages, etc... but how? From the tone of the messages it seems like it was either via IRC or personal email, which effectively counts for zero in this context as we are talking about things that take place in public. Those things need to go into the wiki, with updated pages. Not on blog posts, twitter, or email archives.
// Brian Mathis
On Tue, 12 Apr 2011, Brian Mathis wrote:
packages, etc... but how? From the tone of the messages it seems like it was either via IRC or personal email, which effectively counts for zero in this context as we are talking about things that take place in public. Those things need to go into the wiki, with updated pages.
Not on blog posts, twitter, or email archives.
You can beat a cow, but it rarely gives more milk
I've written repeated private email to reply to civil inquiry to help people through build problems. I would have blogged about it, but then, if a person thought enough to write to me, it seems I should give them a personal reply
The outline I posted earlier today will end up at github, and I'll decorate it with scripts; I'll also blog about it -- but you know, as no-one will pay for that content, it will happen to scratch my itches and on my timeline
Don't you find it at least a ironic via email to carp that an email archive is not where answers should reside
with kind regards,
-- Russ herrold
On Tue, Apr 12, 2011 at 6:39 PM, R P Herrold herrold@owlriver.com wrote:
On Tue, 12 Apr 2011, Brian Mathis wrote:
packages, etc... but how? From the tone of the messages it seems like it was either via IRC or personal email, which effectively counts for zero in this context as we are talking about things that take place in public. Those things need to go into the wiki, with updated pages.
Not on blog posts, twitter, or email archives.
You can beat a cow, but it rarely gives more milk
I've written repeated private email to reply to civil inquiry to help people through build problems. I would have blogged about it, but then, if a person thought enough to write to me, it seems I should give them a personal reply
Sure, give them a personal reply, but then also update the public documentation with the same information so you can save yourself answering the same question again later.
The outline I posted earlier today will end up at github, and I'll decorate it with scripts; I'll also blog about it -- but you know, as no-one will pay for that content, it will happen to scratch my itches and on my timeline
Don't you find it at least a ironic via email to carp that an email archive is not where answers should reside
No, it's not at all ironic because I understand that different types of communications occur in different contexts. Email is a medium used for discussion, while web pages and git are mediums used for documentation and code management. Thanks for handing me a ready-made example that upholds my statement "Most of the responses rely on logical fallacies or things that can obviously be resolved with just an ounce of thought, creativity, or discussion."
with kind regards,
-- Russ herrold
// Brian Mathis
On Tue, 12 Apr 2011, Karanbir Singh wrote:
Also, if you think that just having something out there that people can randomly drive-by and fix is going to work, you must be either really clueless or just new to open source.
In Open Source people scratch personal itches. That itch may as well be that CentOS 5.6 is being blocked by a few issues, holding back also a set of security updates.
Do you really think nobody wants to become the hero of the day by fixing those blocking issues, speeding up a release ?
But your prime example of people not interesting to contribute, is that there was low feedback of your testing framework proposal (of which no information is in the Wiki). Well, ever thought that this particular item was not itching anyone ? Because maybe the bigger picture is missing ?
On 04/12/11 4:31 AM, Radu Gheorghiu wrote:
There can be 100 people trying to fix a bug, rather than 1 person who takes "ownership"
100 cooks can't boil a pot any faster.... wait, no, thats 'too many cooks spoil the soup.
ok, how about... 100 woman can't make a baby any faster.
anyways. enough already, this subject has been beaten to death.
On 4/12/2011 1:59 PM, John R Pierce wrote:
On 04/12/11 4:31 AM, Radu Gheorghiu wrote:
There can be 100 people trying to fix a bug, rather than 1 person who takes "ownership"
100 cooks can't boil a pot any faster.... wait, no, thats 'too many cooks spoil the soup.
ok, how about... 100 woman can't make a baby any faster.
Or thousands of people can't make the Linux kernel better or faster than Linus could have done by himself?
On 04/12/11 12:10 PM, Les Mikesell wrote:
Or thousands of people can't make the Linux kernel better or faster than Linus could have done by himself?
imho, the linux kernel is a freekin mess of conflicted crap, ever changing. 50 different IO schedulers yet none of them can get write barriers sorted out correctly. driver ABIs that change with every build. etc etc. its amazing it works as well as it does.
On 4/12/2011 2:23 PM, John R Pierce wrote:
On 04/12/11 12:10 PM, Les Mikesell wrote:
Or thousands of people can't make the Linux kernel better or faster than Linus could have done by himself?
imho, the linux kernel is a freekin mess of conflicted crap, ever changing. 50 different IO schedulers yet none of them can get write barriers sorted out correctly. driver ABIs that change with every build. etc etc.
But you can't blame that last decision on the crowdsourcing... In fact, getting some protection from it is one of the reasons we are on an 'enterprise' disto list instead of using the authoritative version of the day.
-
Akemi Yagi -
Alain Péan -
aurfalien＠gmail.com -
Brian Mathis -
Brunner, Brian T. -
Christopher Chan -
Cody Robertson -
Craig White -
Dag Wieers -
David Brian Chait -
Digimer -
Drew -
Emmanuel Noobadmin -
Farkas Levente -
Gilbert Sebenste -
Hendrik -
John R Pierce -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Keith Keller -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Mister IT Guru -
Ned Slider -
Peter A -
Phil Schaffner -
R P Herrold -
Radu Gheorghiu -
Rudi Ahlers -
Rui Miguel Silva Seabra -
Scott Silva -
Tamada Wilder -
Tru Huynh