On Tue, Apr 12, 2011 at 11:53 AM, Karanbir Singh <mail-lists at 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