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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
-
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo
