Robert,
This does look like a good start.
Based on recently going through this (or trying to...) with OFBiz I
found quite a bit of good information in the Policy guide and was
able to divine more or less what needed to be done, but there is
little indication of the order of doing things.
I don't think there is a simple answer, other than the general rules
of three +1s and source code required. However, Java code has
additional concerns related to classpath conflicts that could make
distributing snapshots harmful to the origin project.
My first try would be to jump over to that o
Great analysis.
I concur with the points.
John
On 17/11/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 11/17/06, Leo Simons <[EMAIL PROTECTED]> wrote:
> On Nov 17, 2006, at 9:36 AM, Cliff Schmidt wrote:
> > The Qpid community has been debating whether or not they should
> > include an unreleas
On 11/17/06, Leo Simons <[EMAIL PROTECTED]> wrote:
On Nov 17, 2006, at 9:36 AM, Cliff Schmidt wrote:
> The Qpid community has been debating whether or not they should
> include an unreleased snapshot version of MINA within their upcoming
> Qpid release, and whether they would even be allowed to d
The ServiceMix community voted on and has approved to release ServiceMix
3.0.1-incubating.
We would now like to request the permission of the Incubator PMC to
publish the release.
You can preview the site release / download page at:
http://goopen.org/confluence/display/SM/ServiceMix+3.0.1
Thi
Garrett Rooney wrote:
> On 11/17/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>> John O'Hara wrote:
>> > I don't think its the same as releasing another projects code.
>> > A good example is when SubVersion included APR as part of its code
>> > base. No one would have confused that as a rel
On Nov 17, 2006, at 9:36 AM, Cliff Schmidt wrote:
The Qpid community has been debating whether or not they should
include an unreleased snapshot version of MINA within their upcoming
Qpid release, and whether they would even be allowed to do so by
"Apache rules".
(...)
Interested in hearing eve
On 11/17/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
John O'Hara wrote:
> I don't think its the same as releasing another projects code.
> A good example is when SubVersion included APR as part of its code
> base. No one would have confused that as a release of APR, and
> it was patched
Henri Yandell wrote:
> One thing that came out of the board meeting was making sure that the
> community knew how to bring code into the ASF. What the scenarios are,
> and what the rules are.
I'm looking at some logistics and have been following what I see other
ASF projects doing. Are the steps b
Some of the smarter browsers will look at the .jar suffix and try to
execute it by looking at the manifest to find the Main program. This
is not the behavior we want. I don't know of any such issues
with .zip files. If these are automatically processed by the browser
download program, they
Yoav Shapira wrote:
> Hi,
>
> On 11/17/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
>> But my point is that as part of a release you have to validate *all*
>> the code that you ship in that release. In that code there are
>> logically two things:
>
>
> Yes, I agree with everything you said in t
John O'Hara wrote:
> I don't think its the same as releasing another projects code.
> A good example is when SubVersion included APR as part of its code
> base. No one would have confused that as a release of APR, and
> it was patched and modded, and the APR team were kept in the loop.
Actually,
This message is NOT cross-posted.
Does RAT have enough smarts to do this kind of checking?
Craig
Begin forwarded message:
From: Steve Loughran <[EMAIL PROTECTED]>
Date: November 17, 2006 6:45:18 AM PST
To: repository@apache.org
Subject: Re: bad metadata in commons-logging 1.1
Reply-To: reposi
Well I was quite confused myself earlier :-)
Paul
On 11/17/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
Hi,
On 11/17/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> But my point is that as part of a release you have to validate *all*
> the code that you ship in that release. In that code there
Hi,
On 11/17/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
But my point is that as part of a release you have to validate *all*
the code that you ship in that release. In that code there are
logically two things:
Yes, I agree with everything you said in this post. I must have
misunderstood t
But my point is that as part of a release you have to validate *all*
the code that you ship in that release. In that code there are
logically two things:
1) your own code contributed to this project
2) other code.
The other code can be split into:
2a) Released Apache artifacts
2b) Other code.
F
Hi,
On 11/17/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Doh
Sorry. My apologies for that. I got carried away with my example.
I still think the principle applies.
I think it's a big difference though. TLPs have proven their merit in
following the standard release process.
Yoav
Doh
Sorry. My apologies for that. I got carried away with my example.
I still think the principle applies.
Paul
On 11/17/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
On Nov 17, 2006, at 6:20 AM, Paul Fremantle wrote:
> So the fact that MINA is an incubating project shouldn't make it
> *
On Nov 17, 2006, at 6:20 AM, Paul Fremantle wrote:
So the fact that MINA is an incubating project shouldn't make it
*harder* to include than a non-Apache project.
For what it's worth, MINA isn't incubating, it is a TLP: http://
mina.apache.org/
-Brian
-
For Incubating projects, I'm very hesitant about the above. The
reason is that we've been paying a lot of attention to podling
releases and validation thereof. If the dependency podling, MINA in
this case, has never had an ASF-approved release, we're getting into
dicey territory, and I would say
For development releases, it seems like it should be quite reasonable
and maybe needed to use
snapshots, however when doing a major release it would seem that you
would take all possible
effort not to use snapshots, and only use them if absolutely required.
Carl.
Paul Querna wrote:
John O'H
John O'Hara wrote:
> I don't think its the same as releasing another projects code.
> A good example is when SubVersion included APR as part of its code
> base. No
> one would have confused that as a release of APR, and it was patched and
> modded, and the APR team were kept in the loop.
For the
I don't think its the same as releasing another projects code.
A good example is when SubVersion included APR as part of its code base. No
one would have confused that as a release of APR, and it was patched and
modded, and the APR team were kept in the loop.
There is a difference between "relea
Hi,
On 11/17/06, Martin Ritchie <[EMAIL PROTECTED]> wrote:
The concern the Qpid project was having is what happens when you are
doing everything that you can but you need to release a version of
your software but cannot get one of your dependencies to release a new
version.
Do you wait for them
Hi,
In my personal opinion, for normal (non-Incubating) projects, if you
can't get a real release from your dependency (that's the ideal goal,
is Jukka pointed out), you have to get at least an SVN tag or a
labelled nightly build. There has to be a way to get at the
dependency code outside of the
Martin Ritchie wrote:
>
> Do you wait for them to release?
Yes
Or ship patched, with a patch that is approved with the release. But that's
usually not the best choice if you can get some traction at the project that
has the flaw.
It raises an interesting question, can ASF project X 'release' p
Jukka
As a general point, there may be a significant delay in getting a
release with a given patch in it. For example, the Synapse incubator
relies on Axis2. Axis2 is a fairly significant project and they would
be unlikely to be willing or able to create a release with a few minor
patches outside
The question is more general than working with another ASF project.
The Mina people are great and we are working with them.
Your points are absolutely valid for ASF projects and for other open
source work that has similar release process that we could work
within.
The concern the Qpid project wa
Hi,
On 11/17/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
The Qpid community has been debating whether or not they should
include an unreleased snapshot version of MINA within their upcoming
Qpid release, and whether they would even be allowed to do so by
"Apache rules".
Did you already consid
The Qpid community has been debating whether or not they should
include an unreleased snapshot version of MINA within their upcoming
Qpid release, and whether they would even be allowed to do so by
"Apache rules". The committers want to do the right thing and have
asked their mentors for advice.
30 matches
Mail list logo
