On Tuesday 15 July 2003 13:39, Stuart Herbert wrote: > > I hope you realise that your desires are conflicting. more > > ebuilds leads to > > more unmaintained ebuilds. More QA needs more time. > > Rubbish. Totally utter rubbish. > > The right levels of QA *save* time, because things are done > as-right-as-they-can-be first time. Instead of time going into bug fixing > and constantly re-doing what has been done, the time instead goes into > moving forward, and doing new things. *Too much* QA just bogs the whole > thing down, and makes it impossible to get anything done in a timely > fashion. The two are very different. It is not rubbish, but there are ways that can try to make the conflicts as small as possible, but if you want to have an ebuild an hour after a package was released (which I also want) there is not much time to do QA, so things will break every now and then. If you don't want things to break at all, even in an unstable tree, use debian. Gentoo needs to find a middle road. > I can think of one way to make dealing with unmaintained ebuilds easy > enough. First of all, put in place a mechanism to remove the guesswork > about whether a particular package is maintained or not. Then, create a > pool of developers who will handle new ebuilds for these packages. > Finally, make a site where people can come and tell you when an ebuild is > out of date (or just use Bugzilla). That way, packages that no-one > particularly wants to maintain are driven by 'customer demand' (for lack of > a better phrase). Final step is to setup some 'tinderbox' machines, where > the unmaintained ebuilds are automatically built. When they finally break, > a bug could be automatically raised on Bugzilla for someone in the pool to > look at it. > Most breakage is not in compilation unfortunately, but in odd combinations of packages creating broken results. > There's also another way. Encourage more opensource projects to maintain > their own ebuilds. Many of them maintain SPEC files for building RedHat > RPMs. So why not try and distribute the work more widely too? > > What are *your* proposals for addressing this? I'd like to hear them. Well, what I'm doing to address some of these things is the herds project. It aims to find maintainers for all ebuilds. That way we can identify lost packages, and make sure they are maintained or abandoned. > > > We are trying to address these problems in a way that is > > satisfactory for everyone. > > Are you speaking for yourself, or for TheManagement(tm)? I'm trying to speak for the gentoo project, of which the management is a part > > > Be assured that these issues are being addressed. This > > requires time though, as restructuring is necessary for it to happen. > > You talk like we should run along and play, and not bother BigPeople(tm) > like yourself. You'll have to excuse me if I don't like that ;-) It's > exactly this sort of *presentation* (I use the work presentation because > you've included nothing of substance in your reply!) that makes people call > for more openness in the community. Interesting. > I don't consider myself to be a BigPerson(tm), and I don't mind to explain things, or even to change my opinion because of someone elses arguments. I do however don't want to bring up false hopes by comming out with proposals that need revision and are not ready yet. I can tell you however that we are busy finding a solution. I can not tell the solution because there is none yet. The major problems at the moment are responsibilities (who does what), how will we finalize the management restructuring (as this proposal is part of), how can we rearange things to get better QA, and what to do with "small" ebuilds. Paul -- Paul de Vrieze Researcher Mail: pauldv@cs.kun.nl Homepage: http://www.devrieze.net