You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/07/30 16:21:36 UTC
[PROPOSAL] make release 0.1
Traditionally cutting the first apache release for a podling is one big
PITA, therefore
I propose we get started.
I propose we make release 0.1 consisting of
- docFormats (the library only with the OOXML filter)
- dfTest (the main test utility)
- dfUtil (the conversion utility)
We have a lot to learn here, about the files LICENSES and NOTICE and about
how to
handle release candidates and the final release, therefore I propose to
include the
"stable" parts. It can be argued that version 0.1 is not very useful for a
end-user, which
might be right, but it helps us get the release framework up and running.
Once we have 0.1 through the needle of IPMC, version 0.2 can focus a lot
more on the
technical content.
The steps we have to pass (I have surely forgotten a number) are:
- Make a branch (stable_0.1) that only contains what we intent to release
- Make it work (adapt CMake files etc)
- Correct LICENSES and NOTICE
- Prepare a release candidate (upload source with SHA5 to somewhere on dist)
- Vote on the release (min. 3 +1 NO -1)
- Ask IPMC to check the release and have them vote on it
this is the needle, they tend to find things we have not thought about,
but Justin (he is one of the best release checkers in incubators) earlier
promised
me to do a pre-check so we avoid the normal errors.
- When the vote finally passes, move the source to the release part of dist.
- Congratulate each other with work well done.
If we agree on the content and the idea of cutting a release, I volunteer
to do the work and
of course write about every step in here (and on the wiki), so we all learn
from the experience.
I do however need help from e.g. Dave, with some of the specialties.
Following the suggestion from Dave, Let us discuss this until August 7th,
and then see
if we have reached consensus.
Comments ?
rgds
jan i.
Re: [PROPOSAL] make release 0.1
Posted by Daniel Gruno <hu...@apache.org>.
On 2015-07-30 19:22, jan i wrote:
> Dave@ thanks for you offer.
>
> Can you help me understand one things about releases and IPMC.
>
> I have understood the task of the IPMC is to control the validity of the
> release (LICENSE, IP clearance etc) and not the quality (bad documentation
> etc),
> but it seems on general@ quality is often discussed ? can e.g. too little
> documentation be a release blocker ?
>
> thanks in advance.
> rgds
> jan i.
>
Hi Jan,
poor documentation can naturally be a concern, _but it cannot constitute
a veto_ by the IPMC. The priority for the IPMC is IP clearance,
licenses, notices and a transparent, open development process. Whatever
is left is mostly opinions, not requirements. In essence, the IPMC is
the steward of the legality and community aspect of the release, not the
quality of it.
With regards,
Daniel.
Re: [PROPOSAL] make release 0.1
Posted by jan i <ja...@apache.org>.
Dave@ thanks for you offer.
Can you help me understand one things about releases and IPMC.
I have understood the task of the IPMC is to control the validity of the
release (LICENSE, IP clearance etc) and not the quality (bad documentation
etc),
but it seems on general@ quality is often discussed ? can e.g. too little
documentation be a release blocker ?
thanks in advance.
rgds
jan i.
On 30 July 2015 at 18:26, Gabriela Gibson <ga...@gmail.com> wrote:
> I also think that doing this step whilst the project is still relatively
> compact is a very good move.
>
> +1
>
> G
> On 30 Jul 2015 17:06, "Dave Fisher" <da...@comcast.net> wrote:
>
> > Good plan. I will do my best to help. If we have 3 IPMC +1 from the
> > podling then the IPMC part is less of a PITA.
> >
> > Sent from my iPhone
> >
> > > On Jul 30, 2015, at 7:21 AM, jan i <ja...@apache.org> wrote:
> > >
> > > Traditionally cutting the first apache release for a podling is one big
> > > PITA, therefore
> > > I propose we get started.
> > >
> > > I propose we make release 0.1 consisting of
> > > - docFormats (the library only with the OOXML filter)
> > > - dfTest (the main test utility)
> > > - dfUtil (the conversion utility)
> > >
> > > We have a lot to learn here, about the files LICENSES and NOTICE and
> > about
> > > how to
> > > handle release candidates and the final release, therefore I propose to
> > > include the
> > > "stable" parts. It can be argued that version 0.1 is not very useful
> for
> > a
> > > end-user, which
> > > might be right, but it helps us get the release framework up and
> running.
> > >
> > > Once we have 0.1 through the needle of IPMC, version 0.2 can focus a
> lot
> > > more on the
> > > technical content.
> > >
> > > The steps we have to pass (I have surely forgotten a number) are:
> > > - Make a branch (stable_0.1) that only contains what we intent to
> release
> > > - Make it work (adapt CMake files etc)
> > > - Correct LICENSES and NOTICE
> > > - Prepare a release candidate (upload source with SHA5 to somewhere on
> > dist)
> > > - Vote on the release (min. 3 +1 NO -1)
> > > - Ask IPMC to check the release and have them vote on it
> > > this is the needle, they tend to find things we have not thought
> about,
> > > but Justin (he is one of the best release checkers in incubators)
> > earlier
> > > promised
> > > me to do a pre-check so we avoid the normal errors.
> > > - When the vote finally passes, move the source to the release part of
> > dist.
> > > - Congratulate each other with work well done.
> > >
> > > If we agree on the content and the idea of cutting a release, I
> volunteer
> > > to do the work and
> > > of course write about every step in here (and on the wiki), so we all
> > learn
> > > from the experience.
> > > I do however need help from e.g. Dave, with some of the specialties.
> > >
> > > Following the suggestion from Dave, Let us discuss this until August
> 7th,
> > > and then see
> > > if we have reached consensus.
> > >
> > > Comments ?
> > >
> > > rgds
> > > jan i.
> >
>
Re: [PROPOSAL] make release 0.1
Posted by Gabriela Gibson <ga...@gmail.com>.
I also think that doing this step whilst the project is still relatively
compact is a very good move.
+1
G
On 30 Jul 2015 17:06, "Dave Fisher" <da...@comcast.net> wrote:
> Good plan. I will do my best to help. If we have 3 IPMC +1 from the
> podling then the IPMC part is less of a PITA.
>
> Sent from my iPhone
>
> > On Jul 30, 2015, at 7:21 AM, jan i <ja...@apache.org> wrote:
> >
> > Traditionally cutting the first apache release for a podling is one big
> > PITA, therefore
> > I propose we get started.
> >
> > I propose we make release 0.1 consisting of
> > - docFormats (the library only with the OOXML filter)
> > - dfTest (the main test utility)
> > - dfUtil (the conversion utility)
> >
> > We have a lot to learn here, about the files LICENSES and NOTICE and
> about
> > how to
> > handle release candidates and the final release, therefore I propose to
> > include the
> > "stable" parts. It can be argued that version 0.1 is not very useful for
> a
> > end-user, which
> > might be right, but it helps us get the release framework up and running.
> >
> > Once we have 0.1 through the needle of IPMC, version 0.2 can focus a lot
> > more on the
> > technical content.
> >
> > The steps we have to pass (I have surely forgotten a number) are:
> > - Make a branch (stable_0.1) that only contains what we intent to release
> > - Make it work (adapt CMake files etc)
> > - Correct LICENSES and NOTICE
> > - Prepare a release candidate (upload source with SHA5 to somewhere on
> dist)
> > - Vote on the release (min. 3 +1 NO -1)
> > - Ask IPMC to check the release and have them vote on it
> > this is the needle, they tend to find things we have not thought about,
> > but Justin (he is one of the best release checkers in incubators)
> earlier
> > promised
> > me to do a pre-check so we avoid the normal errors.
> > - When the vote finally passes, move the source to the release part of
> dist.
> > - Congratulate each other with work well done.
> >
> > If we agree on the content and the idea of cutting a release, I volunteer
> > to do the work and
> > of course write about every step in here (and on the wiki), so we all
> learn
> > from the experience.
> > I do however need help from e.g. Dave, with some of the specialties.
> >
> > Following the suggestion from Dave, Let us discuss this until August 7th,
> > and then see
> > if we have reached consensus.
> >
> > Comments ?
> >
> > rgds
> > jan i.
>
Re: [PROPOSAL] make release 0.1
Posted by Dave Fisher <da...@comcast.net>.
Good plan. I will do my best to help. If we have 3 IPMC +1 from the podling then the IPMC part is less of a PITA.
Sent from my iPhone
> On Jul 30, 2015, at 7:21 AM, jan i <ja...@apache.org> wrote:
>
> Traditionally cutting the first apache release for a podling is one big
> PITA, therefore
> I propose we get started.
>
> I propose we make release 0.1 consisting of
> - docFormats (the library only with the OOXML filter)
> - dfTest (the main test utility)
> - dfUtil (the conversion utility)
>
> We have a lot to learn here, about the files LICENSES and NOTICE and about
> how to
> handle release candidates and the final release, therefore I propose to
> include the
> "stable" parts. It can be argued that version 0.1 is not very useful for a
> end-user, which
> might be right, but it helps us get the release framework up and running.
>
> Once we have 0.1 through the needle of IPMC, version 0.2 can focus a lot
> more on the
> technical content.
>
> The steps we have to pass (I have surely forgotten a number) are:
> - Make a branch (stable_0.1) that only contains what we intent to release
> - Make it work (adapt CMake files etc)
> - Correct LICENSES and NOTICE
> - Prepare a release candidate (upload source with SHA5 to somewhere on dist)
> - Vote on the release (min. 3 +1 NO -1)
> - Ask IPMC to check the release and have them vote on it
> this is the needle, they tend to find things we have not thought about,
> but Justin (he is one of the best release checkers in incubators) earlier
> promised
> me to do a pre-check so we avoid the normal errors.
> - When the vote finally passes, move the source to the release part of dist.
> - Congratulate each other with work well done.
>
> If we agree on the content and the idea of cutting a release, I volunteer
> to do the work and
> of course write about every step in here (and on the wiki), so we all learn
> from the experience.
> I do however need help from e.g. Dave, with some of the specialties.
>
> Following the suggestion from Dave, Let us discuss this until August 7th,
> and then see
> if we have reached consensus.
>
> Comments ?
>
> rgds
> jan i.
Re: [PROPOSAL] make release 0.1
Posted by Dave Fisher <da...@comcast.net>.
There is no reason to think that we cannot have our 3 +1 from the IPMC in our podling vote.
We already have more than 3 Apache Members.
Sent from my iPhone
> On Jul 30, 2015, at 2:23 PM, Dennis E. Hamilton <de...@acm.org> wrote:
>
> Thanks for the clarification.
>
> Of course, the Incubator PMC must also approve a podling release and there are constraints on how incubator releases may be announced and publicized.
>
> Those can call be checked into as 0.1 becomes ready enough.
>
> - Dennis
>
> -----Original Message-----
> From: Andrea Pescetti [mailto:pescetti@apache.org]
> Sent: Thursday, July 30, 2015 13:32
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [PROPOSAL] make release 0.1
>
>> On 30/07/2015 jan i wrote:
>> - Vote on the release (min. 3 +1 NO -1)
>
> This is very terse but it might be wrong: I don't know what you mean by
> "NO -1" but what happens is, probably, that one -1 from the [P]PMC
> cannot block a release. But again, the assumption at Apache is that
> people value community and collaboration over the rest. This is why you
> won't find a lot of instructions on how to behave if things go wrong
> from a "social" point of view.
>
> However, someone took the time to write it explicitly for top level
> projects: http://www.apache.org/dev/release.html#approving-a-release ;
> by analogy I think the Incubator should do the same (limited to the
> initial PPMC approval) but I haven't checked it.
>
> Regards,
> Andrea.
>
RE: [PROPOSAL] make release 0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Thanks for the clarification.
Of course, the Incubator PMC must also approve a podling release and there are constraints on how incubator releases may be announced and publicized.
Those can call be checked into as 0.1 becomes ready enough.
- Dennis
-----Original Message-----
From: Andrea Pescetti [mailto:pescetti@apache.org]
Sent: Thursday, July 30, 2015 13:32
To: dev@corinthia.incubator.apache.org
Subject: Re: [PROPOSAL] make release 0.1
On 30/07/2015 jan i wrote:
> - Vote on the release (min. 3 +1 NO -1)
This is very terse but it might be wrong: I don't know what you mean by
"NO -1" but what happens is, probably, that one -1 from the [P]PMC
cannot block a release. But again, the assumption at Apache is that
people value community and collaboration over the rest. This is why you
won't find a lot of instructions on how to behave if things go wrong
from a "social" point of view.
However, someone took the time to write it explicitly for top level
projects: http://www.apache.org/dev/release.html#approving-a-release ;
by analogy I think the Incubator should do the same (limited to the
initial PPMC approval) but I haven't checked it.
Regards,
Andrea.
Re: [PROPOSAL] make release 0.1
Posted by Andrea Pescetti <pe...@apache.org>.
On 30/07/2015 jan i wrote:
> - Vote on the release (min. 3 +1 NO -1)
This is very terse but it might be wrong: I don't know what you mean by
"NO -1" but what happens is, probably, that one -1 from the [P]PMC
cannot block a release. But again, the assumption at Apache is that
people value community and collaboration over the rest. This is why you
won't find a lot of instructions on how to behave if things go wrong
from a "social" point of view.
However, someone took the time to write it explicitly for top level
projects: http://www.apache.org/dev/release.html#approving-a-release ;
by analogy I think the Incubator should do the same (limited to the
initial PPMC approval) but I haven't checked it.
Regards,
Andrea.
Re: [PROPOSAL] make release 0.1
Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 20:33, Dennis E. Hamilton <de...@acm.org>
wrote:
> Isn't this limiting contributors to those mentioned in a commit log entry
> or who push files to the repository?
>
it is, but that is not the key. The key is that the file is not used for
tracking, but are generated from the logs.
rgds
jan i.
>
> - Dennis
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Saturday, August 1, 2015 11:06
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [PROPOSAL] make release 0.1
>
> On 1 August 2015 at 19:59, Andrea Pescetti <pe...@apache.org> wrote:
>
> > Peter Kelly wrote:
> >
> >> On 1 Aug 2015, at 10:18 pm, jan i wrote:
> >>> +1, I assume you mean the file contains the names of people who have
> >>> actively done commits on what is being released ?
> >>>
> >> Yes - everyone who’s name is present as an author or committer in the
> git
> >> log
> >>
> >
> > I've seen this debated somewhere. I don't remember the answer, but maybe
> > it's good to check with the Incubator PMC and ask. For sure it's stupid
> to
> > annotate the source files directly, and nobody is proposing this here. As
> > for a separate file with contributors, I find it totally reasonable but I
> > seem to recall a discussion saying that attribution at the ASF is tracked
> > exclusively in version control logs... I don't remember seeing a
> compelling
> > reason for that anyway.
> >
> I remember the debate, and the keyword here is "tracked". We cannot use
> CONTRIBUTORS to track e.g. people who do patches, that must in the version
> control itself.
>
> But we can extract from the version control and generate CONTRIBUTORS. In
> order to avoid discussions later (with IPMC), I would add a couple of
> sentences in the top of the file, explaining how it is generated.
>
> rgds
> jan i.
>
>
> >
> > Regards,
> > Andrea.
> >
>
>
RE: [PROPOSAL] make release 0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Isn't this limiting contributors to those mentioned in a commit log entry or who push files to the repository?
- Dennis
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Saturday, August 1, 2015 11:06
To: dev@corinthia.incubator.apache.org
Subject: Re: [PROPOSAL] make release 0.1
On 1 August 2015 at 19:59, Andrea Pescetti <pe...@apache.org> wrote:
> Peter Kelly wrote:
>
>> On 1 Aug 2015, at 10:18 pm, jan i wrote:
>>> +1, I assume you mean the file contains the names of people who have
>>> actively done commits on what is being released ?
>>>
>> Yes - everyone who’s name is present as an author or committer in the git
>> log
>>
>
> I've seen this debated somewhere. I don't remember the answer, but maybe
> it's good to check with the Incubator PMC and ask. For sure it's stupid to
> annotate the source files directly, and nobody is proposing this here. As
> for a separate file with contributors, I find it totally reasonable but I
> seem to recall a discussion saying that attribution at the ASF is tracked
> exclusively in version control logs... I don't remember seeing a compelling
> reason for that anyway.
>
I remember the debate, and the keyword here is "tracked". We cannot use
CONTRIBUTORS to track e.g. people who do patches, that must in the version
control itself.
But we can extract from the version control and generate CONTRIBUTORS. In
order to avoid discussions later (with IPMC), I would add a couple of
sentences in the top of the file, explaining how it is generated.
rgds
jan i.
>
> Regards,
> Andrea.
>
Re: [PROPOSAL] make release 0.1
Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 19:59, Andrea Pescetti <pe...@apache.org> wrote:
> Peter Kelly wrote:
>
>> On 1 Aug 2015, at 10:18 pm, jan i wrote:
>>> +1, I assume you mean the file contains the names of people who have
>>> actively done commits on what is being released ?
>>>
>> Yes - everyone who’s name is present as an author or committer in the git
>> log
>>
>
> I've seen this debated somewhere. I don't remember the answer, but maybe
> it's good to check with the Incubator PMC and ask. For sure it's stupid to
> annotate the source files directly, and nobody is proposing this here. As
> for a separate file with contributors, I find it totally reasonable but I
> seem to recall a discussion saying that attribution at the ASF is tracked
> exclusively in version control logs... I don't remember seeing a compelling
> reason for that anyway.
>
I remember the debate, and the keyword here is "tracked". We cannot use
CONTRIBUTORS to track e.g. people who do patches, that must in the version
control itself.
But we can extract from the version control and generate CONTRIBUTORS. In
order to avoid discussions later (with IPMC), I would add a couple of
sentences in the top of the file, explaining how it is generated.
rgds
jan i.
>
> Regards,
> Andrea.
>
Re: [PROPOSAL] make release 0.1
Posted by Andrea Pescetti <pe...@apache.org>.
Peter Kelly wrote:
>> On 1 Aug 2015, at 10:18 pm, jan i wrote:
>> +1, I assume you mean the file contains the names of people who have
>> actively done commits on what is being released ?
> Yes - everyone who’s name is present as an author or committer in the git log
I've seen this debated somewhere. I don't remember the answer, but maybe
it's good to check with the Incubator PMC and ask. For sure it's stupid
to annotate the source files directly, and nobody is proposing this
here. As for a separate file with contributors, I find it totally
reasonable but I seem to recall a discussion saying that attribution at
the ASF is tracked exclusively in version control logs... I don't
remember seeing a compelling reason for that anyway.
Regards,
Andrea.
Re: [PROPOSAL] make release 0.1
Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 18:11, Peter Kelly <pm...@apache.org> wrote:
> > On 1 Aug 2015, at 11:10 pm, Peter Kelly <pm...@apache.org> wrote:
> >
> >> On 1 Aug 2015, at 10:18 pm, jan i <ja...@apache.org> wrote:
> >>
> >>> Another thing I would like to suggest is we have a CONTRIBUTORS file
> (or
> >>> similar name) which lists all those who have contributed to the
> project.
> >>> I’m aware this isn’t strictly required, but I think it's a good way to
> give
> >>> credit/recognition to everyone involved for their work.
> >>>
> >> +1, I assume you mean the file contains the names of people who have
> >> actively done commits on what is being released ?
> >
> > Yes - everyone who’s name is present as an author or committer in the
> git log (or mentioned there as having been the author of a patch). I think
> a simple alphabetical listing of names & email addresses would be
> appropriate.
>
> BTW I volunteer to create this as well.
>
Could we agree to do it without email please and use our apache id.
If I understand it correctly our stable branch, also has all the commits,
so it is a simple matter of doing git log and extracting names.
I like the idea of using apache id alphabetical, I would not like any
indication of how much work each have done.
Question, we have had some code added (I added e.g. libraries) which are
gone again, can we easily limit the list to commits that are still in the
code ?
rgds
jan i.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: [PROPOSAL] make release 0.1
Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 19:49, Dennis E. Hamilton <de...@acm.org>
wrote:
> Some contributors may object to their email addresses being put in
> plaintext files.
>
> I don't have a workaround, and the ASF uses email addresses as identifiers
> and as part of code provenance.
>
> So long as there is a place where we can recover email addresses from the
> names we list, I think we can demonstrate provenance without publishing the
> email addresses directly.
>
Do you also publishing the apache id (which is a mail address as well) is a
problem, and would you prefer just their full name ?
>
> In general, we do not accept anonymous contributions, so there needs to be
> a way to handle the objections, whenever one arrives.
>
correct.
>
> It is probably better to figure this out now rather than wait until a
> contributor complains.
>
+1
rgds
jan i
>
> - Dennis
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Saturday, August 1, 2015 09:12
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [PROPOSAL] make release 0.1
>
> > On 1 Aug 2015, at 11:10 pm, Peter Kelly <pm...@apache.org> wrote:
> >
> >> On 1 Aug 2015, at 10:18 pm, jan i <ja...@apache.org> wrote:
> >>
> >>> Another thing I would like to suggest is we have a CONTRIBUTORS file
> (or
> >>> similar name) which lists all those who have contributed to the
> project.
> >>> I’m aware this isn’t strictly required, but I think it's a good way to
> give
> >>> credit/recognition to everyone involved for their work.
> >>>
> >> +1, I assume you mean the file contains the names of people who have
> >> actively done commits on what is being released ?
> >
> > Yes - everyone who’s name is present as an author or committer in the
> git log (or mentioned there as having been the author of a patch). I think
> a simple alphabetical listing of names & email addresses would be
> appropriate.
>
> BTW I volunteer to create this as well.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
>
Re: [PROPOSAL] make release 0.1
Posted by Peter Kelly <pm...@apache.org>.
I’m ok with just using names. The email addresses can be recovered anyway via git log.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 2 Aug 2015, at 12:49 am, Dennis E. Hamilton <de...@acm.org> wrote:
>
> Some contributors may object to their email addresses being put in plaintext files.
>
> I don't have a workaround, and the ASF uses email addresses as identifiers and as part of code provenance.
>
> So long as there is a place where we can recover email addresses from the names we list, I think we can demonstrate provenance without publishing the email addresses directly.
>
> In general, we do not accept anonymous contributions, so there needs to be a way to handle the objections, whenever one arrives.
>
> It is probably better to figure this out now rather than wait until a contributor complains.
>
> - Dennis
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Saturday, August 1, 2015 09:12
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [PROPOSAL] make release 0.1
>
>> On 1 Aug 2015, at 11:10 pm, Peter Kelly <pm...@apache.org> wrote:
>>
>>> On 1 Aug 2015, at 10:18 pm, jan i <ja...@apache.org> wrote:
>>>
>>>> Another thing I would like to suggest is we have a CONTRIBUTORS file (or
>>>> similar name) which lists all those who have contributed to the project.
>>>> I’m aware this isn’t strictly required, but I think it's a good way to give
>>>> credit/recognition to everyone involved for their work.
>>>>
>>> +1, I assume you mean the file contains the names of people who have
>>> actively done commits on what is being released ?
>>
>> Yes - everyone who’s name is present as an author or committer in the git log (or mentioned there as having been the author of a patch). I think a simple alphabetical listing of names & email addresses would be appropriate.
>
> BTW I volunteer to create this as well.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
RE: [PROPOSAL] make release 0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Some contributors may object to their email addresses being put in plaintext files.
I don't have a workaround, and the ASF uses email addresses as identifiers and as part of code provenance.
So long as there is a place where we can recover email addresses from the names we list, I think we can demonstrate provenance without publishing the email addresses directly.
In general, we do not accept anonymous contributions, so there needs to be a way to handle the objections, whenever one arrives.
It is probably better to figure this out now rather than wait until a contributor complains.
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Saturday, August 1, 2015 09:12
To: dev@corinthia.incubator.apache.org
Subject: Re: [PROPOSAL] make release 0.1
> On 1 Aug 2015, at 11:10 pm, Peter Kelly <pm...@apache.org> wrote:
>
>> On 1 Aug 2015, at 10:18 pm, jan i <ja...@apache.org> wrote:
>>
>>> Another thing I would like to suggest is we have a CONTRIBUTORS file (or
>>> similar name) which lists all those who have contributed to the project.
>>> I’m aware this isn’t strictly required, but I think it's a good way to give
>>> credit/recognition to everyone involved for their work.
>>>
>> +1, I assume you mean the file contains the names of people who have
>> actively done commits on what is being released ?
>
> Yes - everyone who’s name is present as an author or committer in the git log (or mentioned there as having been the author of a patch). I think a simple alphabetical listing of names & email addresses would be appropriate.
BTW I volunteer to create this as well.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [PROPOSAL] make release 0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 1 Aug 2015, at 11:10 pm, Peter Kelly <pm...@apache.org> wrote:
>
>> On 1 Aug 2015, at 10:18 pm, jan i <ja...@apache.org> wrote:
>>
>>> Another thing I would like to suggest is we have a CONTRIBUTORS file (or
>>> similar name) which lists all those who have contributed to the project.
>>> I’m aware this isn’t strictly required, but I think it's a good way to give
>>> credit/recognition to everyone involved for their work.
>>>
>> +1, I assume you mean the file contains the names of people who have
>> actively done commits on what is being released ?
>
> Yes - everyone who’s name is present as an author or committer in the git log (or mentioned there as having been the author of a patch). I think a simple alphabetical listing of names & email addresses would be appropriate.
BTW I volunteer to create this as well.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [PROPOSAL] make release 0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 1 Aug 2015, at 10:18 pm, jan i <ja...@apache.org> wrote:
>
>> Another thing I would like to suggest is we have a CONTRIBUTORS file (or
>> similar name) which lists all those who have contributed to the project.
>> I’m aware this isn’t strictly required, but I think it's a good way to give
>> credit/recognition to everyone involved for their work.
>>
> +1, I assume you mean the file contains the names of people who have
> actively done commits on what is being released ?
Yes - everyone who’s name is present as an author or committer in the git log (or mentioned there as having been the author of a patch). I think a simple alphabetical listing of names & email addresses would be appropriate.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [PROPOSAL] make release 0.1
Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 17:15, Peter Kelly <pm...@apache.org> wrote:
> Sounds like a good plan to me.
>
> I volunteer to write the README - I think what we have on the website/wiki
> is a little unclear at the moment, and have some ideas on how to better
> express what the project’s about.
>
super, then we can later update the website/wiki or you do it the other way
round, whatever you prefer.
>
> I suggest we do this (along with LICENSES and NOTICE) as files in the root
> of the Git repository, so we can each make changes via the usual means as
> for code.
>
+1
>
> Another thing I would like to suggest is we have a CONTRIBUTORS file (or
> similar name) which lists all those who have contributed to the project.
> I’m aware this isn’t strictly required, but I think it's a good way to give
> credit/recognition to everyone involved for their work.
>
+1, I assume you mean the file contains the names of people who have
actively done commits on what is being released ?
rgds
jan i.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
> > On 30 Jul 2015, at 9:21 pm, jan i <ja...@apache.org> wrote:
> >
> > Traditionally cutting the first apache release for a podling is one big
> > PITA, therefore
> > I propose we get started.
> >
> > I propose we make release 0.1 consisting of
> > - docFormats (the library only with the OOXML filter)
> > - dfTest (the main test utility)
> > - dfUtil (the conversion utility)
> >
> > We have a lot to learn here, about the files LICENSES and NOTICE and
> about
> > how to
> > handle release candidates and the final release, therefore I propose to
> > include the
> > "stable" parts. It can be argued that version 0.1 is not very useful for
> a
> > end-user, which
> > might be right, but it helps us get the release framework up and running.
> >
> > Once we have 0.1 through the needle of IPMC, version 0.2 can focus a lot
> > more on the
> > technical content.
> >
> > The steps we have to pass (I have surely forgotten a number) are:
> > - Make a branch (stable_0.1) that only contains what we intent to release
> > - Make it work (adapt CMake files etc)
> > - Correct LICENSES and NOTICE
> > - Prepare a release candidate (upload source with SHA5 to somewhere on
> dist)
> > - Vote on the release (min. 3 +1 NO -1)
> > - Ask IPMC to check the release and have them vote on it
> > this is the needle, they tend to find things we have not thought about,
> > but Justin (he is one of the best release checkers in incubators)
> earlier
> > promised
> > me to do a pre-check so we avoid the normal errors.
> > - When the vote finally passes, move the source to the release part of
> dist.
> > - Congratulate each other with work well done.
> >
> > If we agree on the content and the idea of cutting a release, I volunteer
> > to do the work and
> > of course write about every step in here (and on the wiki), so we all
> learn
> > from the experience.
> > I do however need help from e.g. Dave, with some of the specialties.
> >
> > Following the suggestion from Dave, Let us discuss this until August 7th,
> > and then see
> > if we have reached consensus.
> >
> > Comments ?
> >
> > rgds
> > jan i.
>
>
Re: [PROPOSAL] make release 0.1
Posted by Peter Kelly <pm...@apache.org>.
Sounds like a good plan to me.
I volunteer to write the README - I think what we have on the website/wiki is a little unclear at the moment, and have some ideas on how to better express what the project’s about.
I suggest we do this (along with LICENSES and NOTICE) as files in the root of the Git repository, so we can each make changes via the usual means as for code.
Another thing I would like to suggest is we have a CONTRIBUTORS file (or similar name) which lists all those who have contributed to the project. I’m aware this isn’t strictly required, but I think it's a good way to give credit/recognition to everyone involved for their work.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 30 Jul 2015, at 9:21 pm, jan i <ja...@apache.org> wrote:
>
> Traditionally cutting the first apache release for a podling is one big
> PITA, therefore
> I propose we get started.
>
> I propose we make release 0.1 consisting of
> - docFormats (the library only with the OOXML filter)
> - dfTest (the main test utility)
> - dfUtil (the conversion utility)
>
> We have a lot to learn here, about the files LICENSES and NOTICE and about
> how to
> handle release candidates and the final release, therefore I propose to
> include the
> "stable" parts. It can be argued that version 0.1 is not very useful for a
> end-user, which
> might be right, but it helps us get the release framework up and running.
>
> Once we have 0.1 through the needle of IPMC, version 0.2 can focus a lot
> more on the
> technical content.
>
> The steps we have to pass (I have surely forgotten a number) are:
> - Make a branch (stable_0.1) that only contains what we intent to release
> - Make it work (adapt CMake files etc)
> - Correct LICENSES and NOTICE
> - Prepare a release candidate (upload source with SHA5 to somewhere on dist)
> - Vote on the release (min. 3 +1 NO -1)
> - Ask IPMC to check the release and have them vote on it
> this is the needle, they tend to find things we have not thought about,
> but Justin (he is one of the best release checkers in incubators) earlier
> promised
> me to do a pre-check so we avoid the normal errors.
> - When the vote finally passes, move the source to the release part of dist.
> - Congratulate each other with work well done.
>
> If we agree on the content and the idea of cutting a release, I volunteer
> to do the work and
> of course write about every step in here (and on the wiki), so we all learn
> from the experience.
> I do however need help from e.g. Dave, with some of the specialties.
>
> Following the suggestion from Dave, Let us discuss this until August 7th,
> and then see
> if we have reached consensus.
>
> Comments ?
>
> rgds
> jan i.