juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Juneau new release guidelines.
Date Mon, 03 Oct 2016 07:04:59 GMT
I don't agree with the lightweight approach of PPMC, although technically a
podlong vote is not required, the podling should operate like a Top Level
Project in training from the start (with some rough bumps :-).

That said, I think in the beginning it's best for the PPMC release votes to
focus on the technical side, while IPMC votes (including binding votes from
mentors) should catch any license/IP discrepancies. The first incubator
releases don't have to be picture perfect, that's why we have the
DISCLAIMER file ☺

Later on both of these roles would be fulfilled by the PPMC (aspiring PMC)
vote.  But to get there we have to start with following the release process
in principle.

On 2 Oct 2016 2:15 p.m., "John D. Ament" <johndament@apache.org> wrote:

On Sat, Oct 1, 2016 at 11:09 AM James Bognar <james.bognar@salesforce.com>
wrote:

> Hi John,
>
> Much of the credit goes to Stian who pointed me to the Taverna
instructions
> from where I pulled much of the information:
> https://taverna.incubator.apache.org/community
>
> I spent a lot of time just trying to get the formatting right in
> Confluence.  It's got a nice interface, but it's really buggy around
> formatting.  Sometimes I would do something to cause the formatting on
half
> the page to get messed up, and undo wouldn't fix it.  Even now it looks
> fine on Chrome/Firefox/Safari, but the fonts are messed up on
> Safari-mobile.  So be careful about that if you make any updates to the
> page.
>
> >- You may want to set push to false when doing a release.  There's still
> a lot
> of discussion out there, but it may be easier to manage a release off
> >of a fork rather than the main repo (and push to the main repo once the
> release
> is done).  There's trade offs either way.
> >- By not pushing, you eliminate the need to do an RC build as well.
>
> Using a fork sounds good to me.  I'm still not too familiar with Git.  Can
> you point me to an example of the instructions for doing so?  (or simply
> update the doc?)  I've never tried creating or merging forks (even though
I
> know that's what Git is supposedly best at).
>

Assuming you have a github account, if you go to
https://github.com/apache/incubator-juneau you'll see a "Fork" button in
the top right corner (it has a # next to it w/ the number of forks)


>
> >- It would be great if release notes could come out of JIRA rather than
> >being checked in.
>
> Agreed.  Do you know how to do that from a command line (create JIRA
> versions, generate release notes, etc...)?  If not, I can figure it out.
>

I don't.  And for something like this, CLI isn't always the right
solution.  I usually go to pages like
https://issues.apache.org/jira/browse/JUNEAU/fixforversion/12338351/?
selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
and
then click on "Release Notes" in the top right corner.

https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12320520&version=12338351

If you go there, you'll see a small issue w/ the release.


>
> > - The vote/discuss emails confuse me.  Where did that come from?  The
> most
> > I ever see (or expect to see) is a heads up style email saying someone
is
> > thinking about cutting a release.
>
> That was based on the instructions from Taverna.  Feel free to modify the
> templates.
>

Maybe a better way to put it is maybe the list should be in chronological
order.  You should discuss first, giving everyone notice, vote on the
release in PPMC and then vote on IPMC.

Now I want to throw this out there.  I'm trying to help podlings stream
line their process a little.  Technically speaking, the PPMC vote is
*optional*, the IPMC vote is required.  The IPMC wants to see good faith
that they're looking at a good release, but it doesn't mean the PPMC has to
vote on it (the PPMC's votes are non binding, Craig, Jochen and I have
binding votes).  You could prep the release, let people know its out there
to try out, and if we all say it looks good, move on to a IPMC vote.

Since the code had an SGA sent for it, and there's no 3rd party code
embedded, and you have minimal dependencies, as long as we get that
disclaimer file in there for both source and binary, we're good.

Does your binary also shade in your 3rd party deps?


>
> > I think we're also missing the DISCLAIMER as well, indicating that this
> is a project under incubation.
> In the email to general@incubator?
>
>
No, you'll want to check in a copy of this file
https://github.com/apache/incubator-tamaya/blob/master/DISCLAIMER and make
sure it gets included in the release archives.


> Thanks John!
>
>
>
>
> On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <johndament@apache.org>
> wrote:
>
> > James,
> >
> > This is awesome, thank you!
> > Assuming we get through this first release, I want to share this
document
> > with a broader audience to try to put together documented best practices
> > for the incubator release structure.  This covers the maven side that
> I've
> > always seen as a problem.
> >
> > A couple of notes:
> >
> > - You may want to set push to false when doing a release.  There's still
> a
> > lot of discussion out there, but it may be easier to manage a release
off
> > of a fork rather than the main repo (and push to the main repo once the
> > release is done).  There's trade offs either way.
> > - By not pushing, you eliminate the need to do an RC build as well.
> > - It would be great if release notes could come out of JIRA rather than
> > being checked in.
> > - The vote/discuss emails confuse me.  Where did that come from?  The
> most
> > I ever see (or expect to see) is a heads up style email saying someone
is
> > thinking about cutting a release.
> >
> > Also, You don't need "Subject:" in your email subjects.  I think we're
> also
> > missing the DISCLAIMER as well, indicating that this is a project under
> > incubation.
> >
> > John
> >
> > On Fri, Sep 30, 2016 at 12:29 PM James Bognar <
> james.bognar@salesforce.com
> > >
> > wrote:
> >
> > > New release guidelines are finished:
> > >
> > > <goog_1805653564>
> > > https://cwiki.apache.org/confluence/display/JUNEAU/New+
> > release+guidelines
> > >
> > > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
> > >
> > > --
> > > James Bognar
> > >
> >
>
>
>
> --
> James Bognar
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message