I think it comes down to maintence. If projects have active committers who are trying to fix them when they break, then great, lets keep them. Regardless of where they come from. But, if projects are in the system that don't have active committers trying to fix them/deal with the issues, then lets remove them.
I wish that we tracked who the "goto" person was versus just mailing list for various projects. Maybe set up a more flexible approach like 'after 10 failures' we contact the goto person to remind them. After '30 failures' then we remove any leaf projects. Part of the complexity of Gump is that so many things can go wrong. And when things start going wrong, the rate really speeds up and then everything goes wrong. And fixing it can seem like a mountain to climb. To help with the number of projects, have we thought about more aggressive use of installed packages? I know that goes against the current spirit of gump. But really, I don't care about the OpenSymphony dependencies I am using, I just want my ASF projects that depend on OpenSymphony code to build under gump! Maybe someday, when everything is rocksolid, then I'll start paring out the number of packages that I am using. Related to this, I am starting to think about dependencies not just in a "is it a good dependency to have" but in a "what challenges will having this dependency give me in Gump land", which isn't a great thing... Eric > -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Monday, November 01, 2004 10:40 AM > To: Gump code and data > Subject: Re: [proposal] removing non-ASF leaves from the workspace > > > On Monday 01 November 2004 17:00, Leo Simons wrote: > > Kaffe is very much a leaf not a dependency (I know no ASF project > > that can only be built using Kaffe), yet using it for experimental > > runs doubles the amount of cpu and disk space used. > > For the record, there are 8 attempts at starting a Gump build every day. > 1 is Kaffe, 1 is JDK1.5, 1 is 'test' and the others are the > official build. > So, it is not completely accurate to say that the Kaffe build > instance doubles > CPU/disk resources. > > > While I appreciate the goal of being able to have a truly free java > > stack and how using Kaffe to build ASF projects helps towards attaining > > that goal, we're also doing "public service" towards the GNU people in > > this way. > > Looking at the fact that a Kaffe developer (dalibor) has taken > interest in > Gump, installed his own instance and trying hard to get things > going, is IMHO > a good testament to the appreciation of Gump. > > > If you have a figure showing this saves significant cpu/disk space that > > we need for other stuff, you'll get (grudgingly) a +1. > > CPU/disk is basically a financial issue. If it is constrained > today, we can > take temporary measures to exclude projects to make room. > > Some external dependee projects don't build, and is 'annoying' in > the reports. > We can either remove them, or choose a better snapshot from their CVS. > > Those are short-term issues, and I think that removal of > non-fixed dependee > projects are adequate in the short-term. > What we should start discussing is, how do we scale Gump 'real big'? > If company A, can take part of a massive Gump build, provided > that they make > server(s) available for a massively parallelized builds, then I > think *many* > would like to be part of the Gump service, and therefor ASF will > have access > to 'unlimited' CPU/disk resources for those builds (i.e. each > participants > will make available more resource than their part will consume). > > IMHO, this is a tangible, highly interesting and highly valuable > challenge, > and not beyond reach. > > Cheers > Niclas > -- > +------//-------------------+ > / http://www.bali.ac / > / http://niclas.hedhman.org / > +------//-------------------+ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
