Re: preparing for a first release

2018-04-12 Thread Jonas Pfefferle 

Hi Julian

Thanks for the hints I will look into it.

Jonas

 On Tue, 10 Apr 2018 16:46:26 -0700
 Julian Hyde  wrote:

Reviewing the repo at a particular commit is a good first step.

The next step will be to create a release candidate (a tar ball and 
checksum files and signatures), add them to dist.apache.org for 
review, and send an email to start a vote.


Here is an example: 
https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E 
 

I’d be careful with tags. It’s not good to change/delete tags 
applied to the master branch. So I wouldn’t apply the ‘v1.0’ tag 
until the release vote has passed. You could use ‘v1.0-rc1’ etc. for 
release candidates.


I also strongly suggest that you compile a “howto” - a list of 
instructions that you followed to make the release, that can be 
followed by the next release manager next release - and commit it 
after the release. It is very important that the release process is 
consistent and reproducible.


Julian


On Apr 10, 2018, at 7:18 AM, Animesh Trivedi 
 wrote:


Dear all,

We are ready for our first source code release. We have tagged the 
current
candidate with v1.0 
(https://github.com/apache/incubator-crail/tree/v1.0).


What is the next step? Start a vote for "source-only" release where 
people

can review the currently tagged branch?

Thanks,
--
Animesh


On Tue, Mar 13, 2018 at 9:57 PM, Julian Hyde  
wrote:



Bernard,

You have it about right.

One thing to remember is that a release is source-code only. (You 
may

do binary releases later, but they are much more complicated.)

Another is that releases don't need to be perfect in terms of
functionality. It's fine if there are bugs, as long as the code
compiles. The thing that trips up most podlings is getting the legal
aspects right (e.g. no GPL-licensed dependencies, including 
necessary

text in LICENSE and NOTICE files).

I suggest you make a first release candidate, start a vote, and get
feedback. The first couple of votes will likely fail. It will take a
couple of iterations, but we don't expect perfection first time.

When the PPMC vote passes, there is a second vote on the IPMC. (Due
Apache policy that only a "real" PMC can make a release. The IPMC is
real PMC, but the PPMC is only a PMC-in-training.) That second step 
is
arduous I'm afraid (and adds a few extra days) but it's not too bad 
by

the 2nd or 3rd release.

Julian


On Tue, Mar 13, 2018 at 11:35 AM, Luciano Resende 


wrote:
I would say the most important thing would be to get the legal parts 
in a

good state.

For guide, I would start with :
- http://www.apache.org/dev/#releases


For actual steps, here is what I have used in other projects (which

include

building, staging, signing, etc):

https://github.com/apache/bahir/blob/master/dev/release-build.sh


On Tue, Mar 13, 2018 at 11:21 AM, bernard metzler 

wrote:



Dear Mentors,

Looks like we are getting close to a point where we think the code
base is good for a first release. I just searched around a little
to see what is needed from an administrative point of view. What
I found is an overwhelming amount of information, starting
at https://incubator.apache.org/guides/releasemanagement.html

So, what I understand is, we have to follow some formal policies
applicable to all ASF project releases
(http://www.apache.org/legal/release-policy.html) plus setting up
the code base in a staged area (which would be
https://dist.apache.org/repos/dist/dev/incubator/crail/ - which
does not yet exist?), and finally go through a PMC voting procedure,
as described at
https://incubator.apache.org/guides/releasemanagement.html


Is there anything else I am missing?

Thank you!
Bernard.



--
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: preparing for a first release

2018-04-10 Thread Julian Hyde 
Reviewing the repo at a particular commit is a good first step.

The next step will be to create a release candidate (a tar ball and checksum 
files and signatures), add them to dist.apache.org for review, and send an 
email to start a vote.

Here is an example: 
https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E
 

 

I’d be careful with tags. It’s not good to change/delete tags applied to the 
master branch. So I wouldn’t apply the ‘v1.0’ tag until the release vote has 
passed. You could use ‘v1.0-rc1’ etc. for release candidates.

I also strongly suggest that you compile a “howto” - a list of instructions 
that you followed to make the release, that can be followed by the next release 
manager next release - and commit it after the release. It is very important 
that the release process is consistent and reproducible.

Julian



> On Apr 10, 2018, at 7:18 AM, Animesh Trivedi  
> wrote:
> 
> Dear all,
> 
> We are ready for our first source code release. We have tagged the current
> candidate with v1.0 (https://github.com/apache/incubator-crail/tree/v1.0).
> 
> What is the next step? Start a vote for "source-only" release where people
> can review the currently tagged branch?
> 
> Thanks,
> --
> Animesh
> 
> 
> On Tue, Mar 13, 2018 at 9:57 PM, Julian Hyde  wrote:
> 
>> Bernard,
>> 
>> You have it about right.
>> 
>> One thing to remember is that a release is source-code only. (You may
>> do binary releases later, but they are much more complicated.)
>> 
>> Another is that releases don't need to be perfect in terms of
>> functionality. It's fine if there are bugs, as long as the code
>> compiles. The thing that trips up most podlings is getting the legal
>> aspects right (e.g. no GPL-licensed dependencies, including necessary
>> text in LICENSE and NOTICE files).
>> 
>> I suggest you make a first release candidate, start a vote, and get
>> feedback. The first couple of votes will likely fail. It will take a
>> couple of iterations, but we don't expect perfection first time.
>> 
>> When the PPMC vote passes, there is a second vote on the IPMC. (Due
>> Apache policy that only a "real" PMC can make a release. The IPMC is
>> real PMC, but the PPMC is only a PMC-in-training.) That second step is
>> arduous I'm afraid (and adds a few extra days) but it's not too bad by
>> the 2nd or 3rd release.
>> 
>> Julian
>> 
>> 
>> 
>> On Tue, Mar 13, 2018 at 11:35 AM, Luciano Resende 
>> wrote:
>>> I would say the most important thing would be to get the legal parts in a
>>> good state.
>>> 
>>> For guide, I would start with :
>>> - http://www.apache.org/dev/#releases
>>> 
>>> 
>>> For actual steps, here is what I have used in other projects (which
>> include
>>> building, staging, signing, etc):
>>> 
>>> https://github.com/apache/bahir/blob/master/dev/release-build.sh
>>> 
>>> 
>>> 
>>> On Tue, Mar 13, 2018 at 11:21 AM, bernard metzler 
>> wrote:
>>> 
 Dear Mentors,
 
 Looks like we are getting close to a point where we think the code
 base is good for a first release. I just searched around a little
 to see what is needed from an administrative point of view. What
 I found is an overwhelming amount of information, starting
 at https://incubator.apache.org/guides/releasemanagement.html
 
 So, what I understand is, we have to follow some formal policies
 applicable to all ASF project releases
 (http://www.apache.org/legal/release-policy.html) plus setting up
 the code base in a staged area (which would be
 https://dist.apache.org/repos/dist/dev/incubator/crail/ - which
 does not yet exist?), and finally go through a PMC voting procedure,
 as described at
 https://incubator.apache.org/guides/releasemanagement.html
 
 
 Is there anything else I am missing?
 
 Thank you!
 Bernard.
 
>>> 
>>> 
>>> 
>>> --
>>> Luciano Resende
>>> http://twitter.com/lresende1975
>>> http://lresende.blogspot.com/
>>

Re: preparing for a first release

2018-04-10 Thread Animesh Trivedi 
Dear all,

We are ready for our first source code release. We have tagged the current
candidate with v1.0 (https://github.com/apache/incubator-crail/tree/v1.0).

What is the next step? Start a vote for "source-only" release where people
can review the currently tagged branch?

Thanks,
--
Animesh


On Tue, Mar 13, 2018 at 9:57 PM, Julian Hyde  wrote:

> Bernard,
>
> You have it about right.
>
> One thing to remember is that a release is source-code only. (You may
> do binary releases later, but they are much more complicated.)
>
> Another is that releases don't need to be perfect in terms of
> functionality. It's fine if there are bugs, as long as the code
> compiles. The thing that trips up most podlings is getting the legal
> aspects right (e.g. no GPL-licensed dependencies, including necessary
> text in LICENSE and NOTICE files).
>
> I suggest you make a first release candidate, start a vote, and get
> feedback. The first couple of votes will likely fail. It will take a
> couple of iterations, but we don't expect perfection first time.
>
> When the PPMC vote passes, there is a second vote on the IPMC. (Due
> Apache policy that only a "real" PMC can make a release. The IPMC is
> real PMC, but the PPMC is only a PMC-in-training.) That second step is
> arduous I'm afraid (and adds a few extra days) but it's not too bad by
> the 2nd or 3rd release.
>
> Julian
>
>
>
> On Tue, Mar 13, 2018 at 11:35 AM, Luciano Resende 
> wrote:
> > I would say the most important thing would be to get the legal parts in a
> > good state.
> >
> > For guide, I would start with :
> > - http://www.apache.org/dev/#releases
> >
> >
> > For actual steps, here is what I have used in other projects (which
> include
> > building, staging, signing, etc):
> >
> > https://github.com/apache/bahir/blob/master/dev/release-build.sh
> >
> >
> >
> > On Tue, Mar 13, 2018 at 11:21 AM, bernard metzler 
> wrote:
> >
> >> Dear Mentors,
> >>
> >> Looks like we are getting close to a point where we think the code
> >> base is good for a first release. I just searched around a little
> >> to see what is needed from an administrative point of view. What
> >> I found is an overwhelming amount of information, starting
> >> at https://incubator.apache.org/guides/releasemanagement.html
> >>
> >> So, what I understand is, we have to follow some formal policies
> >> applicable to all ASF project releases
> >> (http://www.apache.org/legal/release-policy.html) plus setting up
> >> the code base in a staged area (which would be
> >> https://dist.apache.org/repos/dist/dev/incubator/crail/ - which
> >> does not yet exist?), and finally go through a PMC voting procedure,
> >> as described at
> >> https://incubator.apache.org/guides/releasemanagement.html
> >>
> >>
> >> Is there anything else I am missing?
> >>
> >> Thank you!
> >> Bernard.
> >>
> >
> >
> >
> > --
> > Luciano Resende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
>

Re: preparing for a first release

2018-03-13 Thread Julian Hyde 
Bernard,

You have it about right.

One thing to remember is that a release is source-code only. (You may
do binary releases later, but they are much more complicated.)

Another is that releases don't need to be perfect in terms of
functionality. It's fine if there are bugs, as long as the code
compiles. The thing that trips up most podlings is getting the legal
aspects right (e.g. no GPL-licensed dependencies, including necessary
text in LICENSE and NOTICE files).

I suggest you make a first release candidate, start a vote, and get
feedback. The first couple of votes will likely fail. It will take a
couple of iterations, but we don't expect perfection first time.

When the PPMC vote passes, there is a second vote on the IPMC. (Due
Apache policy that only a "real" PMC can make a release. The IPMC is
real PMC, but the PPMC is only a PMC-in-training.) That second step is
arduous I'm afraid (and adds a few extra days) but it's not too bad by
the 2nd or 3rd release.

Julian



On Tue, Mar 13, 2018 at 11:35 AM, Luciano Resende  wrote:
> I would say the most important thing would be to get the legal parts in a
> good state.
>
> For guide, I would start with :
> - http://www.apache.org/dev/#releases
>
>
> For actual steps, here is what I have used in other projects (which include
> building, staging, signing, etc):
>
> https://github.com/apache/bahir/blob/master/dev/release-build.sh
>
>
>
> On Tue, Mar 13, 2018 at 11:21 AM, bernard metzler  wrote:
>
>> Dear Mentors,
>>
>> Looks like we are getting close to a point where we think the code
>> base is good for a first release. I just searched around a little
>> to see what is needed from an administrative point of view. What
>> I found is an overwhelming amount of information, starting
>> at https://incubator.apache.org/guides/releasemanagement.html
>>
>> So, what I understand is, we have to follow some formal policies
>> applicable to all ASF project releases
>> (http://www.apache.org/legal/release-policy.html) plus setting up
>> the code base in a staged area (which would be
>> https://dist.apache.org/repos/dist/dev/incubator/crail/ - which
>> does not yet exist?), and finally go through a PMC voting procedure,
>> as described at
>> https://incubator.apache.org/guides/releasemanagement.html
>>
>>
>> Is there anything else I am missing?
>>
>> Thank you!
>> Bernard.
>>
>
>
>
> --
> Luciano Resende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/

preparing for a first release

2018-03-13 Thread bernard metzler 
Dear Mentors,

Looks like we are getting close to a point where we think the code
base is good for a first release. I just searched around a little
to see what is needed from an administrative point of view. What
I found is an overwhelming amount of information, starting
at https://incubator.apache.org/guides/releasemanagement.html

So, what I understand is, we have to follow some formal policies
applicable to all ASF project releases
(http://www.apache.org/legal/release-policy.html) plus setting up
the code base in a staged area (which would be
https://dist.apache.org/repos/dist/dev/incubator/crail/ - which
does not yet exist?), and finally go through a PMC voting procedure,
as described at
https://incubator.apache.org/guides/releasemanagement.html


Is there anything else I am missing?

Thank you!
Bernard.