Yes I meant the staging repo. Take a look at the link I sent before about Apache spark release announcement to get some tips how to prepare release for vote.
On Wednesday, December 11, 2013, Ankit Kumar wrote: > 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 >
