Just read through the GORA HOW_TO and I think it speaks a language that we're used to, so that's a good starting point for doing the release.
Noticed a few things we have to get straightened out: - Check if our pom.xml file(s) are similar to that of GORA wrt. release plugin etc. - JIRA. We need to register the release and the issues solved there. - Changes.txt. We have to make such a file and start maintaining it. - Notice.txt file. We need to accumulate the various license attributions etc. from all of our dependencies here. - Artifact signing. Didn't dive into this yet, but I see we probably need to manage a KEYS file and set up release engineer accounts with GPG. 2013/9/12 Henry Saputra <[email protected]> > Agree, you can start with [1] and [2] and give it a shot =) > > [1] http://incubator.apache.org/guides/release-java.html > [2] > https://cwiki.apache.org/confluence/display/GORA/Apache+Gora+Release+Procedure+HOW_TO > > On Wed, Sep 11, 2013 at 5:28 PM, Matt Franklin <[email protected]> > wrote: > > Also, take a look at other project's documented release guides. They > are a > > good starting point. Any specific questions, the mentors should be able > to > > help you answer > > > > > > On Tue, Sep 10, 2013 at 1:20 PM, Henry Saputra <[email protected] > >wrote: > > > >> HI Ankit, > >> > >> Yes I agree, it takes a bit of research to do first release. > >> > >> I will create a wiki page with direct TODO steps for us new with ASF > >> to be release manager. > >> > >> It will be sometimes this week and will send email to @dev list when > >> it is ready. > >> > >> - Henry > >> > >> On Tue, Sep 10, 2013 at 9:27 AM, Ankit Kumar <[email protected]> > >> wrote: > >> > Hi Henry, > >> > > >> > Thanks for sharing more info on the release process. > >> > > >> > My local git repository clone is building successfully with all tests > >> > passing but I do not understand how/where to start. > >> > > >> > The process appears to be still quite a ceremony with lot of steps > pretty > >> > new to us. In order to bring more structure and clarity, could we > please > >> > make a TODO list with a bit of explanation on what is expected from > that > >> > TODO item. This will also help us divide work amongst the group (if > >> needed) > >> > and also as part of working on each TODO item we can also > learn/document > >> > the whole process nicely. > >> > > >> > I guess the TODO list should help a lot already but if needed can we > also > >> > have a skype call(with anyone who knows the process) to > >> discuss/understand > >> > in detail. > >> > > >> > Regards > >> > Ankit > >> > > >> > > >> > On Mon, Sep 9, 2013 at 6:54 PM, Henry Saputra < > [email protected] > >> >wrote: > >> > > >> >> Marvin sent out good tips on how to get IPMC votes for releases under > >> >> ASF incubator. > >> >> > >> >> - Henry > >> >> > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: Marvin Humphrey <[email protected]> > >> >> Date: Mon, Sep 9, 2013 at 9:22 AM > >> >> Subject: [DISCUSS] Release of Apache Allura (incubating) v1.0.0 > >> >> To: "[email protected]" <[email protected]> > >> >> > >> >> > >> >> On Mon, Sep 9, 2013 at 6:47 AM, Rich Bowen <[email protected]> > wrote: > >> >> > Hmm. Did we do something wrong with our call for vote? > >> >> > >> >> Perhaps not this one, though the voting on allura-dev@incubator was > >> >> somewhat > >> >> irregular. > >> >> > >> >> * No "[VOTE]" in the subject. > >> >> * Spread out over multiple threads. > >> >> * No time specification. (I recommend the phrase "at least 72 > >> hours".) > >> >> * PPMC votes claimed as "binding", which is ambiguous. > >> >> > >> >> So long as the IPMC VOTE clears, though, those irregularities don't > >> block > >> >> the > >> >> release IMO. > >> >> > >> >> I'd also like to note that the dev list archives for Allura are > >> >> time-consuming > >> >> and tedious to plow through -- the signal-to-noise ratio is poor due > to > >> the > >> >> large number of auto-generated messages with trivial content. > >> >> > >> >> > Can anyone suggest any reason why we've gotten ZERO response to > this > >> >> message > >> >> > or to Dave's followup? > >> >> > >> >> Allura has four Mentors. You've voted, but where are the others? > >> >> > >> >> Mentors must lead the way, particularly for the first release. > >> "Freelance" > >> >> reviews of release artifacts, by IPMC members who are not following > the > >> >> podling's development, are by their nature superficial. For > instance, a > >> >> freelancer can run RAT and see whether there are files with missing > ALv2 > >> >> headers, but can't see whether files with ALv2 headers had them > >> installed > >> >> appropriately. We count on Mentors to endorse the podling's initial > IP > >> >> handling, from supervising the code grant to monitoring the dev list > and > >> >> commits list day-by-day and ensuring that everything is proper. > >> >> > >> >> After the first release, we are voting on a delta, and all new > changes > >> have > >> >> happened within Apache channels which are comparatively more > auditable. > >> >> However, for the initial incubating release, we are voting on > >> development > >> >> which took place elsewhere, and Mentors have better insight than the > >> rest > >> >> of > >> >> the IPMC into the importation and assimilation of that dark matter > into > >> >> Apache. > >> >> > >> >> > Can some of the old hands around here give us some insight into > what > >> we > >> >> need > >> >> > to do to get things moving? > >> >> > >> >> Getting enough IPMC votes for incubating releases is an age-old issue > >> for > >> >> the > >> >> Incubator. Many long-term remedies have been discussed, but none of > >> that > >> >> will > >> >> help the acute problem faced by Allura. > >> >> > >> >> In today's Incubator, the most effective strategy for an individual > >> >> podling to > >> >> take is for its core contributors to become serious experts about > >> Apache IP > >> >> and release policy and to present squeaky clean release candidates > which > >> >> make > >> >> a best effort to follow all known rules and guidelines. In Allura's > >> case, > >> >> not > >> >> only would it help to run the dev list VOTEs more cleanly, but it > would > >> >> help > >> >> if PPMC members who vote +1 document exactly what steps they took to > >> >> validate > >> >> the release candidate. > >> >> > >> >> It's nice to see a list like this accompanying a +1 vote: > >> >> > >> >> * Sums and sigs OK (log below). > >> >> * Build from source tarball succeeds and passes tests on [list > >> >> platforms]. > >> >> * Extended tests pass on [list platforms]. > >> >> * RAT build target passes. > >> >> * Tarball name contains "incubating". > >> >> * Incubation DISCLAIMER included. > >> >> * Expanded tarball matches version control tag exactly (diff > log > >> >> below). > >> >> * LICENSE and NOTICE assembled according to > >> >> <http://www.apache.org/dev/licensing-howto.html> per > >> discussion at > >> >> [link]. > >> >> * LICENSE and NOTICE up-to-date, as no dependencies have been > >> added > >> >> since initial assembly. > >> >> * All copyleft dependencies purged as documented at [issue]. > >> >> * Copyright date in NOTICE is current. > >> >> * CHANGES entry is current. > >> >> * Issue tracker clean (no open issues for this release). > >> >> ... > >> >> > >> >> Documented diligence by podling contributors lowers the cost of > >> reviewing > >> >> and > >> >> voting for Mentors and other IPMC members, and may help to persuade > >> those > >> >> hanging back to participate. > >> >> > >> >> Marvin Humphrey > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >
