You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Eddie ONeil <ek...@gmail.com> on 2005/05/29 14:21:32 UTC
a beehive release and the JSR 181 TCK issue
All--
There has been some confusion publicly and privately about the JSR
181 TCK issues and the WSM part of Beehive.
The goals of WSM are to implement the JSR 181 specification and to
provide a generic annotation processor for the 181 annotations. In
addition, there is a layer that implements JSR 181 features for the
Axis web service stack.
The JSR 181 specification is being developed under the JCP 2.6
process and has reached the "Final Approval Ballot" stage. But, this
is not the *final* release of the specification. This means that the
spec is not completely finished and that the RI and TCK are not
available.
Both Craig and Geir have confirmed that in order to ship a "final"
version of Beehive that claims to implement JSR 181, we must pass the
JSR 181 TCK. Currently, we are blocked on even starting this work
because the TCK has not been released. I've exchanged some mail with
Geir, and once the TCK is available, he will help us obtain it through
Apache channels and we can start the process of passing the TCK. The
TCK work will be done at Apache under NDA.
The implication here is that Beehive (NetUI + Controls + WSM) can
not go "final" as a whole until the TCK has been released and WSM has
passed.
The purpose of this milestone was to provide incremental progress
toward a 1.0-final release of the stable NetUI and Controls parts of
Beehive, Then, we'd do a subsequent Beehive release that has JSR 181
TCK compliance.
So, it seems to me that the passing the TCK and doing a milestone
release are orthogonal until we consider doing a release that doesn't
include WSM.
It would certainly be possible to release a version of Beehive that
had only the NetUI + Controls bits and let the WSM part continue to
bake until the TCK becomes available and is passed. WSM could then be
included in a later release. Thoughts about this are welcome;
honestly, I'd be fine with this approach.
But, I do think that we should complete the current milestone
release in order to get something new out there.
:)
Eddie
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: a beehive release and the JSR 181 TCK issue
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 30, 2005, at 9:45 PM, Eddie O'Neil wrote:
>
> Comments in-line...
>
> Geir Magnusson Jr. wrote:
>
>> On May 29, 2005, at 8:21 AM, Eddie ONeil wrote:
>>
>>>
>>> But, I do think that we should complete the current milestone
>>> release in order to get something new out there.
>>>
>> +1
>> If you are calling this a milestone increment rather than a real
>> "we're complete and support this" release, then by all means,
>> throw in the JSR-181 stuff. We do this in Apache Geronimom all
>> the time, and it's clear that our milestone releases are not J2EE
>> 1.4 compliant.
>>
>
> Yeah, I agree with this direction, and once the current release is
> done in a couple of days, we'll start exploring this option on
> beehive-dev@.
>
> No reason to have WSM artificially hold us up.
I think my point was that since this isn't a Release, you could keep
the WSM material in there as it's not in any way claiming
completeness or compliance with the spec.
>
> :)
>
>
>
>> geir
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: a beehive release and the JSR 181 TCK issue
Posted by Eddie O'Neil <ek...@bea.com>.
Comments in-line...
Geir Magnusson Jr. wrote:
>
> On May 29, 2005, at 8:21 AM, Eddie ONeil wrote:
>
>> All--
>>
>> There has been some confusion publicly and privately about the JSR
>> 181 TCK issues and the WSM part of Beehive.
>>
>> The goals of WSM are to implement the JSR 181 specification and to
>> provide a generic annotation processor for the 181 annotations. In
>> addition, there is a layer that implements JSR 181 features for the
>> Axis web service stack.
>>
>> The JSR 181 specification is being developed under the JCP 2.6
>> process and has reached the "Final Approval Ballot" stage. But, this
>> is not the *final* release of the specification. This means that the
>> spec is not completely finished and that the RI and TCK are not
>> available.
>>
>> Both Craig and Geir have confirmed that in order to ship a "final"
>> version of Beehive that claims to implement JSR 181, we must pass the
>> JSR 181 TCK. Currently, we are blocked on even starting this work
>> because the TCK has not been released. I've exchanged some mail with
>> Geir, and once the TCK is available, he will help us obtain it through
>> Apache channels and we can start the process of passing the TCK. The
>> TCK work will be done at Apache under NDA.
>>
>> The implication here is that Beehive (NetUI + Controls + WSM) can
>> not go "final" as a whole until the TCK has been released and WSM has
>> passed.
>
>
> Well, where there's a will...
>
> what are you implementing now? A pre-final spec that's public?
Yes, I think so -- hopefully it's the spec that's available here:
http://jcp.org/aboutJava/communityprocess/pfd/jsr181/index.html
but I've not been that involved in the WSM third and could be wrong
about that...
>
> Right now, we have the awful situation in the JCP that any pre-final
> spec isn't licensed for implementation. However, Oracle, JBoss and
> Hibernate are shipping
> example implementations of the EJB3 public draft (which I think is a
> good thing in terms of getting implementations out for people to play
> with...)
>
> However, that's not really permitted, and quite frankly, theoretically
> dangerous because any IP contributed to the spec by the expert group
> experts has not been licensed for use in the spec - that only happens
> when the spec is final, and the spec lead is granted right to license
> the IP for compatible implementations.
>
> So the question here is "what do we do?"
>
> We can
>
> a) just do it and violate the license (I'm not for that)
>
> b) wait until the TCK is complete (that works, but holds you up)
>
> c) try to find some permission.
>
>
> I'm happy to work on (c) for you, but I don't think it's mechanically
> possible under the terms of the governing procedure of the JCP - we'd
> have to approach each expert on the EG for 181 and get them to grant us
> permission, if we wanted to be accurate and complete.
Agreed, this seems difficult especially since the 181 EG seems close to
finishing (they are after all past "Final Approval Ballot") and should
be shipping soon-ish...
Alternate suggestions welcome.
>
>>
>> The purpose of this milestone was to provide incremental progress
>> toward a 1.0-final release of the stable NetUI and Controls parts of
>> Beehive, Then, we'd do a subsequent Beehive release that has JSR 181
>> TCK compliance.
>>
>> So, it seems to me that the passing the TCK and doing a milestone
>> release are orthogonal until we consider doing a release that doesn't
>> include WSM.
>>
>> It would certainly be possible to release a version of Beehive that
>> had only the NetUI + Controls bits and let the WSM part continue to
>> bake until the TCK becomes available and is passed. WSM could then be
>> included in a later release. Thoughts about this are welcome;
>> honestly, I'd be fine with this approach.
>
>
> That works completely. And if you made it so that the WSM part was
> buildable or gettable from a nightly, and then just used w/o any claims
> of completeness or status on your part, then it's probably not an issue
> - it's clear how OSS is developed, and that's just a natural part of
> the process.
>
>
>>
>> But, I do think that we should complete the current milestone
>> release in order to get something new out there.
>
>
> +1
>
> If you are calling this a milestone increment rather than a real "we're
> complete and support this" release, then by all means, throw in the
> JSR-181 stuff. We do this in Apache Geronimom all the time, and it's
> clear that our milestone releases are not J2EE 1.4 compliant.
>
Yeah, I agree with this direction, and once the current release is done
in a couple of days, we'll start exploring this option on beehive-dev@.
No reason to have WSM artificially hold us up.
:)
> geir
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Richard Feit <ri...@bea.com>.
It seems like adding "Incubating" to the name of the release would
prevent this from smelling like official ASF code, or even from smelling
like fully-baked code. I think we're all for that -- our main goal is
to fulfill the requirements for exiting the Incubator, not to languish
there doing non-official releases. Concurrent with that, we hope that
releasing stable code will help us build dev community (along the lines
of what Dan wrote on this thread earlier).
Noel asked earlier:
>You did do http://cvs.apache.org/dist/incubator/beehive/v1.0m1/, so what is
>the "this release" to which you refer?
>
>
>
I just meant whatever "release" we were debating calling an "Official
Release". Eddie suggested in beehive-dev a few days ago that we should
put out a release of NetUI/Controls, so people could try out stable
versions of those two technologies without waiting until WSM can
obtain/pass the JSR181 TCK.
Rich
Cliff Schmidt wrote:
>On 6/8/05, Noel J. Bergman <no...@devtech.com> wrote:
>
>
>>FWIW, versioning schemes such as:
>>
>> M.mQB
>>
>>where M == major, m == minor, Q in [D:Development, A:Alpha, B:Beta,
>>R:Release], and B == Build# encode the release type. I supposed that 1.0m1
>>represents a milestone.
>>
>>In any event, I'm sure that people can come up with some perfectly sane
>>scheme to label. The only thing is that we don't want it to smell like
>>official ASF code until after the project graduates the Incubator.
>>
>>
>
>How about something like:
>Apache {projectname} (Incubating) vM.mQB ?
>
>e.g. "Apache Beehive (Incubating) v1.0R555"
>
>We already require the word "incubating" in the filenames, but things
>like TheServerSide posts wouldn't normally mention this. I'm
>suggesting that the name of the release always include "(Incubating)"
>wherever it is mentioned.
>
>Cliff
>
>---------------------------------------------------------------------
>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: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by Cliff Schmidt <cl...@gmail.com>.
On 6/8/05, Noel J. Bergman <no...@devtech.com> wrote:
> FWIW, versioning schemes such as:
>
> M.mQB
>
> where M == major, m == minor, Q in [D:Development, A:Alpha, B:Beta,
> R:Release], and B == Build# encode the release type. I supposed that 1.0m1
> represents a milestone.
>
> In any event, I'm sure that people can come up with some perfectly sane
> scheme to label. The only thing is that we don't want it to smell like
> official ASF code until after the project graduates the Incubator.
How about something like:
Apache {projectname} (Incubating) vM.mQB ?
e.g. "Apache Beehive (Incubating) v1.0R555"
We already require the word "incubating" in the filenames, but things
like TheServerSide posts wouldn't normally mention this. I'm
suggesting that the name of the release always include "(Incubating)"
wherever it is mentioned.
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Richard Feit wrote:
> I've been a bit hung up on the idea that since Derby has done several
> "official releases" from within the Incubator (e.g., Version 10.0.2.1 at
> http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
> ), Beehive should be able to do the same thing. I think a lot of us
> have been thinking that an "official release" would help to be able to
> express to potential developers that this is a serious project, with
> production-quality code.
Just to clarify, Derby has done one release while in incubation, not
several. We are working on the groundwork for a second release. Given
Noel's recent comments, the download page was changed to 'Incubator
Release'.
I believe releases are a part of developing the community, have to give
something to people so they can find out what itches they have to scratch.
Dan.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
Richard Feit wrote:
> I've been a bit hung up on the idea that since Derby has done several
> "official releases" from within the Incubator (e.g., Version 10.0.2.1 at
> http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
I can appreciate that view. I hadn't noticed the use of the term official
until someone else pointed it out. Apparently, neither had anyone else.
> I understand your points, though, and I think that as an alternative to
> spending more cycles on this release, it would be very healthy for us to
> focus solely on exiting the Incubator.
You did do http://cvs.apache.org/dist/incubator/beehive/v1.0m1/, so what is
the "this release" to which you refer?
FWIW, versioning schemes such as:
M.mQB
where M == major, m == minor, Q in [D:Development, A:Alpha, B:Beta,
R:Release], and B == Build# encode the release type. I supposed that 1.0m1
represents a milestone.
In any event, I'm sure that people can come up with some perfectly sane
scheme to label. The only thing is that we don't want it to smell like
official ASF code until after the project graduates the Incubator.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Richard Feit <ri...@bea.com>.
Thanks Cliff! Getting feedback from you on these issues would be a nice
bonus for us. I think the main thing is that, along the lines of Noel's
comments and advice, if you see anything the Beehive project can do to
better apply ASF principles, it would be great for us to hear it. This
kind of feedback, both public and private, really helps us.
Thanks,
Rich
Cliff Schmidt wrote:
>On 6/11/05, Noel J. Bergman <no...@devtech.com> wrote:
>
>
>>Richard Feit wrote:
>>
>>
>>>This is just a case where we need all the input we can get.
>>>
>>>
>>We'll see if we can get some additional mentoring for you. I believe that
>>we'll have another volunteer to also spend time helping beehive along. :-)
>>
>>
>
>I can volunteer to me an additional mentor if you guys would like to use me.
>
>Cliff
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
(ignore the spam below :) )
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Rich Feit <ri...@gmail.com>.
Thanks Cliff! Getting feedback from you on these issues would be a nice
bonus for us. I think the main thing is that, along the lines of Noel's
comments and advice, if you see anything the Beehive project can do to
better apply ASF principles, it would be great for us to hear it. This
kind of feedback, both public and private, really helps us.
Thanks,
Rich
Cliff Schmidt wrote:
>On 6/11/05, Noel J. Bergman <no...@devtech.com> wrote:
>
>
>>Richard Feit wrote:
>>
>>
>>>This is just a case where we need all the input we can get.
>>>
>>>
>>We'll see if we can get some additional mentoring for you. I believe that
>>we'll have another volunteer to also spend time helping beehive along. :-)
>>
>>
>
>I can volunteer to me an additional mentor if you guys would like to use me.
>
>Cliff
>
>---------------------------------------------------------------------
>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: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by Cliff Schmidt <cl...@gmail.com>.
On 6/11/05, Noel J. Bergman <no...@devtech.com> wrote:
> Richard Feit wrote:
> > This is just a case where we need all the input we can get.
>
> We'll see if we can get some additional mentoring for you. I believe that
> we'll have another volunteer to also spend time helping beehive along. :-)
I can volunteer to me an additional mentor if you guys would like to use me.
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
Richard Feit wrote:
> > > we need all the guidance we can get in achieving that.
> >
> > How has it been going? Have you had input from the project Mentor(s)?
>
> Definitely. Craig (McClanahan) has chimed in publicly and privately,
> with both solicited and unsolicited advice. He's been great about
> letting us know what smells bad (e.g., the idea of moving all bug
> traffic off of beehive-dev).
I'm glad to hear it. :-)
> This is just a case where we need all the input we can get.
We'll see if we can get some additional mentoring for you. I believe that
we'll have another volunteer to also spend time helping beehive along. :-)
> We've discussed the fact that there's not enough activity in the list,
> and that too much of our dev traffic is in JIRA.
> It feels like we're in a cycle that started with ambiguous use
> of beehive-dev, is now in a phase where there's a lot of
> traffic about process/infrastructure/planning, and is moving
> into the realm of design/architecture/integration.
One cannot address what one doesn't perceive, so these sound like good
steps. :-)
> > Incubation isn't a set of hurdles to clear; it is a process
> > to (attempt to) ensure that projects have clean IP and a
> > healthy community that follows ASF principles.
>
> It's good for us to remember that. :)
:-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Richard Feit <ri...@bea.com>.
Noel J. Bergman wrote:
>Richard Feit wrote:
>
>
>
>>it would be very healthy for us to focus solely on exiting
>>the Incubator. We are totally committed to building a real
>>dev community around Beehive
>>
>>
>
>Neither of those was in doubt. :-)
>
>
>
>>we need all the guidance we can get in achieving that.
>>
>>
>
>How has it been going? Have you had input from the project Mentor(s)?
>
>
>
Definitely. Craig (McClanahan) has chimed in publicly and privately,
with both solicited and unsolicited advice. He's been great about
letting us know what smells bad (e.g., the idea of moving all bug
traffic off of beehive-dev). This is just a case where we need all the
input we can get.
>>the main issue that I'm aware of is an insufficient amount of
>>discussion on the beehive-dev list.
>>
>>
>
>Does the PPMC concur with that, or are you simply acknowledging my
>perception?
>
>
>
My impression is that we have the same perception across the board.
We've discussed the fact that there's not enough activity in the list,
and that too much of our dev traffic is in JIRA. I think we're finally
seeing beehive-dev pick up steam (even excluding JIRA/build mail,
there's been almost as much list activity in the first week of June as
there was in all of May). It feels like we're in a cycle that started
with ambiguous use of beehive-dev, is now in a phase where there's a lot
of traffic about process/infrastructure/planning, and is moving into the
realm of design/architecture/integration.
>>we clearly need to have more design/discussion in the list
>>(and, incidentally, less of it within JIRA issues). I
>>feel that this is something we can address.
>>
>>
>
>:-)
>
>
>
>>Beyond this major issue, do you feel that there are other hurdles
>>for us to clear before exiting the Incubator?
>>
>>
>
>When we seem more discussion on the list, we'll all have a better idea of
>how well the core principles of the ASF are being applied. After all,
>Incubation isn't a set of hurdles to clear; it is a process to (attempt to)
>ensure that projects have clean IP and a healthy community that follows ASF
>principles.
>
>
>
It's good for us to remember that. :) If you see anything that makes
you think we're not on the right path, please let us know. Otherwise, I
think we know where to focus for now, and I'm sure Craig will keep us in
line. Thanks for all the feedback.
Rich
> --- Noel
>
>
>---------------------------------------------------------------------
>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: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
Richard Feit wrote:
> it would be very healthy for us to focus solely on exiting
> the Incubator. We are totally committed to building a real
> dev community around Beehive
Neither of those was in doubt. :-)
> we need all the guidance we can get in achieving that.
How has it been going? Have you had input from the project Mentor(s)?
> the main issue that I'm aware of is an insufficient amount of
> discussion on the beehive-dev list.
Does the PPMC concur with that, or are you simply acknowledging my
perception?
> we clearly need to have more design/discussion in the list
> (and, incidentally, less of it within JIRA issues). I
> feel that this is something we can address.
:-)
> Beyond this major issue, do you feel that there are other hurdles
> for us to clear before exiting the Incubator?
When we seem more discussion on the list, we'll all have a better idea of
how well the core principles of the ASF are being applied. After all,
Incubation isn't a set of hurdles to clear; it is a process to (attempt to)
ensure that projects have clean IP and a healthy community that follows ASF
principles.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Richard Feit <ri...@bea.com>.
I've been a bit hung up on the idea that since Derby has done several
"official releases" from within the Incubator (e.g., Version 10.0.2.1 at
http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
), Beehive should be able to do the same thing. I think a lot of us
have been thinking that an "official release" would help to be able to
express to potential developers that this is a serious project, with
production-quality code.
I understand your points, though, and I think that as an alternative to
spending more cycles on this release, it would be very healthy for us to
focus solely on exiting the Incubator. We are totally committed to
building a real dev community around Beehive, and we need all the
guidance we can get in achieving that. From reading the Minimum Exit
Requirements, and from comments you've made in other threads, the main
issue that I'm aware of is an insufficient amount of discussion on the
beehive-dev list. I believe that this was at least partially due to the
state of the project as it entered the Incubator; most of the features
had been designed already. This may be why the beehive-user community
is more diverse than the community on beehive-dev. But we clearly need
to have more design/discussion in the list (and, incidentally, less of
it within JIRA issues). I feel that this is something we can address.
Beyond this major issue, do you feel that there are other hurdles for us
to clear before exiting the Incubator?
Thanks,
Rich
Noel J. Bergman wrote:
>Cliff Schmidt wrote:
>
>
>
>>Noel J. Bergman wrote:
>>
>>
>>>>It just doesn't make sense to me to tell a community that believes it
>>>>
>>>>
>has
>
>
>>>>a "1.0" quality product that they have to call it a "test snapshot".
>>>>
>>>>
>>>Demo? Technology preview? Milestone? Happy Meal?
>>>
>>>
>>If we are keeping a project in incubation until its community is of
>>higher quality, why would we legislate terms that have to do with code?
>>
>>
>
>You did notice the "Happy Meal" quip, right? If people want to try to come
>up with a satisfactory label, fine. I'm curious.
>
>
>
>>>it is entirely intentional and deliberate that projects in the Incubator
>>>
>>>
>are
>
>
>>>not permitted to make anything that smells like an official release.
>>>
>>>
>
>
>
>>I agree that they should not be permitted to make anything that
>>resembles an official *ASF-endorsed* released.
>>
>>
>
>
>
>>I am trying to separate code quality labels from branding.
>>
>>
>
>
>
>>I just don't see what that has to do with letting a project
>>indicate to its users what degree of stability their code
>>base is at or whether they expect to maintain backward
>>compatibility on their APIs
>>
>>
>
>When users hear about a release, they assume a lot more than code quality.
>Just as when they hear that a product reaches EOL, all of a sudden the
>product sucks. In fact, there was an interesting thread on JAMES today:
>
> http://mail-archives.apache.org/mod_mbox/james-server-user/200506.mbox/%3c
>1118153023.7707.14.camel@localhost.localdomain%3e
>
>The end-user observed that "[the] initial impression we got was that Avalon
>was so poorly designed or executed that it was closed due to embarrassment
>or total frustration of the participating developers", when code quality had
>nothing to do with the project's closure.
>
>
>
>>(often signalled by the "1.0" milestone).
>>
>>
>
>Unless it is a Microsoft product, in which case don't touch it before 3.1.
>;-)
>
> --- Noel
>
>
>---------------------------------------------------------------------
>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: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
Cliff Schmidt wrote:
> Noel J. Bergman wrote:
>>> It just doesn't make sense to me to tell a community that believes it
has
>>> a "1.0" quality product that they have to call it a "test snapshot".
>>
>> Demo? Technology preview? Milestone? Happy Meal?
>
> If we are keeping a project in incubation until its community is of
> higher quality, why would we legislate terms that have to do with code?
You did notice the "Happy Meal" quip, right? If people want to try to come
up with a satisfactory label, fine. I'm curious.
> > it is entirely intentional and deliberate that projects in the Incubator
are
> > not permitted to make anything that smells like an official release.
> I agree that they should not be permitted to make anything that
> resembles an official *ASF-endorsed* released.
> I am trying to separate code quality labels from branding.
> I just don't see what that has to do with letting a project
> indicate to its users what degree of stability their code
> base is at or whether they expect to maintain backward
> compatibility on their APIs
When users hear about a release, they assume a lot more than code quality.
Just as when they hear that a product reaches EOL, all of a sudden the
product sucks. In fact, there was an interesting thread on JAMES today:
http://mail-archives.apache.org/mod_mbox/james-server-user/200506.mbox/%3c
1118153023.7707.14.camel@localhost.localdomain%3e
The end-user observed that "[the] initial impression we got was that Avalon
was so poorly designed or executed that it was closed due to embarrassment
or total frustration of the participating developers", when code quality had
nothing to do with the project's closure.
> (often signalled by the "1.0" milestone).
Unless it is a Microsoft product, in which case don't touch it before 3.1.
;-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by Cliff Schmidt <cl...@gmail.com>.
On 6/7/05, Noel J. Bergman <no...@devtech.com> wrote:
>> It just doesn't make sense to me to tell a community that believes it has
>> a "1.0" quality product that they have to call it a "test snapshot".
>
> Demo? Technology preview? Milestone? Happy Meal?
All of those terms (or at least the first three ;-) are references to
code quality. If we are keeping a project in incubation until its
community is of higher quality, why would we legislate terms that have
to do with code?
> Look, maybe this is hard to understand, especially if people are coming from
> an enviroment focused on code quality first, but this isn't about the state
> of the code. It is about the state of the community.
As I said in my prior post, I think we all agree on this -- this
shouldn't be hard for anyone to understand.
> We had a lot of long
> discussions regarding allowing any releases at all from the Incubator, and
> it is entirely intentional and deliberate that projects in the Incubator are
> not permitted to make anything that smells like an official release.
I agree that they should not be permitted to make anything that
resembles an official *ASF-endorsed* released.
<snip/>
> Nor we we want projects to be overly comfortable with a nice long stay. We
> want projects to be serious about getting out of the Incubator from the time
> that they get into it. If this were to mean that projects would start to
> put more emphasis on commmunity development than on their code "just" so
> that they can get out of the Incubator and make releases ... EXACTLY!
I'd be surprised if any individual or company was comfortable having
to include the word "incubating" as part of every filename in their
release, nor comfortable having a paragraph in their README stating
that the project is not officially endorsed by the ASF, nor
comfortable being required by our PRC to mention incubation in any
PR-like materials. I think all these are all good and effective
restrictions.
> Again, our emphasis is on a healthy developer communities that can be relied
> upon to be self-sustaining and follow ASF practices for many years.
You and I completely agree on this. However, I am trying to separate
code quality labels from branding. We all agree that incubation is
about building community -- until a project as reached the goals
around community development, we want to distinguish the project by
requiring the incubator branding -- not the full ASF branding. I just
don't see what that has to do with letting a project indicate to its
users what degree of stability their code base is at or whether they
expect to maintain backward compatibility on their APIs (often
signalled by the "1.0" milestone).
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by Erik Abele <er...@codefaktor.de>.
On 07.06.2005, at 22:48, Noel J. Bergman wrote:
> Demo? Technology preview? Milestone? Happy Meal?
>
> Look, maybe this is hard to understand, especially if people are
> coming from
> an enviroment focused on code quality first, but this isn't about
> the state
> of the code. It is about the state of the community. We had a lot
> of long
> discussions regarding allowing any releases at all from the
> Incubator, and
> it is entirely intentional and deliberate that projects in the
> Incubator are
> not permitted to make anything that smells like an official
> release. The
> fact that they can make any release at all is out of recognition
> that some
> limited releases may help with community growth, but it also
> remains that we
> do not want users to depend on projects that are still in the
> Incubator.
> Now that may seem a self-contradictory statement, but the community
> we want
> focused on are other developers, not users.
>
> Nor we we want projects to be overly comfortable with a nice long
> stay. We
> want projects to be serious about getting out of the Incubator from
> the time
> that they get into it. If this were to mean that projects would
> start to
> put more emphasis on commmunity development than on their code
> "just" so
> that they can get out of the Incubator and make releases ... EXACTLY!
>
> Again, our emphasis is on a healthy developer communities that can
> be relied
> upon to be self-sustaining and follow ASF practices for many years.
Amen - can someone with karma for the incubator site please add this
to the relevant section? I think this sums it up pretty nicely.
Just my 2c...
Cheers,
Erik
RE: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
Cliff Schmidt wrote:
> Daniel John Debrunner wrote:
> >
http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+R
equirements
> > Note: incubator projects are not permitted to issue an official
Release.
> > Test snapshots (however good the quality) and Release plans are OK.
> > Maybe it should be removed? It does tend to contradict the bullet
> > it is under. :-)
>
> Good catch, Dan! I would certainly be in favor of removing this line.
-1 from me. And I'll elaborate further ...
> It just doesn't make sense to me to tell a community that believes it has
> a "1.0" quality product that they have to call it a "test snapshot".
Demo? Technology preview? Milestone? Happy Meal?
Look, maybe this is hard to understand, especially if people are coming from
an enviroment focused on code quality first, but this isn't about the state
of the code. It is about the state of the community. We had a lot of long
discussions regarding allowing any releases at all from the Incubator, and
it is entirely intentional and deliberate that projects in the Incubator are
not permitted to make anything that smells like an official release. The
fact that they can make any release at all is out of recognition that some
limited releases may help with community growth, but it also remains that we
do not want users to depend on projects that are still in the Incubator.
Now that may seem a self-contradictory statement, but the community we want
focused on are other developers, not users.
Nor we we want projects to be overly comfortable with a nice long stay. We
want projects to be serious about getting out of the Incubator from the time
that they get into it. If this were to mean that projects would start to
put more emphasis on commmunity development than on their code "just" so
that they can get out of the Incubator and make releases ... EXACTLY!
Again, our emphasis is on a healthy developer communities that can be relied
upon to be self-sustaining and follow ASF practices for many years.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by Cliff Schmidt <cl...@gmail.com>.
On 6/7/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements
>
> <quote>
> Note: incubator projects are not permitted to issue an official Release.
> Test snapshots (however good the quality) and Release plans are OK.
> </quote>
>
> Maybe it should be removed? It does tend to contradict the bullet it is
> under. :-)
Good catch, Dan! I would certainly be in favor of removing this line.
I know there are different opinions on this within the PMC, but most
would agree that incubation has nothing to do with the technical
quality of the code. It just doesn't make sense to me to tell a
community that believes it has a "1.0" quality product that they have
to call it a "test snapshot". Instead we specify several
branding-related requirements to ensure the project doesn't yet claim
to be an officially-endorse ASF project.
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Cliff Schmidt wrote:
> Here is my opinion on the whole release issue, which has not changed
> in 18 months since the first big discussion of releases and incubation
> branding.
[snip]
Maybe folks are confused by this sentence in the 'Minimum Exit
Requirements' section.
http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements
<quote>
Note: incubator projects are not permitted to issue an official Release.
Test snapshots (however good the quality) and Release plans are OK.
</quote>
Maybe it should be removed? It does tend to contradict the bullet it is
under. :-)
Dan.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by Cliff Schmidt <cl...@gmail.com>.
Here is my opinion on the whole release issue, which has not changed
in 18 months since the first big discussion of releases and incubation
branding.
Full Disclosure: While this is my opinion as a member of the
Incubator PMC, it is not necessarily the consensus of the PMC. In
addition, I was once a BEA employee and am still a (recently inactive)
committer on the beehive project; however, I have been consistent in
my views on this issue regardless of what individual/company/project
has raised the issue.
Given (my assumptions):
1. (binary) releases are useful in building interest in a project,
which often leads to a stronger community; also, the process of doing
a release is useful for a project to go through while in incubation.
2. while in incubation (when a project is still trying to reach its
goals for a diverse, collaborative, meritocratic-based community),
Apache does not want a project to claim that it is a fully-endorsed
Apache project
3. incubation status is no reflection on the technical quality or
maturity of the code base
Therefore:
1. releases should be allowed and even encouraged while incubation
(personally, I don't care whether they're called "releases",
"Releases", or "official project release".
2. projects should a) include obvious notices regarding their
incubation status and the status of their releases (e.g. in the README
file, as part of the file name, and on their web site), b) hold a
vote of their ppmc (which should include interested members of the
Incubator PMC), and c) should ensure their mentor approves of the
release and its process.
3. projects within incubation should not be given some arbitrary
technical boundary, such as preventing them from classifying a release
as "1.0" or "2.0", based on the history and stability of the code
base.
Guess what? When we (this list) spend literally hundreds of emails
discussing these issues in late 2003, we came up with a lose set of
guidelines that pretty much fit with what is described above. See
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0D.
Note there is nothing in there that states a release can't be called
"official" or "1.0" or anything like that. Howeverm, it must meet the
branding guidelines.
I suggest those who disagree with these written guidelines suggest
changes to them to be discussed and voted upon; otherwise, existing
projects today should follow the only documentation we have given
them.
(ready for the inevitable flames to begin, possibly from some folks I
have a lot of respect for...)
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by Eddie ONeil <ek...@gmail.com>.
CIL...
> > If I'm messing up terminology
>
> Oh, the terminology got messed up long ago. LOL :-) Even the term
> "Release" has different connotations. It is neutral in the HTTP Server
> project (beta and GA releases, for example), whereas Jakarta refers to
> Nightly builds, Milestone builds and Release builds, so a Release is
> significant.
Sometimes, it's even the case that a milestone == a release. :)
>
> We are trying to balance the need to support community development with the
> idea that projects in the incubator shouldn't confuse the public over their
> status by claiming the Apache imprimatur.
>
And, I support and am not at all trying to undermine that goal in any way. :)
I would like to see Beehive deliver to potential users a package that
includes bits we deem complete and for which we guarantee backwards
compatibility. To me, it seems that calling something "Official"
relative to Beehive is orthogonal to its incubation status. We
believe that a set of bits are ready to go, though they clearly
originated from an incubating project (thus the location of the web
site, the appropriate notice, and the adjective "incubating" in the
package names) with no claim made to the contrary. One way to convey
this is by using the "official" adjective, as Derby has done.
The benefit for Beehive is (I believe) that official-ness (again,
relative to the state of code) attracts users and thus contributors
since such a release appears to the observer more complete. The
notion of completeness is harder to convey in a "milestone".
Another thing that helps is being able to call something 1.0 (or 3.0,
etc) as appropriate. Are there guidelines for how version numbering
works in Incubator? Or is this left to the discretion of the project?
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
Eddie O'Neil wrote:
> I've heard a couple of times that it's not possible to do a -final
> release from the Incubator, but I've also heard some suggest that
> it could be possible.
It should not be done, by definition of being in the Incubator.
> Didn't Derby do one of these in December 2004 as per:
> http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
"Official" or "Final" are probably not adjectives that should be applied
during incubation.
> If I'm messing up terminology
Oh, the terminology got messed up long ago. LOL :-) Even the term
"Release" has different connotations. It is neutral in the HTTP Server
project (beta and GA releases, for example), whereas Jakarta refers to
Nightly builds, Milestone builds and Release builds, so a Release is
significant.
We are trying to balance the need to support community development with the
idea that projects in the incubator shouldn't confuse the public over their
status by claiming the Apache imprimatur.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: releasing from incubator? -- was: Re: a beehive release and the
JSR 181 TCK issue
Posted by Eddie O'Neil <ek...@bea.com>.
CIL...
Leo Simons wrote:
> On 31-05-2005 03:51, "Eddie O'Neil" <ek...@bea.com> wrote:
>
>> I've heard a couple of times that it's not possible to do a -final
>>release from the Incubator, but I've also heard some suggest that it
>>could be possible.
>
>
> Nope.
Okay, so I take it there's a difference between an "Official Release"
and a "-final" release? Is an "Official Release" just something that a
project can call itself but doesn't mean anything specific in Apache
parlance?
Just learning...apologies for the naivety.
>
>
>> Didn't Derby do one of these in December 2004 as per:
>>
>>http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
>
>
> Nope. AFAICT They followed
>
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0D
>
> Correctly.
Agreed! I didn't see anything there that would imply otherwise and
wasn't at all trying to suggest that there was. Thanks for the
clarification.
Eddie
>
> Cheers!
>
> Leo
>
>
>
> ---------------------------------------------------------------------
> 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: releasing from incubator? -- was: Re: a beehive release and
the JSR 181 TCK issue
Posted by Leo Simons <ma...@leosimons.com>.
On 31-05-2005 03:51, "Eddie O'Neil" <ek...@bea.com> wrote:
> I've heard a couple of times that it's not possible to do a -final
> release from the Incubator, but I've also heard some suggest that it
> could be possible.
Nope.
> Didn't Derby do one of these in December 2004 as per:
>
> http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
Nope. AFAICT They followed
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0D
Correctly.
Cheers!
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
releasing from incubator? -- was: Re: a beehive release and the JSR
181 TCK issue
Posted by Eddie O'Neil <ek...@bea.com>.
Noel--
I've heard a couple of times that it's not possible to do a -final
release from the Incubator, but I've also heard some suggest that it
could be possible.
Didn't Derby do one of these in December 2004 as per:
http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
If I'm messing up terminology or trying to re-open a closed
discussion, please let me know.
:)
Eddie
Noel J. Bergman wrote:
> Geir wrote:
>
>>Eddie ONeil wrote:
>>
>>>I do think that we should complete the current milestone
>>>release in order to get something new out there.
>
>
>>If you are calling this a milestone increment rather than a real
>>"we're complete and support this" release
>
>
> Which they have to do anyway, since Beehive is still in the Incubator. We
> don't do final releases.
>
> So I believe that you have given them a route to a milestone release.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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: a beehive release and the JSR 181 TCK issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
Geir wrote:
> Eddie ONeil wrote:
> > I do think that we should complete the current milestone
> > release in order to get something new out there.
> If you are calling this a milestone increment rather than a real
> "we're complete and support this" release
Which they have to do anyway, since Beehive is still in the Incubator. We
don't do final releases.
So I believe that you have given them a route to a milestone release.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: a beehive release and the JSR 181 TCK issue
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 29, 2005, at 8:21 AM, Eddie ONeil wrote:
> All--
>
> There has been some confusion publicly and privately about the JSR
> 181 TCK issues and the WSM part of Beehive.
>
> The goals of WSM are to implement the JSR 181 specification and to
> provide a generic annotation processor for the 181 annotations. In
> addition, there is a layer that implements JSR 181 features for the
> Axis web service stack.
>
> The JSR 181 specification is being developed under the JCP 2.6
> process and has reached the "Final Approval Ballot" stage. But, this
> is not the *final* release of the specification. This means that the
> spec is not completely finished and that the RI and TCK are not
> available.
>
> Both Craig and Geir have confirmed that in order to ship a "final"
> version of Beehive that claims to implement JSR 181, we must pass the
> JSR 181 TCK. Currently, we are blocked on even starting this work
> because the TCK has not been released. I've exchanged some mail with
> Geir, and once the TCK is available, he will help us obtain it through
> Apache channels and we can start the process of passing the TCK. The
> TCK work will be done at Apache under NDA.
>
> The implication here is that Beehive (NetUI + Controls + WSM) can
> not go "final" as a whole until the TCK has been released and WSM has
> passed.
Well, where there's a will...
what are you implementing now? A pre-final spec that's public?
Right now, we have the awful situation in the JCP that any pre-final
spec isn't licensed for implementation. However, Oracle, JBoss and
Hibernate are shipping
example implementations of the EJB3 public draft (which I think is a
good thing in terms of getting implementations out for people to play
with...)
However, that's not really permitted, and quite frankly,
theoretically dangerous because any IP contributed to the spec by the
expert group experts has not been licensed for use in the spec - that
only happens when the spec is final, and the spec lead is granted
right to license the IP for compatible implementations.
So the question here is "what do we do?"
We can
a) just do it and violate the license (I'm not for that)
b) wait until the TCK is complete (that works, but holds you up)
c) try to find some permission.
I'm happy to work on (c) for you, but I don't think it's mechanically
possible under the terms of the governing procedure of the JCP - we'd
have to approach each expert on the EG for 181 and get them to grant
us permission, if we wanted to be accurate and complete.
>
> The purpose of this milestone was to provide incremental progress
> toward a 1.0-final release of the stable NetUI and Controls parts of
> Beehive, Then, we'd do a subsequent Beehive release that has JSR 181
> TCK compliance.
>
> So, it seems to me that the passing the TCK and doing a milestone
> release are orthogonal until we consider doing a release that doesn't
> include WSM.
>
> It would certainly be possible to release a version of Beehive that
> had only the NetUI + Controls bits and let the WSM part continue to
> bake until the TCK becomes available and is passed. WSM could then be
> included in a later release. Thoughts about this are welcome;
> honestly, I'd be fine with this approach.
That works completely. And if you made it so that the WSM part was
buildable or gettable from a nightly, and then just used w/o any
claims of completeness or status on your part, then it's probably not
an issue - it's clear how OSS is developed, and that's just a natural
part of the process.
>
> But, I do think that we should complete the current milestone
> release in order to get something new out there.
+1
If you are calling this a milestone increment rather than a real
"we're complete and support this" release, then by all means, throw
in the JSR-181 stuff. We do this in Apache Geronimom all the time,
and it's clear that our milestone releases are not J2EE 1.4 compliant.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org