You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Cliff Schmidt <cl...@gmail.com> on 2006/11/17 09:36:51 UTC
Including snapshot dependencies from other ASF projects
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. Paul and I (mentors) have both said
that there could be a way to do this properly, but we also both
thought it was worth discussing on this list, in part because we
expect other podlings out there will have similar questions.
I don't want to revisit the ongoing infrastructure thread about what
constitutes a release, where builds/releases should and shouldn't be
placed, etc. Instead, I'm hoping to understand concerns that
Incubator PMC members have about one of our projects releasing code
that includes unreleased code from another project/podling. The key
point here is that any PMC that releases any code is always
responsible for what it is releasing, whether it's code written under
the purview of the PMC or other dependencies included in the project
-- this isn't a question about whether unreleased code can be
distributed without being voted upon; it's a question of which PMC is
doing the voting.
To see the debate that the Qpid community has been having, take a look
at some of the threads at
http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200611.mbox/thread?3,
particularly the "Maven and artifacts...." thread. Part of the debate
involves technical pros and cons, but I'm trying to get at any policy
issues.
I should point out that the Qpid committers have already submitted
patches to the MINA folks, and from what I've read, MINA has been very
receptive and helpful. The issue here is that even when the patch is
committed to MINA's trunk, they may not choose to create a release
just for this patch or for other reasons within the timeframe when
Qpid would like to do their release. One thing I'm not sure about is
whether the MINA folks have any concerns about Qpid including the
snapshot in their release.
While this issue could apply to any ASF project, not just incubating
ones, I'm raising the issue here because this would be the PMC that
would ultimately approve or reject the release.
Interested in hearing everyone's thoughts (especially PMC members).
Thanks,
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Paul Fremantle <pz...@gmail.com>.
Well I was quite confused myself earlier :-)
Paul
On 11/17/06, Yoav Shapira <yo...@apache.org> wrote:
> Hi,
>
> On 11/17/06, Paul Fremantle <pz...@gmail.com> 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:
> <snip />
>
> Yes, I agree with everything you said in this post. I must have
> misunderstood the case breakdown earlier. Thanks for the
> clarification, and have a good weekend ;)
>
> Yoav
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Yoav Shapira wrote:
> Hi,
>
> On 11/17/06, Paul Fremantle <pz...@gmail.com> 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:
> <snip />
>
> Yes, I agree with everything you said in this post. I must have
> misunderstood the case breakdown earlier. Thanks for the
> clarification, and have a good weekend ;)
Ditto, this was well-put Paul. Someone drag that text to the Wiki :)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 11/17/06, Paul Fremantle <pz...@gmail.com> 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:
<snip />
Yes, I agree with everything you said in this post. I must have
misunderstood the case breakdown earlier. Thanks for the
clarification, and have a good weekend ;)
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Paul Fremantle <pz...@gmail.com>.
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.
For 2a you can rely on Apache's release procedures and pass the buck.
For everything else you have to validate that code.
2b can be split into
2b(i) - non-released Apache code (incubator or TLP)
2b(ii) - Other people's stuff with ASL
2b(iii) - Other people's stuff with another license.
But my point is that there really isn't any difference between 2b(i)
and 2b(ii). Its code that needs to be validated as part of this
release.
Paul
On 11/17/06, Yoav Shapira <yo...@apache.org> wrote:
> Hi,
>
> On 11/17/06, Paul Fremantle <pz...@gmail.com> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 11/17/06, Paul Fremantle <pz...@gmail.com> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Paul Fremantle <pz...@gmail.com>.
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 <br...@apache.org> 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
> > *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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Brian McCallister <br...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Paul Fremantle <pz...@gmail.com>.
> 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, reluctantly, that its binaries
> shouldn't be included in another project.
If we just suppose for a minute that MINA is an external project (not
an Apache project), then we would have a process for validating its
inclusion in the release as an external codebase.
So the fact that MINA is an incubating project shouldn't make it
*harder* to include than a non-Apache project. Or - as you are
suggesting - impossible. If you say that qpid cannot use *any* code
from any incubator project, then by extension that would logically
imply that no Apache project should ever be released with any
non-Apache dependencies included.
Since the MINA code that they wish to release has not been approved by
the Incubator for release, we cannot rely on a previous review.
Therefore the releasing project (e.g. qpid) has to do all the right
checks on the MINA code as well as the QPID code. That is the QPID
team and Incubator team should make no assumptions about the ability
to ship the MINA code. However, the Incubator team should be able to
validate the MINA code just as much as the qpid code.
I suggest that the qpid team as for the support of the MINA mentors at
the point they come to request a release vote for qpid.
If that is all done then there should be no issue in the release
including MINA code.
Paul
>
> Yoav
>
> On 11/17/06, Paul Fremantle <pz...@gmail.com> wrote:
> > 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 of their planned release cycle. I would not expect
> > them to either.
> >
> > So while that is one answer, I don't think it will always apply in every case.
> >
> > Paul
> >
> > On 11/17/06, Jukka Zitting <ju...@gmail.com> wrote:
> > > Hi,
> > >
> > > On 11/17/06, Cliff Schmidt <cl...@gmail.com> 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 consider working with the MINA community to have a
> > > proper release as your dependency? I don't think it should be too hard
> > > to do, the main issues being:
> > >
> > > 1) Technical: Is the code good enough for a release? You already think
> > > the code is good.
> > >
> > > 2) Community: Is there a release manager? If no-one in the MINA
> > > community is interested, there's no stopping one of you from
> > > volunteering.
> > >
> > > 3) Oversight: Is the PMC ready to approve the release? This should
> > > really be up to the MINA PMC to decide.
> > >
> > > BR,
> > >
> > > Jukka Zitting
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Yoav Shapira <yo...@apache.org>.
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 dependant package. I would ask the
dependency to at least create an SVN tag (e.g. MINA_20061116_QPID_0.1)
for this purpose.
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, reluctantly, that its binaries
shouldn't be included in another project.
Yoav
On 11/17/06, Paul Fremantle <pz...@gmail.com> wrote:
> 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 of their planned release cycle. I would not expect
> them to either.
>
> So while that is one answer, I don't think it will always apply in every case.
>
> Paul
>
> On 11/17/06, Jukka Zitting <ju...@gmail.com> wrote:
> > Hi,
> >
> > On 11/17/06, Cliff Schmidt <cl...@gmail.com> 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 consider working with the MINA community to have a
> > proper release as your dependency? I don't think it should be too hard
> > to do, the main issues being:
> >
> > 1) Technical: Is the code good enough for a release? You already think
> > the code is good.
> >
> > 2) Community: Is there a release manager? If no-one in the MINA
> > community is interested, there's no stopping one of you from
> > volunteering.
> >
> > 3) Oversight: Is the PMC ready to approve the release? This should
> > really be up to the MINA PMC to decide.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Paul Fremantle <pz...@gmail.com>.
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 of their planned release cycle. I would not expect
them to either.
So while that is one answer, I don't think it will always apply in every case.
Paul
On 11/17/06, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 11/17/06, Cliff Schmidt <cl...@gmail.com> 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 consider working with the MINA community to have a
> proper release as your dependency? I don't think it should be too hard
> to do, the main issues being:
>
> 1) Technical: Is the code good enough for a release? You already think
> the code is good.
>
> 2) Community: Is there a release manager? If no-one in the MINA
> community is interested, there's no stopping one of you from
> volunteering.
>
> 3) Oversight: Is the PMC ready to approve the release? This should
> really be up to the MINA PMC to decide.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Garrett Rooney wrote:
> On 11/17/06, William A. Rowe, Jr. <wr...@rowe-clan.net> 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 and modded, and the APR team were kept in the loop.
>>
>> Actually, in spite of a wide open-door policy from the apr team to the
>> svn and httpd developer communities, it indicates a breakdown of apr
>> meeting the needs of svn (it's second consumer) and in svn failing to
>> effectively participate in apr. So I actually find it a bad example :)
>
> That's total BS. The svn and httpd teams worked quite hard to get
> their fixes in to APR, and I'm not aware of them either distributing
> patched releases, only snapshots, and eventually releases. The only
> reason that releases and snapshots were distributed was that for a
> long time you couldn't expect to find APR installed on most machines,
> and the svn team wanted to avoid requiring people to scramble around
> looking for dependencies.
Yes - the failures were early on and remedied (and amusingly enough, the
situation around expat and pcre in httpd has similarly improved.) I was
speaking of the early failures that we learned from.
> These days it isn't even distributed as
> part of the default release tarball, but as part of a separate deps
> tarball that just holds extra dependencies.
Yup - living on the bleeding edge of a support library is an interesting
place to be. The point was not to slam svn about apr, or httpd about pcre
or expat, but to point out that this is a problem to be solved. It's not
(living with snapshots of dependent sources) an issue that we should worry
about persisting. And in this case it *is* part of the release the project
is voting on, and in one sense, becomes a release of the dependency.
Paul explained it clearly.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 11/17/06, William A. Rowe, Jr. <wr...@rowe-clan.net> 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 and modded, and the APR team were kept in the loop.
>
> Actually, in spite of a wide open-door policy from the apr team to the
> svn and httpd developer communities, it indicates a breakdown of apr
> meeting the needs of svn (it's second consumer) and in svn failing to
> effectively participate in apr. So I actually find it a bad example :)
That's total BS. The svn and httpd teams worked quite hard to get
their fixes in to APR, and I'm not aware of them either distributing
patched releases, only snapshots, and eventually releases. The only
reason that releases and snapshots were distributed was that for a
long time you couldn't expect to find APR installed on most machines,
and the svn team wanted to avoid requiring people to scramble around
looking for dependencies. These days it isn't even distributed as
part of the default release tarball, but as part of a separate deps
tarball that just holds extra dependencies.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 11/17/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Of course, svn is not an ASF project so they don't (have any reason to)
> follow our tar - vote - distribute rules.
FWIW, correct - but - Subversion largely follows the ASF release rules
(releases get at least 3 +1s before being posted). In some cases, I'd
argue they go too far compared to our 'stock' rules here (specifically
regarding platform testing). -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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, in spite of a wide open-door policy from the apr team to the
svn and httpd developer communities, it indicates a breakdown of apr
meeting the needs of svn (it's second consumer) and in svn failing to
effectively participate in apr. So I actually find it a bad example :)
But the expat and pcre bundled packages are similar examples. For a very
long time, official distributions of pcre wouldn't even interoperate. We
aren't talking the few build choice changes to better integrate, but the
code itself.
> There is a difference between "release" and distribute.
> We're asking if a project can distribute some arbitrary SVN point in
> anothers repository, not if they can release it.
If you ship code *here at the ASF* as your project's tarball, you are
releasing it. This IS the very definition of a release, and attempting
to split hairs on the subject is what made this thread run away. Even
if SVN doesn't ship the official APR, it will land in /usr/local/lib and
therefore overlays the release.
Anything we distribute (e.g. svn's apr, or apr's expat) is released by us
no matter if it's an arbitrary svn point, or if it's a specific release.
Of course, svn is not an ASF project so they don't (have any reason to)
follow our tar - vote - distribute rules.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Carl Trieloff <cc...@redhat.com>.
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'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 most part, in the more-recent past, Subversion shipped with the
> version of APR that HTTPD shipped with, which sometimes was a SVN
> snapshot, and sometimes as release.
>
> In the most-recent past, Subversion has only been shipping with real APR
> releases, unpatched. HTTPD now also only ships with real APR releases,
> unpatched.
>
> -Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Including snapshot dependencies from other ASF projects
Posted by Paul Querna <ch...@force-elite.com>.
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 most part, in the more-recent past, Subversion shipped with the
version of APR that HTTPD shipped with, which sometimes was a SVN
snapshot, and sometimes as release.
In the most-recent past, Subversion has only been shipping with real APR
releases, unpatched. HTTPD now also only ships with real APR releases,
unpatched.
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by John O'Hara <jo...@gmail.com>.
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 "release" and distribute.
We're asking if a project can distribute some arbitrary SVN point in
anothers repository, not if they can release it.
Does that make any kind of sense?
John
On 17/11/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> 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' project Y's
> code? Because that is, in fact, what you are asking.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Including snapshot dependencies from other ASF projects
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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' project Y's
code? Because that is, in fact, what you are asking.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 11/17/06, Martin Ritchie <ri...@apache.org> 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 to release?
I would do that, even given the concerns about delays expressed in
other comments. Doing otherwise feels like a slippery slope towards
forking the other project.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Martin Ritchie <ri...@apache.org>.
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 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 to release?
Cheers
--
Martin Ritchie
Qpid
On 17/11/06, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 11/17/06, Cliff Schmidt <cl...@gmail.com> 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 consider working with the MINA community to have a
> proper release as your dependency? I don't think it should be too hard
> to do, the main issues being:
>
> 1) Technical: Is the code good enough for a release? You already think
> the code is good.
>
> 2) Community: Is there a release manager? If no-one in the MINA
> community is interested, there's no stopping one of you from
> volunteering.
>
> 3) Oversight: Is the PMC ready to approve the release? This should
> really be up to the MINA PMC to decide.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 11/17/06, Cliff Schmidt <cl...@gmail.com> 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 consider working with the MINA community to have a
proper release as your dependency? I don't think it should be too hard
to do, the main issues being:
1) Technical: Is the code good enough for a release? You already think
the code is good.
2) Community: Is there a release manager? If no-one in the MINA
community is interested, there's no stopping one of you from
volunteering.
3) Oversight: Is the PMC ready to approve the release? This should
really be up to the MINA PMC to decide.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Cliff Schmidt <cl...@gmail.com>.
On 11/17/06, Cliff Schmidt <cl...@gmail.com> 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". The committers want to do the right thing and have
> asked their mentors for advice. Paul and I (mentors) have both said
> that there could be a way to do this properly, but we also both
> thought it was worth discussing on this list, in part because we
> expect other podlings out there will have similar questions.
Thanks to everyone for all the great feedback! I feel so warm and
happy inside when we have such a helpful and productive thread on this
list. :-)
For anyone interested, I'm personally recommending (can't speak for
other mentors, although we've been pretty much on the same page so
far) that the Qpid PPMC follow Leo's outline (including (0)). Thanks
for putting the time into writing that, Leo!
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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 other project, build a
release package containing just the last release plus fixes, and
then ask the other project for three +1s.
If that failed, I would try to distribute just a released version
and add override classes/methods where necessary. Lacking that
possibility, I would copy/paste the code and change the class names,
essentially creating a temporary fork.
I don't think that Incubator podlings should be any different from
regular projects in this regard, and I don't think we should prevent
them from doing what needs to be done to cut a release. I think it
is very healthy for a podling to think about it first, discuss the
options with the other Apache project second, and then do what is
best for the podling's product based upon those discussions.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Cliff Schmidt <cl...@gmail.com>.
On 11/20/06, Carl Trieloff <cc...@redhat.com> wrote:
> Marnie McCormack wrote:
> > Hi Cliff,
> >
> > Thanks very much for progressing this for us.
> >
> > It has been encouraging to read such thoughtful and pragmatic
> > responses from
> > Leo and Henri.
> >
> > My reading of their responses is that if we cannot use a MINA release, we
> > can proceed with the snapshot if the MINA team do not object and there
> > are
> > valid reasons for doing so (and we follow the advice about declaring the
> > snapshot appropriately.
> >
> > Is this how you read the feedback ?
Yes -- but be sure to read Leo's "== next steps ==" section. I think
he spells out a few qpid-specific details there that also seem pretty
reasonable to me.
> I know Robert has been speaking with MINA team. Looking through all
> those mails
> on the MINA list I would guess the next step would be write a mail that
> copies both
> the MINA and Qpid lists and ask if they would create us one case (3). if
> not we then need to
> document the details to release M1 under case (4)
Yep - that makes sense as a start to me, but see Leo's "== next steps
==" for more details. Let me know if any of those steps don't make
sense to any of you -- they all seem reasonable to me.
Cliff
Re: Including snapshot dependencies from other ASF projects
Posted by Carl Trieloff <cc...@redhat.com>.
Marnie McCormack wrote:
> Hi Cliff,
>
> Thanks very much for progressing this for us.
>
> It has been encouraging to read such thoughtful and pragmatic
> responses from
> Leo and Henri.
>
> My reading of their responses is that if we cannot use a MINA release, we
> can proceed with the snapshot if the MINA team do not object and there
> are
> valid reasons for doing so (and we follow the advice about declaring the
> snapshot appropriately.
>
> Is this how you read the feedback ?
I know Robert has been speaking with MINA team. Looking through all
those mails
on the MINA list I would guess the next step would be write a mail that
copies both
the MINA and Qpid lists and ask if they would create us one case (3). if
not we then need to
document the details to release M1 under case (4)
(3) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(4) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
Re: Including snapshot dependencies from other ASF projects
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Cliff,
Thanks very much for progressing this for us.
It has been encouraging to read such thoughtful and pragmatic responses from
Leo and Henri.
My reading of their responses is that if we cannot use a MINA release, we
can proceed with the snapshot if the MINA team do not object and there are
valid reasons for doing so (and we follow the advice about declaring the
snapshot appropriately.
Is this how you read the feedback ?
(BTW I'm leaving aside, for now, Henri's comments about issues that maven
build tools might have with snapshots (which I think is better discussed in
a separate thread).
Thanks & Regards,
Marnie
On 11/20/06, Cliff Schmidt <cl...@gmail.com> wrote:
>
> We got a lot of good feedback on the incubator general@ thread about
> this issue. Most PMC members seemed to feel that there was a way to
> do this properly. Paul Fremantle made some very good points about
> this. And then, Leo Simons had a very detailed suggestion. Leo is
> just one of the many members of the Incubator PMC, but I think his
> email below is really well thought out and makes a lot of sense.
>
> I recommend the the Qpid PPMC adopt his guidelines below for dealing
> with the MINA situation and similar ones in the future (I'm not saying
> there needs to be a formal vote to do decide to follow his email, but
> that I think it would be nice if there appeared to be a general
> consensus to do things this way). Henri Yandell (also on the PMC and
> on the ASF board) had a few additional comments worth considering as
> well:
> http://mail-archives.apache.org/mod_mbox/incubator-general/200611.mbox/%3c31cc37360611171549r380bc3bdg32eda533340c8153@mail.gmail.com%3e
> .
>
> Cliff
>
> ---------- Forwarded message ----------
> From: Leo Simons
> Date: Nov 17, 2006 2:02 PM
> Subject: Re: Including snapshot dependencies from other ASF projects
> To: general at incubator .apache.org
>
>
> 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 everyone's thoughts (especially PMC members).
>
> Ah, interesting and complex subject...
>
> = IMHO =
>
> (0) above and beyond all the below, release management is not
> easily encapsulated in rules like this and (P)PMCs SHOULD
> spend serious effort in figuring this kind of thing out for
> themselves and their specific situation
>
> (1) for any release from an incubating project...
> (2) all dependencies SHOULD have a stable/final release
> (3) failing that, all dependencies SHOULD have a
> project-sanctioned beta/alpha/snapshot release
> (4) failing that, custom builds of all dependencies
> SHOULD be clearly identified as such and traceable
> to their exact origin, eg
>
> qpid-1.1.4-incubating.zip
> lib/
> mina-r2475690.qpid-1.1.4-incubating.jar
>
> (5) the community whose code you're packaging SHOULD
> be notified of this activity and MUST NOT have
> any serious objections
> (6) custom builds of other incubating projects SHOULD
> NOT be included at all
> (7) the source, license, and status for all dependencies MUST
> be clearly documented
>
> (8) for any release from a non-incubating project...
> (9) all dependencies SHOULD have a stable/final release
> (10) failing that, all dependencies SHOULD have a
> project-sanctioned beta/alpha/snapshot release
> (11) failing that, custom builds of all dependencies
> SHOULD be clearly identified as such and traceable
> to their exact origin, eg
>
> qpid-1.1.4-incubating.zip
> lib/
> mina-r2475690.qpid-1.1.4-incubating.jar
>
> (12) the community whose code you're packaging SHOULD
> be notified of this activity and MUST NOT have
> any serious objections
> (13) custom builds of other incubating projects MUST
> NOT be included at all
> (14) dependencies SHOULD NOT be incubating projects
> (15) the source, license, and status for all dependencies MUST
> be clearly documented
>
>
> = Some ranting to explain and qualify this further =
>
> (0) really is the only clear and unambiguous "rule" if you ask me.
>
> The difference between (1)-(7) and (8)-(15) is between (6) and
> (13,14): projects that are not incubating really MUST NOT ship with
> custom builds of incubating projects, and I think having dependencies
> on incubating projects should also not happen in general (though
> there can be good exceptions to this, in particular when the
> incubating project was already an established open source project
> with a compatible license, eg a dependency on an incubator release of
> activemq or wicket would be just fine).
>
> For java projects that following the maven-style naming mechanism,
> one example is having a jar which has "SNAPSHOT" in its name, by
> itself that DOES NOT satisfy (7) or (15), and "downloaded from
> ibiblio" in terms of "where we got it" is also NOT OK.
>
> Note this is all, explicitly, **IM(NS)HO**. There's quite a few
> projects out there that don't follow these rules at all.
>
> (...)
>
> (16) With my incubator PMC hat on, when I vote, I will vote according
> to (1)-(7), and I expect[*] that any SHOULDs or SHOULD NOTs that
> can't be met are explicitly brought to my attention when asked to vote.
>
> (17) With my member-of-other PMC hat on, when I vote, I will vote
> according to (8)-(15).
>
> I will often get (16,17) wrong at least a little bit. Since I try
> hard to get it right, you don't see me voting on many podling releases.
>
> With other hats on (like infrastructure when I was active there, or
> that of a general opinionist), I will usually refrain from claiming
> any MUSTs or SHOULDs, but if I have a vested interest in a project I
> will often be rather vocal nonetheless.
>
>
> = Applying this opinion of mine to qpid/MINA =
>
> - good to see the discussion
> - good to see the question asked
>
>
> == next steps ==
> - try and work within the MINA community to get the release
> you need
> - if that doesn't work out, let the MINA community know you
> will build a custom release
> - if they object, work to get the objections dealt with
> - do a custom branch of the mina tree (you can `svn cp` parts
> of the ASF repository into your own svn area easily
> enough)
> - change (project|pom).xml and similar files to have a
> sensible artifact version
> - create the MINA snapshot from your branch
> - do not release or seperately distribute your snapshot, and
> add some documentation to discourage others from doing so as
> needed
> - include the MINA snapshot in your release candidate
> - document the MINA's snapshot use and origin
> - business as usual
> - note the custom-built thingie (by reference probably) on
> the VOTE thread for the podling release
> - note that doing this properly is often more work than just
> doing the needed work within MINA, especially if you have a
> good working relationship with that community already
>
>
> cheers,
>
> /LSD
>
> [*] and this is because of the awkward PMC-member-sometimes-votes-on-
> software-he-does-not-work-on thing we have around here
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Fwd: Including snapshot dependencies from other ASF projects
Posted by Cliff Schmidt <cl...@gmail.com>.
We got a lot of good feedback on the incubator general@ thread about
this issue. Most PMC members seemed to feel that there was a way to
do this properly. Paul Fremantle made some very good points about
this. And then, Leo Simons had a very detailed suggestion. Leo is
just one of the many members of the Incubator PMC, but I think his
email below is really well thought out and makes a lot of sense.
I recommend the the Qpid PPMC adopt his guidelines below for dealing
with the MINA situation and similar ones in the future (I'm not saying
there needs to be a formal vote to do decide to follow his email, but
that I think it would be nice if there appeared to be a general
consensus to do things this way). Henri Yandell (also on the PMC and
on the ASF board) had a few additional comments worth considering as
well: http://mail-archives.apache.org/mod_mbox/incubator-general/200611.mbox/%3c31cc37360611171549r380bc3bdg32eda533340c8153@mail.gmail.com%3e.
Cliff
---------- Forwarded message ----------
From: Leo Simons
Date: Nov 17, 2006 2:02 PM
Subject: Re: Including snapshot dependencies from other ASF projects
To: general at incubator .apache.org
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 everyone's thoughts (especially PMC members).
Ah, interesting and complex subject...
= IMHO =
(0) above and beyond all the below, release management is not
easily encapsulated in rules like this and (P)PMCs SHOULD
spend serious effort in figuring this kind of thing out for
themselves and their specific situation
(1) for any release from an incubating project...
(2) all dependencies SHOULD have a stable/final release
(3) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(4) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
(5) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(6) custom builds of other incubating projects SHOULD
NOT be included at all
(7) the source, license, and status for all dependencies MUST
be clearly documented
(8) for any release from a non-incubating project...
(9) all dependencies SHOULD have a stable/final release
(10) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(11) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
(12) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(13) custom builds of other incubating projects MUST
NOT be included at all
(14) dependencies SHOULD NOT be incubating projects
(15) the source, license, and status for all dependencies MUST
be clearly documented
= Some ranting to explain and qualify this further =
(0) really is the only clear and unambiguous "rule" if you ask me.
The difference between (1)-(7) and (8)-(15) is between (6) and
(13,14): projects that are not incubating really MUST NOT ship with
custom builds of incubating projects, and I think having dependencies
on incubating projects should also not happen in general (though
there can be good exceptions to this, in particular when the
incubating project was already an established open source project
with a compatible license, eg a dependency on an incubator release of
activemq or wicket would be just fine).
For java projects that following the maven-style naming mechanism,
one example is having a jar which has "SNAPSHOT" in its name, by
itself that DOES NOT satisfy (7) or (15), and "downloaded from
ibiblio" in terms of "where we got it" is also NOT OK.
Note this is all, explicitly, **IM(NS)HO**. There's quite a few
projects out there that don't follow these rules at all.
(...)
(16) With my incubator PMC hat on, when I vote, I will vote according
to (1)-(7), and I expect[*] that any SHOULDs or SHOULD NOTs that
can't be met are explicitly brought to my attention when asked to vote.
(17) With my member-of-other PMC hat on, when I vote, I will vote
according to (8)-(15).
I will often get (16,17) wrong at least a little bit. Since I try
hard to get it right, you don't see me voting on many podling releases.
With other hats on (like infrastructure when I was active there, or
that of a general opinionist), I will usually refrain from claiming
any MUSTs or SHOULDs, but if I have a vested interest in a project I
will often be rather vocal nonetheless.
= Applying this opinion of mine to qpid/MINA =
- good to see the discussion
- good to see the question asked
== next steps ==
- try and work within the MINA community to get the release
you need
- if that doesn't work out, let the MINA community know you
will build a custom release
- if they object, work to get the objections dealt with
- do a custom branch of the mina tree (you can `svn cp` parts
of the ASF repository into your own svn area easily
enough)
- change (project|pom).xml and similar files to have a
sensible artifact version
- create the MINA snapshot from your branch
- do not release or seperately distribute your snapshot, and
add some documentation to discourage others from doing so as
needed
- include the MINA snapshot in your release candidate
- document the MINA's snapshot use and origin
- business as usual
- note the custom-built thingie (by reference probably) on
the VOTE thread for the podling release
- note that doing this properly is often more work than just
doing the needed work within MINA, especially if you have a
good working relationship with that community already
cheers,
/LSD
[*] and this is because of the awkward PMC-member-sometimes-votes-on-
software-he-does-not-work-on thing we have around here
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Carl Trieloff <cc...@redhat.com>.
this is great, thank you. It gives us a clear way to work the issue in qpid.
Regards
Carl.
John O'Hara wrote:
> Great analysis.
> I concur with the points.
>
> John
> On 17/11/06, Henri Yandell <fl...@gmail.com> wrote:
>>
>> On 11/17/06, Leo Simons <ma...@leosimons.com> 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 do so by
>> > > "Apache rules".
>> > (...)
>> > > Interested in hearing everyone's thoughts (especially PMC members).
>> >
>> > Ah, interesting and complex subject...
>> >
>> > = IMHO =
>> >
>> > (0) above and beyond all the below, release management is not
>> > easily encapsulated in rules like this and (P)PMCs SHOULD
>> > spend serious effort in figuring this kind of thing out for
>> > themselves and their specific situation
>>
>> +1
>>
>> > (1) for any release from an incubating project...
>> > (2) all dependencies SHOULD have a stable/final release
>> > (3) failing that, all dependencies SHOULD have a
>> > project-sanctioned beta/alpha/snapshot release
>> > (4) failing that, custom builds of all dependencies
>> > SHOULD be clearly identified as such and traceable
>> > to their exact origin, eg
>> >
>> > qpid-1.1.4-incubating.zip
>> > lib/
>> > mina-r2475690.qpid-1.1.4-incubating.jar
>>
>> +1. Revision and who it's for are essential.
>>
>> > (5) the community whose code you're packaging SHOULD
>> > be notified of this activity and MUST NOT have
>> > any serious objections
>> > (6) custom builds of other incubating projects SHOULD
>> > NOT be included at all
>>
>> One thing I think we shouldn't do is have an incubating project be
>> deemed less 'safe' that a project outside the ASF. So +1 to SHOULD NOT
>> rather than MUST NOT. Definitely a place where (0) is expected to take
>> strong precedence.
>>
>> > (7) the source, license, and status for all dependencies MUST
>> > be clearly documented
>> >
>> > (8) for any release from a non-incubating project...
>> > (9) all dependencies SHOULD have a stable/final release
>> > (10) failing that, all dependencies SHOULD have a
>> > project-sanctioned beta/alpha/snapshot release
>> > (11) failing that, custom builds of all dependencies
>> > SHOULD be clearly identified as such and traceable
>> > to their exact origin, eg
>> >
>> > qpid-1.1.4-incubating.zip
>> > lib/
>> > mina-r2475690.qpid-1.1.4-incubating.jar
>> >
>> > (12) the community whose code you're packaging SHOULD
>> > be notified of this activity and MUST NOT have
>> > any serious objections
>> > (13) custom builds of other incubating projects MUST
>> > NOT be included at all
>> >
>> > (14) dependencies SHOULD NOT be incubating projects
>> >
>> > (15) the source, license, and status for all dependencies MUST
>> > be clearly documented
>> >
>> >
>> > = Some ranting to explain and qualify this further =
>> >
>> > (0) really is the only clear and unambiguous "rule" if you ask me.
>> >
>> > The difference between (1)-(7) and (8)-(15) is between (6) and
>> > (13,14): projects that are not incubating really MUST NOT ship with
>> > custom builds of incubating projects, and I think having dependencies
>> > on incubating projects should also not happen in general (though
>> > there can be good exceptions to this, in particular when the
>> > incubating project was already an established open source project
>> > with a compatible license, eg a dependency on an incubator release of
>> > activemq or wicket would be just fine).
>>
>> +1
>>
>> > For java projects that following the maven-style naming mechanism,
>> > one example is having a jar which has "SNAPSHOT" in its name, by
>> > itself that DOES NOT satisfy (7) or (15), and "downloaded from
>> > ibiblio" in terms of "where we got it" is also NOT OK.
>>
>> Yep, banning SNAPSHOTs in releases is becoming the defacto. Afaik, the
>> Maven2 release plugin does not allow releases with snapshots in the
>> dependency tree, and we definitely ban such a thing in Commons
>> releases (we averaged 2 releases a month when we weren't very active -
>> now we'd probably want to do 1 a week if we could get up to speed; so
>> Commons has a lot of release discussions).
>>
>> Snapshot dependencies come back to bite you in many user error
>> reports. It's not worth the benefit of not having to solve this stuff
>> up front.
>>
>> (snip...)
>>
>> > = Applying this opinion of mine to qpid/MINA =
>> >
>> > - good to see the discussion
>> > - good to see the question asked
>> >
>> >
>> > == next steps ==
>> > - try and work within the MINA community to get the release
>> > you need
>>
>> And have patience here. It may slow your project down, but the ties
>> between your project and the dependency are worth the slow down.
>>
>> Geronimo needed Axis to do a 1.4 release; and in the end one of the
>> Geronimo guys dug in and did a lot of the work for it. Axis needed
>> Commons to do a release, and an Axis guy dug in and did the work.
>> Although this can be a pain, the ties between the communities are much
>> more valuable in the long term than the short-term delay (imnsho etc).
>>
>> > - if that doesn't work out, let the MINA community know you
>> > will build a custom release
>>
>> I'd like to see reports of custom releases in board reports. It's a
>> reflection on communities working together and being aware of this is
>> critical for the board I think. It shouldn't be a negative aspect
>> towards either community, there are good reasons why one community has
>> to go fast and one has to go slow.
>>
>> > - if they object, work to get the objections dealt with
>> > - do a custom branch of the mina tree (you can `svn cp` parts
>> > of the ASF repository into your own svn area easily
>> > enough)
>> > - change (project|pom).xml and similar files to have a
>> > sensible artifact version
>> > - create the MINA snapshot from your branch
>> > - do not release or seperately distribute your snapshot, and
>>
>> Is this possible if you're going to be a maven build? ie) there will
>> be a mina jar that qpid would need to depend on. If it's a maven build
>> (no idea what qpid uses); would they change the group id to be qpid's
>> id, or keep it as mina's?
>>
>> > add some documentation to discourage others from doing so as
>> > needed
>> > - include the MINA snapshot in your release candidate
>> > - document the MINA's snapshot use and origin
>> > - business as usual
>> > - note the custom-built thingie (by reference probably) on
>> > the VOTE thread for the podling release
>>
>> How about package name? Should those be changed to avoid clashes with
>> official releases?
>>
>> > - note that doing this properly is often more work than just
>> > doing the needed work within MINA, especially if you have a
>> > good working relationship with that community already
>>
>> Yep. Effectively you are taking on the role of release manager, so
>> it's going to be more effort doing it from scratch than in the
>> original place with local experts (even if they're inactive).
>>
>> Great email Leo :)
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by John O'Hara <jo...@gmail.com>.
Great analysis.
I concur with the points.
John
On 17/11/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 11/17/06, Leo Simons <ma...@leosimons.com> 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 do so by
> > > "Apache rules".
> > (...)
> > > Interested in hearing everyone's thoughts (especially PMC members).
> >
> > Ah, interesting and complex subject...
> >
> > = IMHO =
> >
> > (0) above and beyond all the below, release management is not
> > easily encapsulated in rules like this and (P)PMCs SHOULD
> > spend serious effort in figuring this kind of thing out for
> > themselves and their specific situation
>
> +1
>
> > (1) for any release from an incubating project...
> > (2) all dependencies SHOULD have a stable/final release
> > (3) failing that, all dependencies SHOULD have a
> > project-sanctioned beta/alpha/snapshot release
> > (4) failing that, custom builds of all dependencies
> > SHOULD be clearly identified as such and traceable
> > to their exact origin, eg
> >
> > qpid-1.1.4-incubating.zip
> > lib/
> > mina-r2475690.qpid-1.1.4-incubating.jar
>
> +1. Revision and who it's for are essential.
>
> > (5) the community whose code you're packaging SHOULD
> > be notified of this activity and MUST NOT have
> > any serious objections
> > (6) custom builds of other incubating projects SHOULD
> > NOT be included at all
>
> One thing I think we shouldn't do is have an incubating project be
> deemed less 'safe' that a project outside the ASF. So +1 to SHOULD NOT
> rather than MUST NOT. Definitely a place where (0) is expected to take
> strong precedence.
>
> > (7) the source, license, and status for all dependencies MUST
> > be clearly documented
> >
> > (8) for any release from a non-incubating project...
> > (9) all dependencies SHOULD have a stable/final release
> > (10) failing that, all dependencies SHOULD have a
> > project-sanctioned beta/alpha/snapshot release
> > (11) failing that, custom builds of all dependencies
> > SHOULD be clearly identified as such and traceable
> > to their exact origin, eg
> >
> > qpid-1.1.4-incubating.zip
> > lib/
> > mina-r2475690.qpid-1.1.4-incubating.jar
> >
> > (12) the community whose code you're packaging SHOULD
> > be notified of this activity and MUST NOT have
> > any serious objections
> > (13) custom builds of other incubating projects MUST
> > NOT be included at all
> >
> > (14) dependencies SHOULD NOT be incubating projects
> >
> > (15) the source, license, and status for all dependencies MUST
> > be clearly documented
> >
> >
> > = Some ranting to explain and qualify this further =
> >
> > (0) really is the only clear and unambiguous "rule" if you ask me.
> >
> > The difference between (1)-(7) and (8)-(15) is between (6) and
> > (13,14): projects that are not incubating really MUST NOT ship with
> > custom builds of incubating projects, and I think having dependencies
> > on incubating projects should also not happen in general (though
> > there can be good exceptions to this, in particular when the
> > incubating project was already an established open source project
> > with a compatible license, eg a dependency on an incubator release of
> > activemq or wicket would be just fine).
>
> +1
>
> > For java projects that following the maven-style naming mechanism,
> > one example is having a jar which has "SNAPSHOT" in its name, by
> > itself that DOES NOT satisfy (7) or (15), and "downloaded from
> > ibiblio" in terms of "where we got it" is also NOT OK.
>
> Yep, banning SNAPSHOTs in releases is becoming the defacto. Afaik, the
> Maven2 release plugin does not allow releases with snapshots in the
> dependency tree, and we definitely ban such a thing in Commons
> releases (we averaged 2 releases a month when we weren't very active -
> now we'd probably want to do 1 a week if we could get up to speed; so
> Commons has a lot of release discussions).
>
> Snapshot dependencies come back to bite you in many user error
> reports. It's not worth the benefit of not having to solve this stuff
> up front.
>
> (snip...)
>
> > = Applying this opinion of mine to qpid/MINA =
> >
> > - good to see the discussion
> > - good to see the question asked
> >
> >
> > == next steps ==
> > - try and work within the MINA community to get the release
> > you need
>
> And have patience here. It may slow your project down, but the ties
> between your project and the dependency are worth the slow down.
>
> Geronimo needed Axis to do a 1.4 release; and in the end one of the
> Geronimo guys dug in and did a lot of the work for it. Axis needed
> Commons to do a release, and an Axis guy dug in and did the work.
> Although this can be a pain, the ties between the communities are much
> more valuable in the long term than the short-term delay (imnsho etc).
>
> > - if that doesn't work out, let the MINA community know you
> > will build a custom release
>
> I'd like to see reports of custom releases in board reports. It's a
> reflection on communities working together and being aware of this is
> critical for the board I think. It shouldn't be a negative aspect
> towards either community, there are good reasons why one community has
> to go fast and one has to go slow.
>
> > - if they object, work to get the objections dealt with
> > - do a custom branch of the mina tree (you can `svn cp` parts
> > of the ASF repository into your own svn area easily
> > enough)
> > - change (project|pom).xml and similar files to have a
> > sensible artifact version
> > - create the MINA snapshot from your branch
> > - do not release or seperately distribute your snapshot, and
>
> Is this possible if you're going to be a maven build? ie) there will
> be a mina jar that qpid would need to depend on. If it's a maven build
> (no idea what qpid uses); would they change the group id to be qpid's
> id, or keep it as mina's?
>
> > add some documentation to discourage others from doing so as
> > needed
> > - include the MINA snapshot in your release candidate
> > - document the MINA's snapshot use and origin
> > - business as usual
> > - note the custom-built thingie (by reference probably) on
> > the VOTE thread for the podling release
>
> How about package name? Should those be changed to avoid clashes with
> official releases?
>
> > - note that doing this properly is often more work than just
> > doing the needed work within MINA, especially if you have a
> > good working relationship with that community already
>
> Yep. Effectively you are taking on the role of release manager, so
> it's going to be more effort doing it from scratch than in the
> original place with local experts (even if they're inactive).
>
> Great email Leo :)
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Including snapshot dependencies from other ASF projects
Posted by Henri Yandell <fl...@gmail.com>.
On 11/17/06, Leo Simons <ma...@leosimons.com> 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 do so by
> > "Apache rules".
> (...)
> > Interested in hearing everyone's thoughts (especially PMC members).
>
> Ah, interesting and complex subject...
>
> = IMHO =
>
> (0) above and beyond all the below, release management is not
> easily encapsulated in rules like this and (P)PMCs SHOULD
> spend serious effort in figuring this kind of thing out for
> themselves and their specific situation
+1
> (1) for any release from an incubating project...
> (2) all dependencies SHOULD have a stable/final release
> (3) failing that, all dependencies SHOULD have a
> project-sanctioned beta/alpha/snapshot release
> (4) failing that, custom builds of all dependencies
> SHOULD be clearly identified as such and traceable
> to their exact origin, eg
>
> qpid-1.1.4-incubating.zip
> lib/
> mina-r2475690.qpid-1.1.4-incubating.jar
+1. Revision and who it's for are essential.
> (5) the community whose code you're packaging SHOULD
> be notified of this activity and MUST NOT have
> any serious objections
> (6) custom builds of other incubating projects SHOULD
> NOT be included at all
One thing I think we shouldn't do is have an incubating project be
deemed less 'safe' that a project outside the ASF. So +1 to SHOULD NOT
rather than MUST NOT. Definitely a place where (0) is expected to take
strong precedence.
> (7) the source, license, and status for all dependencies MUST
> be clearly documented
>
> (8) for any release from a non-incubating project...
> (9) all dependencies SHOULD have a stable/final release
> (10) failing that, all dependencies SHOULD have a
> project-sanctioned beta/alpha/snapshot release
> (11) failing that, custom builds of all dependencies
> SHOULD be clearly identified as such and traceable
> to their exact origin, eg
>
> qpid-1.1.4-incubating.zip
> lib/
> mina-r2475690.qpid-1.1.4-incubating.jar
>
> (12) the community whose code you're packaging SHOULD
> be notified of this activity and MUST NOT have
> any serious objections
> (13) custom builds of other incubating projects MUST
> NOT be included at all
>
> (14) dependencies SHOULD NOT be incubating projects
>
> (15) the source, license, and status for all dependencies MUST
> be clearly documented
>
>
> = Some ranting to explain and qualify this further =
>
> (0) really is the only clear and unambiguous "rule" if you ask me.
>
> The difference between (1)-(7) and (8)-(15) is between (6) and
> (13,14): projects that are not incubating really MUST NOT ship with
> custom builds of incubating projects, and I think having dependencies
> on incubating projects should also not happen in general (though
> there can be good exceptions to this, in particular when the
> incubating project was already an established open source project
> with a compatible license, eg a dependency on an incubator release of
> activemq or wicket would be just fine).
+1
> For java projects that following the maven-style naming mechanism,
> one example is having a jar which has "SNAPSHOT" in its name, by
> itself that DOES NOT satisfy (7) or (15), and "downloaded from
> ibiblio" in terms of "where we got it" is also NOT OK.
Yep, banning SNAPSHOTs in releases is becoming the defacto. Afaik, the
Maven2 release plugin does not allow releases with snapshots in the
dependency tree, and we definitely ban such a thing in Commons
releases (we averaged 2 releases a month when we weren't very active -
now we'd probably want to do 1 a week if we could get up to speed; so
Commons has a lot of release discussions).
Snapshot dependencies come back to bite you in many user error
reports. It's not worth the benefit of not having to solve this stuff
up front.
(snip...)
> = Applying this opinion of mine to qpid/MINA =
>
> - good to see the discussion
> - good to see the question asked
>
>
> == next steps ==
> - try and work within the MINA community to get the release
> you need
And have patience here. It may slow your project down, but the ties
between your project and the dependency are worth the slow down.
Geronimo needed Axis to do a 1.4 release; and in the end one of the
Geronimo guys dug in and did a lot of the work for it. Axis needed
Commons to do a release, and an Axis guy dug in and did the work.
Although this can be a pain, the ties between the communities are much
more valuable in the long term than the short-term delay (imnsho etc).
> - if that doesn't work out, let the MINA community know you
> will build a custom release
I'd like to see reports of custom releases in board reports. It's a
reflection on communities working together and being aware of this is
critical for the board I think. It shouldn't be a negative aspect
towards either community, there are good reasons why one community has
to go fast and one has to go slow.
> - if they object, work to get the objections dealt with
> - do a custom branch of the mina tree (you can `svn cp` parts
> of the ASF repository into your own svn area easily
> enough)
> - change (project|pom).xml and similar files to have a
> sensible artifact version
> - create the MINA snapshot from your branch
> - do not release or seperately distribute your snapshot, and
Is this possible if you're going to be a maven build? ie) there will
be a mina jar that qpid would need to depend on. If it's a maven build
(no idea what qpid uses); would they change the group id to be qpid's
id, or keep it as mina's?
> add some documentation to discourage others from doing so as
> needed
> - include the MINA snapshot in your release candidate
> - document the MINA's snapshot use and origin
> - business as usual
> - note the custom-built thingie (by reference probably) on
> the VOTE thread for the podling release
How about package name? Should those be changed to avoid clashes with
official releases?
> - note that doing this properly is often more work than just
> doing the needed work within MINA, especially if you have a
> good working relationship with that community already
Yep. Effectively you are taking on the role of release manager, so
it's going to be more effort doing it from scratch than in the
original place with local experts (even if they're inactive).
Great email Leo :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Including snapshot dependencies from other ASF projects
Posted by Leo Simons <ma...@leosimons.com>.
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 everyone's thoughts (especially PMC members).
Ah, interesting and complex subject...
= IMHO =
(0) above and beyond all the below, release management is not
easily encapsulated in rules like this and (P)PMCs SHOULD
spend serious effort in figuring this kind of thing out for
themselves and their specific situation
(1) for any release from an incubating project...
(2) all dependencies SHOULD have a stable/final release
(3) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(4) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
(5) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(6) custom builds of other incubating projects SHOULD
NOT be included at all
(7) the source, license, and status for all dependencies MUST
be clearly documented
(8) for any release from a non-incubating project...
(9) all dependencies SHOULD have a stable/final release
(10) failing that, all dependencies SHOULD have a
project-sanctioned beta/alpha/snapshot release
(11) failing that, custom builds of all dependencies
SHOULD be clearly identified as such and traceable
to their exact origin, eg
qpid-1.1.4-incubating.zip
lib/
mina-r2475690.qpid-1.1.4-incubating.jar
(12) the community whose code you're packaging SHOULD
be notified of this activity and MUST NOT have
any serious objections
(13) custom builds of other incubating projects MUST
NOT be included at all
(14) dependencies SHOULD NOT be incubating projects
(15) the source, license, and status for all dependencies MUST
be clearly documented
= Some ranting to explain and qualify this further =
(0) really is the only clear and unambiguous "rule" if you ask me.
The difference between (1)-(7) and (8)-(15) is between (6) and
(13,14): projects that are not incubating really MUST NOT ship with
custom builds of incubating projects, and I think having dependencies
on incubating projects should also not happen in general (though
there can be good exceptions to this, in particular when the
incubating project was already an established open source project
with a compatible license, eg a dependency on an incubator release of
activemq or wicket would be just fine).
For java projects that following the maven-style naming mechanism,
one example is having a jar which has "SNAPSHOT" in its name, by
itself that DOES NOT satisfy (7) or (15), and "downloaded from
ibiblio" in terms of "where we got it" is also NOT OK.
Note this is all, explicitly, **IM(NS)HO**. There's quite a few
projects out there that don't follow these rules at all.
(...)
(16) With my incubator PMC hat on, when I vote, I will vote according
to (1)-(7), and I expect[*] that any SHOULDs or SHOULD NOTs that
can't be met are explicitly brought to my attention when asked to vote.
(17) With my member-of-other PMC hat on, when I vote, I will vote
according to (8)-(15).
I will often get (16,17) wrong at least a little bit. Since I try
hard to get it right, you don't see me voting on many podling releases.
With other hats on (like infrastructure when I was active there, or
that of a general opinionist), I will usually refrain from claiming
any MUSTs or SHOULDs, but if I have a vested interest in a project I
will often be rather vocal nonetheless.
= Applying this opinion of mine to qpid/MINA =
- good to see the discussion
- good to see the question asked
== next steps ==
- try and work within the MINA community to get the release
you need
- if that doesn't work out, let the MINA community know you
will build a custom release
- if they object, work to get the objections dealt with
- do a custom branch of the mina tree (you can `svn cp` parts
of the ASF repository into your own svn area easily
enough)
- change (project|pom).xml and similar files to have a
sensible artifact version
- create the MINA snapshot from your branch
- do not release or seperately distribute your snapshot, and
add some documentation to discourage others from doing so as
needed
- include the MINA snapshot in your release candidate
- document the MINA's snapshot use and origin
- business as usual
- note the custom-built thingie (by reference probably) on
the VOTE thread for the podling release
- note that doing this properly is often more work than just
doing the needed work within MINA, especially if you have a
good working relationship with that community already
cheers,
/LSD
[*] and this is because of the awkward PMC-member-sometimes-votes-on-
software-he-does-not-work-on thing we have around here
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: Including snapshot dependencies from other ASF projects
Posted by Cliff Schmidt <cl...@gmail.com>.
FYI -- just sent this to the Incubator general list. We'll see what
the rest of the PMC thinks about it. Any of you should definitely
feel free to jump in with corrections or opinions.
Cliff
---------- Forwarded message ----------
From: Cliff Schmidt
Date: Nov 17, 2006 12:36 AM
Subject: Including snapshot dependencies from other ASF projects
To: general at incubator
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. Paul and I (mentors) have both said
that there could be a way to do this properly, but we also both
thought it was worth discussing on this list, in part because we
expect other podlings out there will have similar questions.
I don't want to revisit the ongoing infrastructure thread about what
constitutes a release, where builds/releases should and shouldn't be
placed, etc. Instead, I'm hoping to understand concerns that
Incubator PMC members have about one of our projects releasing code
that includes unreleased code from another project/podling. The key
point here is that any PMC that releases any code is always
responsible for what it is releasing, whether it's code written under
the purview of the PMC or other dependencies included in the project
-- this isn't a question about whether unreleased code can be
distributed without being voted upon; it's a question of which PMC is
doing the voting.
To see the debate that the Qpid community has been having, take a look
at some of the threads at
http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200611.mbox/thread?3,
particularly the "Maven and artifacts...." thread. Part of the debate
involves technical pros and cons, but I'm trying to get at any policy
issues.
I should point out that the Qpid committers have already submitted
patches to the MINA folks, and from what I've read, MINA has been very
receptive and helpful. The issue here is that even when the patch is
committed to MINA's trunk, they may not choose to create a release
just for this patch or for other reasons within the timeframe when
Qpid would like to do their release. One thing I'm not sure about is
whether the MINA folks have any concerns about Qpid including the
snapshot in their release.
While this issue could apply to any ASF project, not just incubating
ones, I'm raising the issue here because this would be the PMC that
would ultimately approve or reject the release.
Interested in hearing everyone's thoughts (especially PMC members).
Thanks,
Cliff