Re: Getting the distribution onto a download site somewhere ...
On 9/24/2003 12:10 AM, [EMAIL PROTECTED] wrote: We are trying to get there you know. If at any point you want to help, just let me know. I wasn't trying to say that you weren't working on it, just trying to point out that some people consider Releases important. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Rodent of Unusual Size wrote: Cliff Schmidt wrote: snipped-release-plan/ this sounds to me like a very good plan. thank you! +1 :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Jochen Wiedmann wrote: Noel J. Bergman wrote: I am not on the Incubator PMC, but I feel that a project still bearing incubator status should not be permitted to make a Release. I do not know what exactly you define as a release. Is that more than a distribution? An incubator project is expected to build a community. I doubt it can do so from the CVS only: That would put the entry level for new users too high. Agreed. Some Apache projects satisfy this need by making nightly builds available for download. I don't know how this works in the incubator, but setting up a nightly build process and making the nightlies available for download could satisfy this need. Phil Jochen - 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: Getting the distribution onto a download site somewhere ...
Jochen Wiedmann wrote: Noel J. Bergman wrote: I am not on the Incubator PMC, but I feel that a project still bearing incubator status should not be permitted to make a Release. I do not know what exactly you define as a release. Is that more than a distribution? Capital R. A Release build is a specific notion within the ASF. Not all builds are created equal, and no one was talking about distribution from CVS only. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting the distribution onto a download site somewhere ...
Capital R. A Release build is a specific notion within the ASF. Not all builds are created equal, and no one was talking about distribution from CVS only. Would you mind to explain me what the specific notion means? See http://httpd.apache.org/dev/release.html for the httpd project's guidelines. They use the term release the way that Jakarta projects will use the term build, but the overall effect is the same. See http://jakarta.apache.org/site/binindex.cgi for a description of the guidelines used by Jakarta and related projects. Basically the terminology maps, except that httpd calls things a release and Jakarta calls them a build. So, roughly speaking, you might look at it as: httpd Jakarta - --- Nightly build (automated, might not compile) alpha release beta release Milestone build GA releaseRelease build That is why I make sure to write Release with a capital 'R' when referring to a Release build. These are just guidelines. For example, the Apache James project hasn't been putting out nightly builds, but we do put out test builds that are not considered milestones. Those would be more like an alpha release in httpd project terms. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Noel J. Bergman wrote: See http://httpd.apache.org/dev/release.html for the httpd project's guidelines. They use the term release the way that Jakarta projects will use the term build, but the overall effect is the same. See http://jakarta.apache.org/site/binindex.cgi for a description of the guidelines used by Jakarta and related projects. Thanks, understood. In that case, I'd hold my argument, that the incubated project requires the ability for Releases in order to attract external users and build a community. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Jochen Wiedmann wrote: Thanks, understood. In that case, I'd hold my argument, that the incubated project requires the ability for Releases in order to attract external users and build a community. i disagree. the lack of a release snapshot doesn't seem to interfere with sourceforge projects attracting people, and i don't see that it would be any different here. i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Rodent of Unusual Size wrote: i disagree. the lack of a release snapshot doesn't seem to interfere with sourceforge projects attracting people, and i don't see that it would be any different here. The lack of release snapshots on sf.net is (IMO) the best indicator, that the project isn't maintained well or even not at all. At least I cannot remember a single case of a project without published files, where the CVS did contain something useful. i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. There are several things I do not understand here. First of all, IMO, by accepting a project for incubation, it is part of the ASF. For whatever other reason am I expected to sign a contribution agreement at the beginning? From your point of view, it would be suffigient to sign when the project exits incubation. Next, assuming that my point is wrong, I would assume that incubation is targetted to be a process of transition. Which means, that a project is at some point perhaps not completely ready, but with a sufficient progress. What good does it, to insist in the final 20 percent or whatever you are missing? Finally, you should not forget that incubated projects are frequently mature and well maintained. What good does it, to forbid them to publish, for example, a release that is identical to the last public release, except that the package names are being updated. IMO this is the least what users can expect to guide them in their own transition as soon as possible. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Jochen Wiedmann wrote: i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. There are several things I do not understand here. First of all, IMO, by accepting a project for incubation, it is part of the ASF. no, it is a *candidate to become* part of the asf. if it fails to exit the incubator, for whatever reason, it doesn't wander off into the sunset bearing the asf name with it. :-) For whatever other reason am I expected to sign a contribution agreement at the beginning? From your point of view, it would be suffigient to sign when the project exits incubation. because the code is being stored on asf infrastructure, among other things. Next, assuming that my point is wrong, I would assume that incubation is targetted to be a process of transition. Which means, that a project is at some point perhaps not completely ready, but with a sufficient progress. What good does it, to insist in the final 20 percent or whatever you are missing? i'm having trouble parsing that, so i can't respond intelligently. can you rephrase? Finally, you should not forget that incubated projects are frequently mature and well maintained. What good does it, to forbid them to publish, for example, a release that is identical to the last public release, except that the package names are being updated. IMO this is the least what users can expect to guide them in their own transition as soon as possible. as far as i'm concerned, they can publish whatever they want -- but they can't call it an asf release. i don't think any harm would be done if a ga release were made during incubation, labeled with the pre-incubation name (i.e., not mentioning the asf at all), but i'd have to consider it more to feel sure about that. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting the distribution onto a download site somewhere ...
Jochen, A project is accepted into the Incubator on the hopes that it WILL become an ASF project. However, it still needs to meet certain critera (the exit criteria). Those criteria should include having a healthy Community, which helps to ensure its long term survival; and having all legal issues resolved, which permits it to be legally released under the ASF copyright. If those criteria have not been met, I do believe that the project should not be permitted to release a package with the imprimatur (Offical Approval) of the ASF. I would sooner permit a project to release something with known (and documented) bugs than to release something with legal entanglements. I don't care how mature the code. Software has bugs. Entanglements have lawyers. Those are the issues that come to my mind. The Incubator PMC may have others. Personally, I think that snapshots marked as test builds and perhaps also carrying a file listing the project's incubation status, would be OK. Again, the Incubator PMC may share or differ on that view. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting the distribution onto a download site somewhere ...
OK, based on everything I've read from this and a few of the other threads on this list, which I've just caught up to (I picked a bad weekend to attend a wedding that took me off email ;-), I am going to propose to the other XMLBeans folks that we do the following: 1. Create a build of a cvs snapshot and name the file: incubated-xmlbeans-1.0.0.zip (Ted's more serious suggestion than the one below, although that one made me smile more). 2. Edit the README.txt file to include a paragraph explaining that this build is a snapshot of an incubated project that is not yet officially endorsed by the ASF. 3. Add a note to the XMLBeans project web site making sure the incubation status is clear. Unless there are other suggestions, I'm going to assume this is a reasonable process to follow for an incubated project, which needs to make binaries available in order to help build a community. Cliff On Monday, September 22, 2003 11:40 AM, Ted Leung wrote: Okay guys, I get the message. I'll ask XML beans to make a xmlbeans-is-not-part-of-the-ASF-1.0 release. On 9/22/2003 10:09 AM, Rodent of Unusual Size wrote: Jochen Wiedmann wrote: i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. There are several things I do not understand here. First of all, IMO, by accepting a project for incubation, it is part of the ASF. no, it is a *candidate to become* part of the asf. if it fails to exit the incubator, for whatever reason, it doesn't wander off into the sunset bearing the asf name with it. :-) For whatever other reason am I expected to sign a contribution agreement at the beginning? From your point of view, it would be suffigient to sign when the project exits incubation. because the code is being stored on asf infrastructure, among other things. Next, assuming that my point is wrong, I would assume that incubation is targetted to be a process of transition. Which means, that a project is at some point perhaps not completely ready, but with a sufficient progress. What good does it, to insist in the final 20 percent or whatever you are missing? i'm having trouble parsing that, so i can't respond intelligently. can you rephrase? Finally, you should not forget that incubated projects are frequently mature and well maintained. What good does it, to forbid them to publish, for example, a release that is identical to the last public release, except that the package names are being updated. IMO this is the least what users can expect to guide them in their own transition as soon as possible. as far as i'm concerned, they can publish whatever they want -- but they can't call it an asf release. i don't think any harm would be done if a ga release were made during incubation, labeled with the pre-incubation name (i.e., not mentioning the asf at all), but i'd have to consider it more to feel sure about that. - 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: Getting the distribution onto a download site somewhere ...
Cliff Schmidt wrote: OK, based on everything I've read from this and a few of the other threads on this list, which I've just caught up to (I picked a bad weekend to attend a wedding that took me off email ;-), I am going to propose to the other XMLBeans folks that we do the following: 1. Create a build of a cvs snapshot and name the file: incubated-xmlbeans-1.0.0.zip (Ted's more serious suggestion than the one below, although that one made me smile more). 2. Edit the README.txt file to include a paragraph explaining that this build is a snapshot of an incubated project that is not yet officially endorsed by the ASF. 3. Add a note to the XMLBeans project web site making sure the incubation status is clear. Unless there are other suggestions, I'm going to assume this is a reasonable process to follow for an incubated project, which needs to make binaries available in order to help build a community. this sounds to me like a very good plan. thank you! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Copying to [EMAIL PROTECTED] for policy check. On 9/20/2003 1:54 AM, robert burrell donkin wrote: IIRC incubating projects should not create full releases (the reason being that the ASF makes a long term commitment to maintain all full releases) until the incubation process is finished (but this policy is something that should probably be checked with the incubator pmc). instead, unstable (milestone, alpha, beta, gold etc) releases should be created. these should be made available for download from the appropriate subdirectory of cvs.apache.org. (again, probably the pmc are the right people to ask about policy on whether they should be made available from an xml subdirectory download or a incubator download subdirectory.) Robert, I understand the concern here, but if there is a version that has been finished / super tested, etc, it seems a little sily not to make it stable. If incubation were to fail, and xmlbeans ended up on, say, Java.net, it's not going to change the quality of the code one way or another. I sort of thought that we already went through this with the lists being @xml or @incubator if you're considering releases, then this might also be a good time to consider nightlies and gump (if there are not yet sorted out). gump is a meta-builder which re-builds and tests all jakarta projects (and many other apache projects) with the latest versions of each dependency each day. nightly builds are created every day and uploaded to cvs.apache.org. i would recommend that xml beans signs up for both. +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting the distribution onto a download site somewhere ...
Ted, if there is a version that has been finished / super tested, etc, it seems a little sily not to make it stable. Stable, yes. Labeled as an ASF Release, no. In my view. I am not on the Incubator PMC, but I feel that a project still bearing incubator status should not be permitted to make a Release. Release status carries an imprimatur inappropriate for a project that has not entered the ASF proper. Basically, I would consider that by definition, on the basis that if a project is ready to make a Release, and isn't ready to leave the Incubator, then any reasons keeping it in the Incubator are reasons why it should not make a Release. Yes, if a project is ready to produce a Release, its status in the Incubator should be examined to see whether or not it has been successfully fledged, and any issues keeping it in the Incubator should be the focus of work to resolve. Projects under incubation should be permitted to put out test builds clearly indicated as such. I am not particularly concerned about whether a test build is located under cvs.apache.org/builds/incubator/project or cvs.apache.org/builds/TLP/project, but the Incubator PMC might have a stronger opinion. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Noel J. Bergman wrote: I am not on the Incubator PMC, but I feel that a project still bearing incubator status should not be permitted to make a Release. I do not know what exactly you define as a release. Is that more than a distribution? An incubator project is expected to build a community. I doubt it can do so from the CVS only: That would put the entry level for new users too high. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
