Hi Henry, Can you explain what is the staging area? Is it the staging repo location i already shared in the vote thread earlier.
I need to understand what extra steps i must perform before sending again the vote thread. Regards Ankit On Dec 11, 2013 3:15 PM, "Matt Franklin" <[email protected]> wrote: > Keep in mind the first Apache release is the hardest. It gets a lot > easier from here. > > > On Tue, Dec 10, 2013 at 8:03 PM, Henry Saputra <[email protected] > >wrote: > > > Thanks guys, I guess we could continue with release VOTE using the > staging > > repo. > > > > I have set the svn pub sub for MetaModel to push our release artifacts > > later to the dist location. > > > > Ankit, as the RE for this release, can resend the [VOTE] thread with > > RC files in the staging area. > > > > > > - Henry > > > > On Sat, Dec 7, 2013 at 4:18 AM, Matt Franklin <[email protected]> > > wrote: > > > On Fri, Dec 6, 2013 at 3:18 PM, Kasper Sørensen < > > > [email protected]> wrote: > > > > > >> Hi all, > > >> > > >> Recent vote of the release didn't go too well because of variying > > opinions > > >> on where the release candidate artifacts should be provided. With this > > >> discussion I want to get an impression of what people need when they > > review > > >> a release, and what this means for the requirements and wishes of the > > >> actual release artifact location. > > >> > > >> It seems the norm in Apache projects is that artifacts are manually > > >> uploaded by the Release Engineer to somewhere in his personal > > >> people.apache.org web space. So some people prefer this approach. The > > >> upside here is that the release engineer can arrange the location so > > that > > >> it is as humanly consumable as possible. (Proponents of this approach > > may > > >> add more upsides that I may not know about.) > > >> > > > > > > Uploading to people.apache.org is actually an older practice that has > > been > > > deprecated. There is now a SVN Pub/Sub system with a staging and dist > > > section that we can ask INFRA to configure for us. > > > > > > > > > > > >> > > >> However, we're using Maven for the release packaging, signing and > > >> verification, and uploading to a Maven staging repository on > > >> repository.apache.org. This means that we can automize the upload > > >> completely by the existing Maven release process. The location that > the > > >> Release Engineer would publish would ultimately be a small Maven > > >> repository. This has the advantage that if you want to review a > release > > >> candidate from the perspective of an existing project that is > depending > > on > > >> MetaModel, you could simply consume the repository in your project and > > >> update your dependency version number. That way you could use the > > release > > >> candidate with very few changes and be able to build, test and run > other > > >> projects that depend on it. It also means that the location of the > > release > > >> candidate artifacts is not on people.apache.org, and that for > instance > > the > > >> source zip file will not be in the root of the upload location, but > in: > > >> > > >> > > > [root]/org/apache/metamodel/MetaModel/[version]/MetaModel-[version]-source-release.zip. > > >> That location is obviously less easily accessible if you just get the > > >> repository URL. > > >> > > > > > > We should deploy to repository.apache.org. It ensures are artifacts > are > > > synced to Maven central. > > > > > > > > >> > > >> My opinion: > > >> I like the automatic Maven repository and don't see the point (yet?) > in > > why > > >> it has to be on people.apache.org. That said, I do think the vote > email > > >> should contain not just one link to the repository, but also a link > > >> specifically to the source zip. That way the complication of finding > the > > >> source zip is overcome for people less accustomed to Maven's > repository > > >> layout. > > >> > > > > > > Bottom line is that it doesn't really matter where the release > artifacts > > > are staged; but, the release process MUST comply with the following: > > > > > > 1) Produce a binary-free source package that is the "release" that is > > voted > > > on > > > 2) Comply with all LICENSE & NOTICE constraints (including ensuring > > > compatible licensing on source inclusions) > > > 3) Reside on dist.apache.org. By policy, a release must be accessible > > > through > https://dist.apache.org/repos/dist/release/incubator/metamodel/ > > > > > > A release MAY: > > > > > > 1) Deploy to maven central via repository.apache.org > > > 2) Build "convenience" binaries that include 3rd party dependencies and > > > host these in dist > > > > > > > > > Hope this clears things up. > > > > > > > > >> > > >> Best regards, > > >> Kasper > > >> > > >
