On 3/22/07, Steve Loughran <[EMAIL PROTECTED]> wrote:
Xavier Hanin wrote: > On 3/20/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote: >> >> On Wed, 14 Mar 2007, Xavier Hanin <[EMAIL PROTECTED]> wrote: >> >> > I think it would be a good thing to produce a first incubating >> > version of Ivy early April, and I would like to check what we need >> > to do, and who does what. >> >> We have a pretty detailed step by step guide at Ant[1] that show how >> we do it over there. In general the exact process of doing a release >> is different between ASF projects but there are a few things that are >> common: >> >> * the distribution must only contain stuff we are allowed to >> distribute > > I think this is ok. For external dependencies, I think they are all ok > since > either from Apache, or used by other Apache projects. We also have a > dependency on xooki for the documentation, which is released under ASL v2. > There is also one class largely inspired by a Maven class, but I think this > is not a problem. Xooki itself has some piece of codes inspired by > tiddlywiki (BSD) and dojo ( Academic Free > License<http://opensource.org/licenses/afl-2.1.php> > v2.1) Is xooki distributed? or just depended on to create the distros?
For the moment xooki is only an in browser solution, so you need xooki to browse the doc. This is likely to change in the future since it causes some problems (bad accessibility and bad compatibility with web crawlers for the online version), but right now we'll need to distribute it together with the doc. Is it a problem?
> * all LICENSE and NOTICE files are in place (this also means inside >> the JAR file in the case of binary distributions), all project files >> contain the license headers > > > I think I see what to do for LICENSE and NOTICE, but I'm not sure for > license headers. All java source files have the proper license header. But > should all xml files, including files used for unit tests and examples, > include the header? What about properties files? HTML files from the > documentation? > > * the distribution files are signed with a valid PGP key. >> >> Sidenote: make sure to catch Steve and myself (don't know whether >> any other Ant people will be around) as well as any other Apache >> people you will meet in Amsterdam and make sure we sign the key you >> intend to use for the final release. There probably will be a >> keysigning event at ApacheCon. > > > Does it mean this step is necessary before I can release a first alpha or > beta version? Because I would like to try to release it before ApacheCon. As Jan said, we can do that together. if you look at the full apache release rules (where are they, BTW?), the PMC members are meant to verify that that the built artifacts are what they say they are, which may include rebuilding the files and comparing checksums on the individual .class files in the JAR. This is there to catch malicious build managers putting in back doors. So >1 person should be building the file anyway...any of the people who are in the apache trustweb can sign the release.
Ok, I didn't know that, I see that security is a major concern for Apache, it's a good thing.
* before the distribution files can be copied to the distribution area >> you need at least 3 +1s from PMC members and more +1s than -1s. >> >> * people will vote on the distribution files, so prepare what you want >> to release before calling for a vote. > > > Ok, so I'll first commit the required files (NOTICE, LICENSE, DISCLAIMER, > and a release guide) to see if things seems ok, then I'll prepare a release > and put it in my user space on the apache web site to ease evaluation and > start the vote, first on this list, then if it's ok on the > [EMAIL PROTECTED] Is > it a correct way to proceed? I should subscribe to [EMAIL PROTECTED], shouldn't I?
I think so, as a mentor and member of the incubator PMC. But I'm certainly not the best person to give recomentation on that subject :-)
>> So I would like to know what do we need to do to make such a >> > release. What is the process of releasing software in the incubator? >> >> It is not too different from the "normal" way of making a release >> AFAIU[2]. Your mentors are supposed to be Incubator PMC members, so our >> +1s should be enough to ensure the quorum. >> >> > Who can perform the remaining tasks? >> >> In theory anybody can be the release manager, being a committer >> certainly simplifies things 8-) > > > Ok, I'll take this task, unless somebody else want to take it. Well volunteered :) I may be able to add the ivy build to the bamboo build of smartfrog we're setting up here, though its probably better as a public CI server. Hmm. Maybe I could set it up at home, too.
This would be nice, a more real time feedback than gump would be nice, and being able to use generated artifacts as with our prior cruisecontrol setup at jayasoft. What is needed at the end of the day is
-the JAR file -the docs for offline use, maybe some examples. -a source distribution that people can use to build the JAR file. If it doesnt work, you don't get contributions back.
These three things should already be straightforward to get: $ svn co https://svn.apache.org/repos/asf/incubator/ivy/core/trunk ivy $ cd ivy $ ant release This generates the same kinf of files as those available here: http://incubator.apache.org/ivy/downloads/latest/ I'll need to check if building is still ok with the source distrib. And I don't know if the packaging used is ok. -the right headers on all the source files. Checkstyle can audit the
code for this.
As I said before, I don't exactly know what should be considered source files. Java files already have the good header (I think), but what about xml files and the like. About checkstyles, maybe we could include the check as part of Ivy build. Is there an easy to use checkstyle rule for that? -a release announcement PGP-signed by someone other apache people trust. I can write the release announcement even if my english is far from perfect, but I'll need a volunteer for signing. Other than that, the release guidelines are just that, guidelines.
For ant, we set up a wiki page of what has to be done...here is the ant1.7 one: http://wiki.apache.org/ant/Ant17/Planning That's probably the first step...create a (draft) plan.
That sounds like a good idea, I'll create a draft page on the wiki. For the rest, well, I like to view the alpha release as a way of testing
the release process.
Exactly, that's my view too. And it will also help people see that we are making progress in our incubation process. - Xavier You can do tricks like unzip/untar the redist
artifacts, then do a build of that project (pointing it away from the normal ivy cache dirs), to check that your source redist is cleanly buildable, and run checkstyle against the source to look for licensing problems. -steve
