Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
References: <CADmm+Kej-pqfieZueESg+=MF0Lx+_0znF44SxFsqQDA5t-exeg@mail.gmail.com>
In-Reply-To: <CADmm+Kej-pqfieZueESg+=MF0Lx+_0znF44SxFsqQDA5t-exeg@mail.gmail.com>
From: "John D. Ament" <johndament@apache.org>
Date: Mon, 09 Jan 2017 00:26:53 +0000
Message-ID: <CAOqetn_y-WqMLiTGzaaA-K78Jqw5nk8915wxd9H_MhHDN_ObdA@mail.gmail.com>
Subject: Re: Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]
To: general@incubator.apache.org
Content-Type: multipart/alternative; boundary=94eb2c0812f246b37905459e6d6d
archived-at: Mon, 09 Jan 2017 00:27:08 -0000

--94eb2c0812f246b37905459e6d6d
Content-Type: text/plain; charset=UTF-8

On Sun, Jan 8, 2017 at 6:55 PM Niclas Hedhman <niclas@hedhman.org> wrote:

> Yes, I think we all hear your "frustration" that the process is not as
> streamlined as it perhaps could, nor that the documentation is as solid as
> one might expect (patches are welcome)
>
> The underlying "issue" between the previous "GitHub/Maven releases" and
> "Apache releases" was discussed at length long time ago. Basically, pushing
> something to Maven Central is not a release. It is a "convenience service"
> by the project, and is not at all required from Apache's point of view.
> This fact may have some repercussions in how you approach the release.
>
> Perhaps it is possible to automate a bunch of this, for future podlings to
> benefit from. And perhaps with help from someone who has experienced this
> recently and have notes, infra could create a self-service portal for
> setting it up.
>
> In Apache Polygene, we have gotten very far in terms of release automation,
> but the initial steps are of course outside our scope. Probably after our
> next release, we will publish reusable Gradle components for the Apache
> release process for other Gradle based projects to benefit from. We'll see
> exactly how we do this.
>

Agreed with all of the above.  In addition, the ASF parent pom is at
https://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml which can have
a lot more added to it.

It strikes me though from reading your commentary, a lot of what you ran
into is specific to how your project is setup.  RAT for instance, I
wouldn't have ignored headers on README.md (it should have headers).
Standard eclipse files should probably be excluded by default, since those
are IDE generated values.  However in your case, if the file is in the
release it should have a valid header.

Release processes are interesting.  Given a similar set of developers, its
surprisingly high how frequently release steps will differ between
projects.  Even when it comes to a build.  Some projects like to have an
explicit RAT check step, others like it with every build.  Different
projects have different preferences and I think if we standardize it we'll
start to stifle creativity.


>
> Cheers
> Niclas
>
>
> On Mon, Jan 9, 2017 at 1:12 AM, Edward Capriolo <edlinuxguru@gmail.com>
> wrote:
>
> > On Sat, Jan 7, 2017 at 9:42 AM, John D. Ament <johndament@apache.org>
> > wrote:
> >
> > > On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman <niclas@hedhman.org>
> > wrote:
> > >
> > > > On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament <johndament@apache.org
> >
> > > > wrote:
> > > >
> > > > > > So, instead of tying the "incubating" marker to "incubating", I
> > would
> > > > favor
> > > > > > a system of marker(s) indicating the code maturity (incl legal).
> > So,
> > > > for a
> > > > > > podling release to be 1.2.3 (a la Groovy), the same release
> > standard
> > > as
> > > > > > TLPs are applied, but allow "alpha", "rc" or similar markers for
> > > > podlings
> > > > > > to "practice" releases. Probably not pushing those to mirrors,
> but
> > > > > > otherwise identical in "process" for podling to get their grips
> on
> > > the
> > > > > > release process.
> > > > > >
> > > >
> > > > > I think this is a fair point, and probably close to what podling
> > > > > communities do (when its a fairly new codebase).  We often see
> > releases
> > > > in
> > > > > the 0.x line, and in the 1+ lines.  Its up to the podling to
> > determine
> > > > how
> > > > > mature they are from a release numbering standpoint.  I wouldn't
> want
> > > the
> > > > > IPMC to enforce a versioning scheme.
> > > > > It does however seem like a foundation wide versioning scheme may
> > make
> > > > > sense, or at least references to common references, e.g. semver,
> may
> > > make
> > > > > sense as a recommendation to new podlings.
> > > >
> > > > Yeah, this is a tricky question. On one hand I don't like to dictate,
> > but
> > > > as a user I like to have a unified view of the world. Perhaps one or
> > two
> > > > DOAP entries would be a good way, and more strongly promote the DOAP
> > and
> > > > over time our common tooling could provide the unified view. A bit of
> > > "be a
> > > > good citizen.... for your own sake" attitude.
> > > >
> > > >
> > > I'm not sure what you mean by DOAP entries.  Do you have an example?
> > >
> > > John
> > >
> > >
> > >
> > > >
> > > > Cheers
> > > > --
> > > > Niclas Hedhman, Software Developer
> > > > http://polygene.apache.org - New Energy for Java
> > > >
> > >
> >
> > But that pendulum has swung in the opposite direction, and podling
> releases
> > are now expected to be at ASF TLP levels.
> >
> > I agree with this. I have started the gossip podling. Getting the release
> > out to ASF levels is a bit tricky. Let me explain my situation:
> >
> > For projects outside of apache I have my own github and I setup an
> account
> > on sonatype. I publish two or three artifacts to maven central and have a
> > good amount of foot traffic for what are niche projects.
> >
> > github, sonatype, and travis yaml is a lightning fast setup. Sonatype
> asks
> > you to submit a jira one time and after that you can publish unlimited
> > artifacts in your group to maven central.  After the initial setup a
> single
> > pom file is all you need to be publishing to maven central.
> > mvn release clean; mvn release prepare; mvn release perform
> > With some plugins you can even automate the closing and releasing the
> > repository if you wish,I still do that by hand in sonatype UI.
> >
> > If you compare this with the apache process there are a lot of
> disconnected
> > steps. For example, I took on the role of release engineer. We all live
> in
> > the stack overflow generation, this document is really great
> > https://www.apache.org/dev/release-signing.html in its detail, however
> it
> > lacks the "here is the 10 steps you actually need" to cut a release. We
> > also had to schedule a key signing party for me.
> >
> > Also it was very difficult to find the stripped down basic pom file. We
> > luckily got a contributor that did 90% but as we got closer to the
> release
> > I had to figure out how the rat plugin works, how to make it exclude
> things
> > etc.
> >
> >                         <plugin>
> >                                 <groupId>org.apache.rat</groupId>
> >
>  <artifactId>apache-rat-plugin</artifactId>
> >                                 <configuration>
> >                                         <excludes>
> >
> > <exclude>README.md</exclude>
> >
> > <exclude>eclipse_template.xml</exclude>
> >                                         </excludes>
> >                                 </configuration>
> >                                 <executions>
> >                                         <execution>
> >                                                 <phase>verify</phase>
> >                                                 <goals>
> >
>  <goal>check</goal>
> >                                                 </goals>
> >                                         </execution>
> >                                 </executions>
> >                         </plugin>
> >
> > You have to go to a different page for the release module configuration
> >
> >
> > <pushChanges>false</pushChanges>
> >
> > <localCheckout>true</localCheckout>
> >
> > <autoVersionSubmodules>true</autoVersionSubmodules>
> >
> >
> > Now, I know this is just a process of tracking down some other pom file
> in
> > the incubator and taking it apart.
> >
> > There were other things too like tickets to infra to give me assess to
> > things svn, release.apache.org. At one point I was following some old
> doc
> > in apache which confused me on which server to put my public_html file.
> >
> > Please do not take this to mean I am complaining about the current
> process
> > or defending my own ignorance! However, if the process stays as it is. I
> do
> > think one streamline doc could disconnect all the steps. An example would
> > be like this.
> >
> > Checklist:
> >   Have a signed key with WEB of trust? NO - click here.
> >   Have svn access to path/to/keys ? Create infra ticket/contact podling
> >   Create INFRA for project jira
> >   Create INFRA for https://repository.apache.org/
> >   Complete pom file with special release and rat baked in
> >   ...
> >   put your settings in .m2/settings file
> >
> > To wrap it up I do not mind the requirements put it was fairly daunting
> to
> > connect u all the things that have to happen to make a release compared
> to
> > (sonatype,git,travis) and I found the process tricky to navigate. It
> sapped
> > more time than I would have liked and often you end up needing help from
> > infra/ podling crew and people are not always free at the same time.
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
>

--94eb2c0812f246b37905459e6d6d--