RE: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Biological Object Model Project
Hi, James Carman wrote: I would like to start a biological object model process (I need to come up with a catchier name) and I think ASF would be a great place for it. Have you looked at the Open Bioinformatics Foundation (http://www.open-bio.org/)? They are not ASF, but they have a working, actively used and evolving codebase that already forms a de-facto standard platform for open source bioinformatics. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Biological Object Model Project
>From what I understand, the BioJava project doesn't really provide persistence for biological objects, which is something that I would want in a model/platform. My idea is to use something like Hibernate or JDO to actually persist the data. Also, the last "recent update" for BioJava was from May 2004. I would think that a platform should allow you to store your objects into a persistent storage mechanism (RDBMS). Once you have a persistable model in place, then you write utilities which can operate on it. Granted, I haven't used BioJava that much. I'm just going by what I see from the JavaDocs and I could be very wrong. -Original Message- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 2:10 AM To: general@incubator.apache.org Subject: Re: Biological Object Model Project Hi, James Carman wrote: > I would like to start a biological object model process (I need to come up > with a catchier name) and I think ASF would be a great place for it. Have you looked at the Open Bioinformatics Foundation (http://www.open-bio.org/)? They are not ASF, but they have a working, actively used and evolving codebase that already forms a de-facto standard platform for open source bioinformatics. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
On 6/8/05, Noel J. Bergman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Biological Object Model Project
IMO its a great idea (assuming nothing like that exists) but how can ASF help you given that the incubator is meant to bring in existing projects with working code rather than ideas? Sanjiva. On Tue, 2005-06-07 at 18:35 -0400, James Carman wrote: > All, > > > > I would like to start a biological object model process (I need to come up > with a catchier name) and I think ASF would be a great place for it. I > currently work with a product called GKP (Genomics Knowledge Platform) from > a company called Xteric and it works fairly well, but it is not open source. > It's tough to get grant money from the government for software development > if you're using something that's proprietary and not open source. You can't > exactly tell a university that they have to spend $1M on a software package > if they wish to use it for research. Anyway, what is needed in the > Genomics/Bioinformatics world is a common, standardized, open source object > model for us to develop applications against. I understand that I'm > supposed to have a working codebase, but this is still a vision for me. > However, if we started a project, I think we could get some real experts > (bioinformaticians) to contribute and work towards developing a standard > platform. Any thoughts? > > > > James Carman > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Biological Object Model Project
Sanjiva, I'm glad you like the idea. I think there is a need for something like this in the bioinformatics community. Well, I could start modeling some classes that I'm somewhat familiar with. Unfortunately, though, I'm not a bioinformatician, so I'm not exactly the person who should be doing the actual domain modeling. What I (and many others at ASF) can bring to the table is the infrastructure which allows the objects to be stored/retrieved. Maybe I could try to recruit some help from some domain experts (bioinformaticians) to start developing the model. Then, we could bring some subset of the finished product in as an ASF incubator project. How does that sound? I was really just wanting to figure out if ASF would be willing to host a project such as this one. James -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 7:19 PM To: general@incubator.apache.org Subject: Re: Biological Object Model Project IMO its a great idea (assuming nothing like that exists) but how can ASF help you given that the incubator is meant to bring in existing projects with working code rather than ideas? Sanjiva. On Tue, 2005-06-07 at 18:35 -0400, James Carman wrote: > All, > > > > I would like to start a biological object model process (I need to come up > with a catchier name) and I think ASF would be a great place for it. I > currently work with a product called GKP (Genomics Knowledge Platform) from > a company called Xteric and it works fairly well, but it is not open source. > It's tough to get grant money from the government for software development > if you're using something that's proprietary and not open source. You can't > exactly tell a university that they have to spend $1M on a software package > if they wish to use it for research. Anyway, what is needed in the > Genomics/Bioinformatics world is a common, standardized, open source object > model for us to develop applications against. I understand that I'm > supposed to have a working codebase, but this is still a vision for me. > However, if we started a project, I think we could get some real experts > (bioinformaticians) to contribute and work towards developing a standard > platform. Any thoughts? > > > > James Carman > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STATUS] (incubator) Wed Jun 8 23:46:31 2005
APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*-
Last modified at [$Date: 2005-01-20 01:12:13 -0500 (Thu, 20 Jan 2005) $]
Web site: http://Incubator.Apache.Org/
Wiki page: http://wiki.apache.org/incubator/
[note: the Web site is the 'official' documentation; the wiki pages
are for collaborative development, including stuff destined for the
Web site.]
Pending Issues
==
o Clearly and authoritatively document how to edit, generate,
and update the Web site (three separate functions).
o Move the stable wiki pages into the official site.
o We need to be very very clear about what it takes to be accepted
into the incubator. It should be a very low bar to leap, possibly
not much more than 'no problematic code' and the existence of a
healthy community (we don't want to become a dumping ground).
o We need to be very very clear about what it takes for a podling
to graduate from the incubator. The basic requirements obviously
include: has a home, either as part of another ASF project or as
a new top-level project of its own; needs to be a credit to the
ASF and function well in the ASF framework; ...
o Moving the bylaw documentation from the Wiki to the main site
o fix formatting of the project status pages
Resolved Issues
===
o The policy documentation does not need ratification of changes
if there seems consensus. Accordingly, the draft status of these
documents can be removed and we will use the lazy "commit first,
discuss later" mode common across the ASF for documentation
(http://mail-archives.apache.org/eyebrowse/[EMAIL
PROTECTED]&by=thread&from=517190)
o Coming up with a set of bylaws for the project
(http://mail-archives.apache.org/eyebrowse/[EMAIL
PROTECTED]&by=thread&from=517190)
o All projects under incubation must use a STATUS file (or a
status.xml file if the project prefers XML) that contains
information the PMC needs about the project. This file must
live at the root of the project cvs module
(http://mail-archives.apache.org/eyebrowse/[EMAIL
PROTECTED]&by=thread&from=504543)
o Projects under incubation should display appropriate "disclaimers"
so that it is clear that they are, indeed, under incubation
(http://mail-archives.apache.org/eyebrowse/[EMAIL
PROTECTED]&by=thread&from=504543)
The Incubation Process
==
This tries to list all the actions items that must be complete for a project
before it can graduate from the incubator. It is probably incomplete.
Identify the project to be incubated:
-- Make sure that the requested project name does not already exist
and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
-- If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
-- If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
-- If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
Interim responsibility:
-- Who has been identified as the mentor for the incubation?
-- Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
Copyright:
-- Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
-- Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
-- For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
-- Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
Establish a list of active committers:
-- Are all active committers in the STATUS file?
-- Do they have accounts on cvs.apache.org?
-- Have they submitted a contributors agreement?
Infrastructure:
-- CVS modules created and committers added to avail file?
-- Mailing lists set up and archived?
-- Problem tracking system (Bugzilla)?
-- Has the project migrated to our infrastructure?
Collaborative Development:
-- Have all of the active long-term volunteers been identified
and acknowledged as committers on the project?
-- Are there three or more independent committers?
[The legal definition of independent is long and boring, but basically
it means that there is no binding relationship be
