On Wed, Jan 09, 2008 at 07:19:48PM -0500, Adam Jackson wrote: > > Partly that's just how software _works_. You don't ever ship anything > 100% perfect because it's not an achievable goal. But, partly because > it's just observed reality of how the project is staffed. For many of > the features that people consider vitally important we have at best a > small team of contributors. In that case let them do what they think best. > > Isn't the fedora contributors time used like they want to? > > Oh man. If only. Not in that sense, of course. What I am saying is that if somebody wants to work on something even if it is not where the main strand of fedora, even if it leads to having parallel stuff he should not be deterred. > > If there are three parts, and three interactions but dozens of contributors > > willing to fix them where is the issue? > > We don't _have_ dozens of contributors willing to fix them. I can count > the number of unsolicited X patches I've received from random Fedora > people on one hand. Statistically speaking, zero bug reports come with > patches attached. Again, this is just a reality of software. Most > users are not developers. There is no reason to ever expect this to > change. I can't see the connection with patches. > Go read No Silver Bullet again. Software is hard. Complexity is the > essence of the problem. Complexity is a handshake problem, n(n-1)/2. That's just untrue. Not everything interacts in complex ways with everything. Also adding some complexity may some time reduce development costs when some comparisons become possible when similar software coexist. > You can not just throw manpower at the problem, because the > communication problem between the developers is also a handshake > problem. The only solution is radical simplicity. It isn't that simple. Do we also want community handle on fedora or not? I really like redhat leadership and innovations, but I don't want to be a puppet either. If people from the community with specific needs and wants are to be accepted in fedora, it means that radical simplicity is not possible. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
