You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/09/26 22:40:09 UTC
Incubator dependencies in Apache projects
Hi,
Here's another angle to the incubating release issue. We already
discussed this lately in relation to Apache FtpServer and the
JSecurity podling, see http://markmail.org/message/g23r7rvwvbzbn47z.
Some of the comments I found troubling were "You will probably not
release this code to an unsuspecting public anyway, will you?" and
"the actual bottom line is that if the MINA project wants to release
JSecurity as an *internal* dependency, that is the MINA project's
"problem" to support." Another troubling thing is that the question
even needed to be asked.
IMHO the only guidance that we give other projects about incubating
dependencies should be included in the required disclaimers and the
fact that we approve a release in the first place. After that it's up
to the other project to review and decide whether they want the
dependency or not.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by Matthieu Riou <ma...@offthelip.org>.
On Fri, Sep 26, 2008 at 3:59 PM, Davanum Srinivas <da...@gmail.com> wrote:
> I agree with Doug. We don't need explicit disclaimers. We can
> encourage them however to mention it somewhere appropriate.
>
+1. If it ain't broke don't fix it.
Matthieu
>
> thanks,
> dims
>
> On Fri, Sep 26, 2008 at 5:49 PM, Doug Cutting <cu...@apache.org> wrote:
> > Upayavira wrote:
> >>
> >> Exactly. I was writing something much the same. We could even require
> >> TLP projects that have incubating dependencies to include a statement in
> >> their releases to that effect: "Should any of our incubating
> >> dependencies fail incubation, we (the TLP) will take responsibility for
> >> that code so as to continue supporting our users."
> >
> > -1 Do we require similar disclaimers when we depend on BSD licensed code
> > from SourceForge that one guy wrote and that hasn't been updated in a
> year?
> > Outside of legalities, it's up to each PMC to decide whether a
> dependency
> > is a good for its project. Sometimes the best solution isn't a great
> > solution, but it might be better than no solution at all. If a project
> > depends on something that dies, then it has to decide whether it can live
> > without it, reanimate it, use something else, or whatever. We don't
> > otherwise mandate back-compatibility from one release to the next. Back
> > compatibility is a very good way to maintain a community, but it's not
> > absolutely required by the ASF.
> >
> > Doug
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Incubator dependencies in Apache projects
Posted by Davanum Srinivas <da...@gmail.com>.
I agree with Doug. We don't need explicit disclaimers. We can
encourage them however to mention it somewhere appropriate.
thanks,
dims
On Fri, Sep 26, 2008 at 5:49 PM, Doug Cutting <cu...@apache.org> wrote:
> Upayavira wrote:
>>
>> Exactly. I was writing something much the same. We could even require
>> TLP projects that have incubating dependencies to include a statement in
>> their releases to that effect: "Should any of our incubating
>> dependencies fail incubation, we (the TLP) will take responsibility for
>> that code so as to continue supporting our users."
>
> -1 Do we require similar disclaimers when we depend on BSD licensed code
> from SourceForge that one guy wrote and that hasn't been updated in a year?
> Outside of legalities, it's up to each PMC to decide whether a dependency
> is a good for its project. Sometimes the best solution isn't a great
> solution, but it might be better than no solution at all. If a project
> depends on something that dies, then it has to decide whether it can live
> without it, reanimate it, use something else, or whatever. We don't
> otherwise mandate back-compatibility from one release to the next. Back
> compatibility is a very good way to maintain a community, but it's not
> absolutely required by the ASF.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by Doug Cutting <cu...@apache.org>.
Upayavira wrote:
> Exactly. I was writing something much the same. We could even require
> TLP projects that have incubating dependencies to include a statement in
> their releases to that effect: "Should any of our incubating
> dependencies fail incubation, we (the TLP) will take responsibility for
> that code so as to continue supporting our users."
-1 Do we require similar disclaimers when we depend on BSD licensed
code from SourceForge that one guy wrote and that hasn't been updated in
a year? Outside of legalities, it's up to each PMC to decide whether a
dependency is a good for its project. Sometimes the best solution isn't
a great solution, but it might be better than no solution at all. If a
project depends on something that dies, then it has to decide whether it
can live without it, reanimate it, use something else, or whatever. We
don't otherwise mandate back-compatibility from one release to the next.
Back compatibility is a very good way to maintain a community, but
it's not absolutely required by the ASF.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Sep 26, 2008 at 10:54 PM, Upayavira <uv...@odoko.co.uk> wrote:
> We could even require TLP projects that have incubating dependencies
> to include a statement in their releases to that effect: "Should any
> of our incubating dependencies fail incubation, we (the TLP) will take
> responsibility for that code so as to continue supporting our users."
Why?
A TLP will obviously support it's users, but I don't see why it should
take responsibility for the codebase of a failed dependency. Of course
they can do so if it makes sense for the project, but that should not
(and IMHO can not) be a mandate from the Incubator.
For example, Apache Jackrabbit uses the PDFBox library as a dependency
to implement full text indexing of PDF documents. PDFBox is currently
incubating and Jackrabbit will most likely upgrade the dependency as
soon as PDFBox makes its first incubating release. However, there are
no PDF experts in Jackrabbit (that I know of) and there is no way
Jackrabbit could take over the PDFBox code, should PDFBox fail
incubation. Most likely Jackrabbit would just keep using the last
release until some other library with better PDF support appears.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by sebb <se...@gmail.com>.
On 26/09/2008, Upayavira <uv...@odoko.co.uk> wrote:
> On Fri, 2008-09-26 at 22:40 +0200, Jukka Zitting wrote:
> > Hi,
> >
> > Here's another angle to the incubating release issue. We already
> > discussed this lately in relation to Apache FtpServer and the
> > JSecurity podling, see http://markmail.org/message/g23r7rvwvbzbn47z.
> > Some of the comments I found troubling were "You will probably not
> > release this code to an unsuspecting public anyway, will you?" and
> > "the actual bottom line is that if the MINA project wants to release
> > JSecurity as an *internal* dependency, that is the MINA project's
> > "problem" to support." Another troubling thing is that the question
> > even needed to be asked.
> >
> > IMHO the only guidance that we give other projects about incubating
> > dependencies should be included in the required disclaimers and the
> > fact that we approve a release in the first place. After that it's up
> > to the other project to review and decide whether they want the
> > dependency or not.
>
>
> Exactly. I was writing something much the same. We could even require
> TLP projects that have incubating dependencies to include a statement in
> their releases to that effect: "Should any of our incubating
> dependencies fail incubation, we (the TLP) will take responsibility for
> that code so as to continue supporting our users."
That's an excellent idea.
It puts the onus where it belongs.
> Regards, Upayavira
>
>
>
>
> ---------------------------------------------------------------------
> 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: Incubator dependencies in Apache projects
Posted by Upayavira <uv...@odoko.co.uk>.
On Fri, 2008-09-26 at 22:40 +0200, Jukka Zitting wrote:
> Hi,
>
> Here's another angle to the incubating release issue. We already
> discussed this lately in relation to Apache FtpServer and the
> JSecurity podling, see http://markmail.org/message/g23r7rvwvbzbn47z.
> Some of the comments I found troubling were "You will probably not
> release this code to an unsuspecting public anyway, will you?" and
> "the actual bottom line is that if the MINA project wants to release
> JSecurity as an *internal* dependency, that is the MINA project's
> "problem" to support." Another troubling thing is that the question
> even needed to be asked.
>
> IMHO the only guidance that we give other projects about incubating
> dependencies should be included in the required disclaimers and the
> fact that we approve a release in the first place. After that it's up
> to the other project to review and decide whether they want the
> dependency or not.
Exactly. I was writing something much the same. We could even require
TLP projects that have incubating dependencies to include a statement in
their releases to that effect: "Should any of our incubating
dependencies fail incubation, we (the TLP) will take responsibility for
that code so as to continue supporting our users."
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 30, 2008, at 1:49 PM, Niclas Hedhman wrote:
> On Tue, Sep 30, 2008 at 12:14 AM, Daniel Kulp <dk...@apache.org>
> wrote:
>> On Monday 29 September 2008 12:08:52 pm Kevan Miller wrote:
>>> On Sep 26, 2008, at 4:49 PM, Davanum Srinivas wrote:
>>>> Agreed. We've done this before and i bring it up yet again :)
>>>>
>>>> Geronimo PMC used Yoko, Yoko failed, they ended up absorbing most
>>>> of
>>>> the code.
>>>
>>> I wouldn't call Yoko *failed*. It didn't generate enough interest to
>>> go TLP, but did become a sub-project of Geronimo. Also, portions
>>> were
>>> donated to CXF. Seems like a *success* to me.
>>
>> I have to agree. All parts of the Yoko codebase are now supported
>> and
>> enhanced in active projects. That sounds like a success, not a
>> failure.
>
> So, there is a subproject in Geronimo which is essentially the Yoko
> codebase, released in a way so non-Geronimo users can consume that
> codebase?? If so, Excellent.
Yes. That's correct. The Yoko ORB is a Geronimo subproject. Yoko
committers were adopted into Geronimo. Yoko is released separately and
is being consumed by other projects (i.e. Apache Harmony).
> But the matter of fact is, that the
> STATUS page says "dissolved, with parts going to Geronimo and CXF",
> which implies a different story, and indeed says "Yoko didn't make
> it.", i.e. failure. Please call it for what it is, it IS Ok for
> podlings to end, dissolve, absorbed, evaporate and whatever other
> possible end-of-life we can imagine... Just because a podling fails,
> it doesn't mean that any particular person or group of persons fail.
> Two different things.
I wasn't involved with the wording of the Yoko status page, nor with
the resolution as they left incubator. Not familiar with why it was
worded in the way they were...
I don't think we need to debate semantics, here. I think we're
largely in agreement. We're debating shades of grey, here... IMO,
"fail" is harsh description of the outcome.
--kevan
Re: Incubator dependencies in Apache projects
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Sep 30, 2008 at 12:14 AM, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 29 September 2008 12:08:52 pm Kevan Miller wrote:
>> On Sep 26, 2008, at 4:49 PM, Davanum Srinivas wrote:
>> > Agreed. We've done this before and i bring it up yet again :)
>> >
>> > Geronimo PMC used Yoko, Yoko failed, they ended up absorbing most of
>> > the code.
>>
>> I wouldn't call Yoko *failed*. It didn't generate enough interest to
>> go TLP, but did become a sub-project of Geronimo. Also, portions were
>> donated to CXF. Seems like a *success* to me.
>
> I have to agree. All parts of the Yoko codebase are now supported and
> enhanced in active projects. That sounds like a success, not a failure.
So, there is a subproject in Geronimo which is essentially the Yoko
codebase, released in a way so non-Geronimo users can consume that
codebase?? If so, Excellent. But the matter of fact is, that the
STATUS page says "dissolved, with parts going to Geronimo and CXF",
which implies a different story, and indeed says "Yoko didn't make
it.", i.e. failure. Please call it for what it is, it IS Ok for
podlings to end, dissolve, absorbed, evaporate and whatever other
possible end-of-life we can imagine... Just because a podling fails,
it doesn't mean that any particular person or group of persons fail.
Two different things.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 29 September 2008 12:08:52 pm Kevan Miller wrote:
> On Sep 26, 2008, at 4:49 PM, Davanum Srinivas wrote:
> > Agreed. We've done this before and i bring it up yet again :)
> >
> > Geronimo PMC used Yoko, Yoko failed, they ended up absorbing most of
> > the code.
>
> I wouldn't call Yoko *failed*. It didn't generate enough interest to
> go TLP, but did become a sub-project of Geronimo. Also, portions were
> donated to CXF. Seems like a *success* to me.
I have to agree. All parts of the Yoko codebase are now supported and
enhanced in active projects. That sounds like a success, not a failure.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 26, 2008, at 4:49 PM, Davanum Srinivas wrote:
> Agreed. We've done this before and i bring it up yet again :)
>
> Geronimo PMC used Yoko, Yoko failed, they ended up absorbing most of
> the code.
I wouldn't call Yoko *failed*. It didn't generate enough interest to
go TLP, but did become a sub-project of Geronimo. Also, portions were
donated to CXF. Seems like a *success* to me.
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator dependencies in Apache projects
Posted by Davanum Srinivas <da...@gmail.com>.
Agreed. We've done this before and i bring it up yet again :)
Geronimo PMC used Yoko, Yoko failed, they ended up absorbing most of the code.
-- dims
On Fri, Sep 26, 2008 at 4:40 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> Here's another angle to the incubating release issue. We already
> discussed this lately in relation to Apache FtpServer and the
> JSecurity podling, see http://markmail.org/message/g23r7rvwvbzbn47z.
> Some of the comments I found troubling were "You will probably not
> release this code to an unsuspecting public anyway, will you?" and
> "the actual bottom line is that if the MINA project wants to release
> JSecurity as an *internal* dependency, that is the MINA project's
> "problem" to support." Another troubling thing is that the question
> even needed to be asked.
>
> IMHO the only guidance that we give other projects about incubating
> dependencies should be included in the required disclaimers and the
> fact that we approve a release in the first place. After that it's up
> to the other project to review and decide whether they want the
> dependency or not.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org