Re: [proposal] removing non-ASF leaves from the workspace
On Mon, 01 Nov 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: So, let me rephrase my proposal: If a project: 1) is not an ASF project 2) no ASF project depend on it 3) has been broken for a while and shows no sign of activity (gump-wise) +1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Mon, 1 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: Please see my thread about removing commons-xo [1] for an example of one project that we can get rid of. I may be nitpicking, but commons-xo builds fine in Gump if you use Ant instead of Maven. The main problem is that XO declares dependencies in its project.xml it doesn't need (like beanutils). The effect certainly is the same. If nobody wants to fix the project.xml, it obviously is in an unmaintained state. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
Since Leo and Conor already raised the biggest concerns I had with your initial proposal I don't need to talk about them 8-) I'd like to add one thing, though. Sometimes leaves turn into nodes. ant-contrib is such a beast which was a leave for a long time (when I abused my committer power to add them to Gump). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Mon, 01 Nov 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: That's why it took 3 years and several burned-out people to reach 85%. Oh, we had 100% once. And we've been in the 80% area before excalibur moved out of Avalon as well. The biggest problems that made us drop to low success percentages have come from inside the ASF IMHO, and certainly not from leaf builds. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] removing non-ASF leaves from the workspace
I've removed it. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 9:42 AM To: [EMAIL PROTECTED] Subject: Re: [proposal] removing non-ASF leaves from the workspace On Mon, 1 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: Please see my thread about removing commons-xo [1] for an example of one project that we can get rid of. I may be nitpicking, but commons-xo builds fine in Gump if you use Ant instead of Maven. The main problem is that XO declares dependencies in its project.xml it doesn't need (like beanutils). The effect certainly is the same. If nobody wants to fix the project.xml, it obviously is in an unmaintained state. Stefan - 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]
Re: [proposal] removing non-ASF leaves from the workspace
Stefan Bodewig wrote: Since Leo and Conor already raised the biggest concerns I had with your initial proposal I don't need to talk about them 8-) I'd like to add one thing, though. Sometimes leaves turn into nodes. ant-contrib is such a beast which was a leave for a long time (when I abused my committer power to add them to Gump). that is why I suggested to remove the reference from the profile, *NOT* to remove the module/project descriptors ;-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
Stefano Mazzocchi wrote: there are a few projects that gump builds that are not ASF projects and are not used by any ASF project. I'm not sure which projects this is about (or what the projects you listed are about), but I can imagine that these projects are built against the latest and greatest ASF software to make sure that ASF software doesn't introduce incompatible changes. ie Cocoon might like Gump to build Daisy as its a good integration test for cocoon. Abstractly, projects depend on having good dependees available inside the system as a measure for their own backwards compatibility. I think the ASF already has enough things to build for ourselves and gump is not a public service. The ASF is a public service in a way though :-D. I like how gump as a project and a community has tried so hard to reach out to all parts of the oss world, not just the ASF. Abstractly, requiring dependees to be ASF-internal leads to a closed ASF. No good. I personally think that it is abusive for comitters to use their access to add projects that are not required. whoah. Around here stuff like that used to be okay, encouraged even. Gump is now pushing in a somewhat different direction (which I support) so we're changing some of our ideas on this, but that doesn't make the people not quite aware of those unspoken 10-mile-high goals abusive all of a sudden. Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm sure I can found more (and, in fact, I'll write some code to outline those and automate the checks). I propose that we remove those projects from the gump.xml profile that is ran on brutus (we can keep the descriptors there, that doesn't hurt) but I would like to remove all those leaves projects from using cpu/disk space. 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. 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. WTDY? If you have a figure showing this saves significant cpu/disk space that we need for other stuff, you'll get (grudgingly) a +1. cheers, -LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
Stefano Mazzocchi wrote: Conor MacNeill wrote: Stefano Mazzocchi wrote: WTDY? The downside of this idea is that ASF projects will lose warnings about incompatible changes they make that break non-ASF projects. I said: remove non-ASF project that ASF projects don't depend upon. You are talking about removing non-ASF projects upon which no ASF projects depend, right?. I understand this. Please have another read of what I said. By removing those non-ASF projects from Gump, you lose an indication of the downstream effects of changes in ASF projects. Let's take Barcode4J as a (random) example. It depends upon the ASF projects, xalan and avalon-framework. By removing Barcode4J from Gump, you will no longer notice when changes in Xalan and Avalon break Barcode4J. In effect, barcode4J acts as a testcase for its dependencies and you propose to remove that test. I understand the motivation, I'm not particularly concerned, but there is a potential downside, which I thought was worth noting. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Monday 01 November 2004 17:02, Conor MacNeill wrote: In effect, barcode4J acts as a testcase for its dependencies and you propose to remove that test. I understand the motivation, I'm not particularly concerned, but there is a potential downside, which I thought was worth noting. Very good observation, and the importance of external dependees will increase for Apache projects at a 'higher level', which don't have internal dependees. This can OTOH still be achieved by discriminately not build from the external project HEAD, and instead use release tagged snapshots. That provides IMHO the best of both for the ASF side of the equation. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: [proposal] removing non-ASF leaves from the workspace
On Monday 01 November 2004 19:29, Eric Pugh wrote: 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... Hmmm... I wonder if such thought is a sign of Gump creating problem for you, or if Gump amplifies future trouble with external dependencies?? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] removing non-ASF leaves from the workspace
The cost of having to build each dependency in Gump drives home that I may be using some weird dependency that no else is using, and is therefore not already in Gump. However, as long as the code remains buildable, it won't be an issue. In the long run, in 5 years when some libarary I am using is no longer maintained, then this will become key information. Sometimes I just want to build against version XX of a dependency. But this is mostly me being lazy. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 12:58 PM To: Gump code and data Subject: Re: [proposal] removing non-ASF leaves from the workspace On Monday 01 November 2004 19:29, Eric Pugh wrote: 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... Hmmm... I wonder if such thought is a sign of Gump creating problem for you, or if Gump amplifies future trouble with external dependencies?? 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]
Re: [proposal] removing non-ASF leaves from the workspace
Niclas Hedhman niclas at hedhman.org writes: 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. My long term (a few weeks, I hope) plan is to have a second gump instance on developer.classpath.org with the free runtimes to both take the extra load off ASF, and to give further free runtimes like gcj, IKVM, JamVM, etc. a go at building the free java software world from scratch. 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. I appreciate in particular the extremely helpful developers on #gump. Thanks a lot for those that helped me set myself up. I still have to pay you back with the wiki page, though ;) Seriously though, I think gump is just wonderful, and is going to help leapfrog the whole free runtimes thing quite a bit as a side effect. Today, there is a lot of great free software written in Java, not least thanks to ASF's successful projects. Unfortunately, there are often some small issues that prevent some free Java softare from running on free runtimes. Gump can help find and fix those small issues, as it did for GNU JAXP's small bug today for me. The small issues may be bugs in the free runtimes, or code that is just a little bit outside the letter of the specification, but runs fine on non-free runtimes. In particular the latter case is hard to anticipate a priori in a class library implementation. That's where having a gump can be very, very helpful: it shows what idioms other developers expect to work. Finally, I see great potential in maintaining a confidence level in a free java stack, once we're there ;) That could help quite a bit wrt to packaging efforts of free software written in Java for operating systems like GNU/Linux, *BSD, etc. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
Conor MacNeill wrote: Stefano Mazzocchi wrote: Conor MacNeill wrote: Stefano Mazzocchi wrote: WTDY? The downside of this idea is that ASF projects will lose warnings about incompatible changes they make that break non-ASF projects. I said: remove non-ASF project that ASF projects don't depend upon. You are talking about removing non-ASF projects upon which no ASF projects depend, right?. I understand this. Please have another read of what I said. By removing those non-ASF projects from Gump, you lose an indication of the downstream effects of changes in ASF projects. Let's take Barcode4J as a (random) example. It depends upon the ASF projects, xalan and avalon-framework. By removing Barcode4J from Gump, you will no longer notice when changes in Xalan and Avalon break Barcode4J. In effect, barcode4J acts as a testcase for its dependencies and you propose to remove that test. I understand the motivation, I'm not particularly concerned, but there is a potential downside, which I thought was worth noting. Conor, my apologies. You are right and I misunderstood your statement. Point well taken (and echoing with Leo's comment). So, let me rephrase my proposal: If a project: 1) is not an ASF project 2) no ASF project depend on it 3) has been broken for a while and shows no sign of activity (gump-wise) we remove it from the gump.xml profile that brutus runs. As a result: 1) we save some time and space 2) we obtain a more reasonable indication that the gump status *is* is a measure of the community integration Thoughts? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
Niclas Hedhman wrote: 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. The kaffe build increased our disk usage of 7Gb (about 1/6 of our resources) and uses 56 CPU minutes and one 3 hours time slot (about 1/8 of our 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. Not only that. The build on Kaffe is a political tool for the java community: it's the only way to show that we have a way out if Sun decided to do something weird licensing-wise with their JVM. This would be a *huge* service to the java community at large and to the ASF in the first place. 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. We do not have disk-space issues at the moment, but we are not able to get another build in the house. Before going financial, I would spend some time in making sure that the builds could land into another part of the disk. that would reduce disk consumption by an order of magnitude. Some external dependee projects don't build, and is 'annoying' in the reports. This is my main concern: their failures are basically cry wolf, when a real failure happens, nobody notices. We can either remove them, or choose a better snapshot from their CVS. The result would be the same. 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'? Niclas, there are *tons* of things to do in gump before we even start attempting that. Please, let's fix our problems first. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
Eric Pugh wrote: 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. Agreed. 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. I completely agree on the fact that pointing a problem to a single person is way more efficient. There is a way to understand who break what, but it's not easy to implement efficiently since it requires gump to know what versions of the dependencies projects depend on. 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. That's why it took 3 years and several burned-out people to reach 85%. To help with the number of projects, have we thought about more aggressive use of installed packages? Yes, and the number of packages we have already worries me. In the future my goal is exactly the opposite: remove as many packages as we can. 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! This is why we need explicit versioned dependencies (maven pom provides that already) so that we can be *both* a build system *and* a continous integration system. 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... I think this is just awesome: the day a FOG is considered a dependency risk by people downstream is the day gump starts to make sense. Eric, solving the pain right now might just increase it later on. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
Stefano Mazzocchi wrote: If a project: 1) is not an ASF project 2) no ASF project depend on it 3) has been broken for a while and shows no sign of activity (gump-wise) +1 to that one. In the case of has been broken for a LONG time with no sign of activity gump-wise I would even support the above for ASF projects. At least until the tree is cleaned up. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] removing non-ASF leaves from the workspace
I agree. Please see my thread about removing commons-xo [1] for an example of one project that we can get rid of. I think other jakarta-commons-sandbox may be removed as well if they are stagnant... Eric [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg51295.html -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 5:06 PM To: Gump code and data Subject: Re: [proposal] removing non-ASF leaves from the workspace Stefano Mazzocchi wrote: If a project: 1) is not an ASF project 2) no ASF project depend on it 3) has been broken for a while and shows no sign of activity (gump-wise) +1 to that one. In the case of has been broken for a LONG time with no sign of activity gump-wise I would even support the above for ASF projects. At least until the tree is cleaned up. - LSD - 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]
Re: [proposal] removing non-ASF leaves from the workspace
Eric Pugh wrote: Sometimes I just want to build against version XX of a dependency. But this is mostly me being lazy. Well, I think gump should allow you to do that: build against the latest dependency *and* build against the dependency you want. Those are two different things, true, but equally useful and gump should give you both. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
On Monday 01 November 2004 23:41, Stefano Mazzocchi wrote: So, let me rephrase my proposal: If a project: 1) is not an ASF project 2) no ASF project depend on it 3) has been broken for a while and shows no sign of activity (gump-wise) we remove it from the gump.xml profile that brutus runs. As a result: 1) we save some time and space 2) we obtain a more reasonable indication that the gump status *is* is a measure of the community integration +1 -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
I've got no problem with removing Barcode4J from Gump. It is a nice-to-have but I can live without it. Go ahead. On 30.10.2004 19:55:21 Stefano Mazzocchi wrote: there are a few projects that gump builds that are not ASF projects and are not used by any ASF project. I think the ASF already has enough things to build for ourselves and gump is not a public service. I personally think that it is abusive for comitters to use their access to add projects that are not required. Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm sure I can found more (and, in fact, I'll write some code to outline those and automate the checks). I propose that we remove those projects from the gump.xml profile that is ran on brutus (we can keep the descriptors there, that doesn't hurt) but I would like to remove all those leaves projects from using cpu/disk space. WTDY? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
there are a few projects that gump builds that are not ASF projects and are not used by any ASF project. I think the ASF already has enough things to build for ourselves and gump is not a public service. I hear you, but since Gump was a social experiment not an ASF build tool, some of this was reach out. Don't forget that some non-ASF projects that Gump built became ASF projects, e.g. ws-juddi. I personally think that it is abusive for comitters to use their access to add projects that are not required. I don't know as much (partly since I added a few of them ;-). Other folks had the ability to -1 any. We used to run once a day, and as such it wasn't such a big deal. Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm sure I can found more (and, in fact, I'll write some code to outline those and automate the checks). I propose that we remove those projects from the gump.xml profile that is ran on brutus (we can keep the descriptors there, that doesn't hurt) but I would like to remove all those leaves projects from using cpu/disk space. WTDY? We have grown a lot larger in recent months, and are using a lot more CPU/disk. Further, we are trying to do more than one Gump workspace (JDK1.5, Kaffe, etc.) As such, maybe we do have to trim down. If it helps with that that, then go for it. For Gump to scale (as Niclas mentioned) we do need to federate somehow, but that is a separate topic this seems a practical step until then. Folks who really want to be included could petition us for re-inclusion. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
Adam R. B. Jack wrote: there are a few projects that gump builds that are not ASF projects and are not used by any ASF project. I think the ASF already has enough things to build for ourselves and gump is not a public service. I hear you, but since Gump was a social experiment not an ASF build tool, some of this was reach out. Don't forget that some non-ASF projects that Gump built became ASF projects, e.g. ws-juddi. I'm about to propose that we change that 'social experiment' tagline and we turn this into a more solid thing for the ASF. I personally think that it is abusive for comitters to use their access to add projects that are not required. I don't know as much (partly since I added a few of them ;-). Other folks had the ability to -1 any. We used to run once a day, and as such it wasn't such a big deal. Right, we also used to run at 60%, things are changing. Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm sure I can found more (and, in fact, I'll write some code to outline those and automate the checks). I propose that we remove those projects from the gump.xml profile that is ran on brutus (we can keep the descriptors there, that doesn't hurt) but I would like to remove all those leaves projects from using cpu/disk space. WTDY? We have grown a lot larger in recent months, and are using a lot more CPU/disk. Further, we are trying to do more than one Gump workspace (JDK1.5, Kaffe, etc.) As such, maybe we do have to trim down. If it helps with that that, then go for it. For Gump to scale (as Niclas mentioned) we do need to federate somehow, but that is a separate topic this seems a practical step until then. Folks who really want to be included could petition us for re-inclusion. I find particularely silly that we have a projects that: 1) are not from the ASF 2) no ASF project depends on 3) and they constantly don't build and nobody seems to care I find the combination of the above enough to remove a project from our builds. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
Stefano Mazzocchi wrote: WTDY? The downside of this idea is that ASF projects will lose warnings about incompatible changes they make that break non-ASF projects. IOW, info about downstream breakages can be interesting even if it is not a breakage in an ASF project. I know the I always regarded Gump as a giant test of Ant. Ant probably gets enough coverage just from ASF project builds to not be overly concerned, but other projects may be more affected. Just me 2c Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
Conor MacNeill wrote: Stefano Mazzocchi wrote: WTDY? The downside of this idea is that ASF projects will lose warnings about incompatible changes they make that break non-ASF projects. I said: remove non-ASF project that ASF projects don't depend upon. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] removing non-ASF leaves from the workspace
On Sunday 31 October 2004 01:55, Stefano Mazzocchi wrote: there are a few projects that gump builds that are not ASF projects and are not used by any ASF project. I think the ASF already has enough things to build for ourselves and gump is not a public service. I personally think that it is abusive for comitters to use their access to add projects that are not required. Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm sure I can found more (and, in fact, I'll write some code to outline those and automate the checks). I propose that we remove those projects from the gump.xml profile that is ran on brutus (we can keep the descriptors there, that doesn't hurt) but I would like to remove all those leaves projects from using cpu/disk space. WTDY? What Think Do I? :o) First a bit off-topic; isn't this also becoming a scalability issue problem for the ASF model of oversight as well? The more external dependencies that are introduced into the codebase, the higher the risk that non-ASF projects are introducing trojan horses and other security-related issues. There seems to be various levels of desire among ASF committers to make external dependencies, even choosing external ones over viable ASF ones, often with the argument of level of community activity. Anyway, that aside, I think that as long as Gump is not a P2P federation of externally provided CPU resources, I don't see a reason why ASF should build any leaf nodes that no ASF projects are dependent upon. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
