You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2013/11/27 21:45:51 UTC
Release Verification Checklist
Greets,
In response to Bertrand's proposal at <http://s.apache.org/awz>, I've created
a draft release verification checklist:
http://wiki.apache.org/incubator/ReleaseChecklist
It should be emphasized that completing a checklist like this at release
points is only one aspect of exercising proper IP stewardship over a codebase.
The checklist says nothing about code provenance, and while it may catch
licensing documentation bugs, it does little to guard against the possibility
of actual licensing violations: bogus header swaps, "borrowed" code pasted
into files with different licensing, and so on. We don't generally encounter
such problems at Apache, but we need to stay vigilant.
Design notes:
* Brevity is important for ease of use. We don't want to explain what makes
for a valid LICENSE and NOTICE in a checklist.
* +0 and -0 votes are rare, so they are omitted from the template.
* All checklist items are optional. Of course if you leave everything
unchecked, your indifference is going to be entered into the record.
* The dictate that all checklist items are optional is explicitly included
in the template despite wasting precious space, because otherwise PPMC
confusion will cause needless stress and wasted time.
* Podlings may wish to augment this template with project-specific
modifications, e.g. "Extended tests pass", "RAT report clean".
* The `Apache ID` field is intended to allow whoever enters these checklists
into the record to copy-and-paste verbatim without having to look up
credentials. Hopefully people will actually fill it in regularly.
* There is no field identifying the release candidate because that
information will be carried by email subject, filepath in version control,
etc.
* The checklist text is designed for quick copy/paste into an email. It
must take up as little vertical space as possible so that it is easy to
select with a mouse/trackpad gesture.
* The textual layout is intended to stack cleanly and to look good when
rendered using either fixed-width or variable-width fonts.
Thoughts?
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Dec 3, 2013 at 11:42 PM, ant elder <an...@gmail.com> wrote:
> Just fyi so I'm not accused of not saying anything - I'm not totally sure
> what the intention is for this and I'm all for doing some experiments and
> wouldn't get in the way if this is to be tried with a podling, however this
> looks like its becoming a fairly complex and arduous process to me.
That depends on whether or not we hold the line on what goes into the
checklist.
If the checklist consists solely of stuff that blocks the release -- stuff
that podlings and Mentors need to be doing *anyway* -- then the only added
overhead is some bookkeeping around voting. I don't think that's unreasonable
at all, especially since participating in the extra ceremony serves a training
purpose for PPMC members.
On the other hand, if the checklist gets larded up with stuff that has no
direct connection to the release[1], then I would agree we are layering extra
tasks on top of the release process and making it needlessly "arduous and
complex".
With regards to the purpose of this thread, it is primarily to explore how we
would implement Bertrand's proposal. Eventually, I plan to codify that
proposal as a diff against our policy page. I expect that the policy change
proposal diff will not contain the full checklist, but will make abstract
reference to a checklist hosted elsewhere on the Incubator website -- allowing
for modifications to the checklist and release process by lazy consensus
rather than majority-rule policy vote. Under this scheme, the checklist only
needs to be workable, not perfect, in order to proceed to PROPOSAL and VOTE.
Marvin Humphrey
[1] Does a community which is not "healthy" block the release? How do you fix
that in a timely manner so you can get your release out?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
Just fyi so I'm not accused of not saying anything - I'm not totally sure
what the intention is for this and I'm all for doing some experiments and
wouldn't get in the way if this is to be tried with a podling, however this
looks like its becoming a fairly complex and arduous process to me.
...ant
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Dec 1, 2013 at 3:46 PM, sebb <se...@gmail.com> wrote:
>> Can you live with this second draft?
>
> I don't understand what this means:
>
> ASF copyright correct in each top-level NOTICE.
>
> Why is it necessary in addition to the following?
>
> Top-level LICENSE and NOTICE correct for each distribution.
The awkwardness of that line is an artifact of how the checklist has evolved.
At this point, I agree that it's become superfluous, so I've deleted it.
> I think there needs to be a separate list of explanations that detail
> the checks.
+1
So be it, as long as the checklist itself stays concise.
I've now deleted the first draft, as I assume that no one will object to
moving forward with the second draft accommodating multiple archives.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by sebb <se...@gmail.com>.
On 1 December 2013 19:09, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Fri, Nov 29, 2013 at 1:33 PM, sebb <se...@gmail.com> wrote:
>> Not sure I understand why the checklist needs to be specific.
>
> The checklist should include only items which might block the release of the
> artifacts under review. Expanding it to include unrelated concerns imposes an
> unnecessary cost each time someone goes through the checklist.
>
> Let's not make the release process any harder than it needs to be.
Which is easier?
- have one checklist with some items that don't apply to all release votes
- have separate checklists for releases with and without binary artifacts
>> It does not necessarily need to be a separate check item.
>> Just a reminder that the N&L files are specific to the distributed
>> items (SCM or release artifact).
>
> I'm apprehensive that a single checklist which tries to be all things to all
> projects will ultimately prove unworkable. The design pressure is building
> and eventually, customization will be the only answer.
AFAICT there are only two different kinds of release votes:
- SCM and source
- SCM, source and convenience binaries
> Nevertheless, I've added a second draft to
> http://wiki.apache.org/incubator/ReleaseChecklist which attempts to address
> your concerns. Here are some of the changes:
>
> * Pluralize a few items to allow for the possibility that the release
> candidate VOTE encompasses multiple archives -- accommodating both
> projects which release multiple source archives simultaneously and
> projects which make convenience binaries available.
> * Require that LICENCE and NOTICE be "correct for each distribution". To my
> mind this is superfluous because it was implied by "correct", but it's
> certainly something that projects get wrong a lot.
The issue is that the N&L files may need to be diffferent for the
binary artifacts.
This is often overlooked.
> * Simplify the testing checklist item to `[ ] All tests pass.` This is
> weaker, in that it does not require building and testing of the *source*
> archive, but it is more compatible with more configurations. The
> checklist item shouldn't require that all tests pass for *all* archives,
> because that doesn't work with platform-specific binaries; this language
> was the best general compromise I could come up with.
> * Change the "license headers" item to specify "source files", in order to
> resolve an incidental ambiguity with regards to whether "files" meant
> archive files or source files.
>
> Can you live with this second draft?
I don't understand what this means:
ASF copyright correct in each top-level NOTICE.
Why is it necessary in addition to the following?
Top-level LICENSE and NOTICE correct for each distribution.
I think there needs to be a separate list of explanations that detail
the checks.
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Dave Fisher <da...@comcast.net>.
On Dec 1, 2013, at 4:47 PM, Marvin Humphrey wrote:
> On Sun, Dec 1, 2013 at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>> One note I have is I don't think we should be teaching that some of release
>> steps are "optional" when they are required.
>
> Don't get me wrong -- I would actually prefer to make each PPMC member do the
> work for each item. The main rationale behind making the checklist items
> "optional" is something else: to avoid adding yet more design pressure onto
> the checklist. Making all items "required" means that we have to anticipate
> all possible edge cases in advance, lest we make it impossible to vote for a
> release which would otherwise pass but gets hung up on a technicality.
I'll agree that there is a balance between confronting a long list and trying to get it done. I'll submit that we do need to know the podling gets it. I've seen instances where TLP's have new members who need to be taught this curriculum as well.
>
> How about building in a different safety valve?
>
> - Checklist (all items optional, mark only those personally verified):
> + Checklist (mark only items personally verified; items left unchecked must
> + be explained in "Notes"):
I think that this will work. It encourages PPMC members to do the "required" activities without overly penalizing them for failure.
>
>> If we are using the checklist as a way to test and measure the podling for
>> graduation then I would add the following checkboxes.
>
> I don't think we should add any design requirement that does not pertain to
> voting on the release artifacts. It is already extremely challenging
> attempting to meet all the absolute requirements being presented by various
> discussion participants.
My additions are trivially easier than all other items. These serve to identify the voter and help IPMC members save time when vetting a release.
Regards,
Dave
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Alex Harui <ah...@adobe.com>.
On 12/1/13 4:47 PM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
>On Sun, Dec 1, 2013 at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>> One note I have is I don't think we should be teaching that some of
>>release
>> steps are "optional" when they are required.
>
>Don't get me wrong -- I would actually prefer to make each PPMC member do
>the
>work for each item. The main rationale behind making the checklist items
>"optional" is something else: to avoid adding yet more design pressure
>onto
>the checklist. Making all items "required" means that we have to
>anticipate
>all possible edge cases in advance, lest we make it impossible to vote
>for a
>release which would otherwise pass but gets hung up on a technicality.
Just curious: how do you know someone didn't just copy-paste the form with
boxes already checked? Can we not make a tool that performs these checks?
IMO, make everything required. Let the mentors or other IPMC members
grant exceptions if you hit edge cases. This is just an experiment, not
new policy that will be in place forever, right?
FWIW, I would also drop the "all tests passed". That would make it easier
to create a tool that checks everything else. I'm pretty sure our mentors
never ran the tests. The PPMC members are probably sufficiently invested
in making sure quality is sufficient, one way or another. For Flex, we
didn't even have all tests donated to the repo for our first release. I
ran the artifacts against the Adobe copy of the tests, but no non-Adobe
folks had such an opportunity.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Dec 1, 2013 at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
> One note I have is I don't think we should be teaching that some of release
> steps are "optional" when they are required.
Don't get me wrong -- I would actually prefer to make each PPMC member do the
work for each item. The main rationale behind making the checklist items
"optional" is something else: to avoid adding yet more design pressure onto
the checklist. Making all items "required" means that we have to anticipate
all possible edge cases in advance, lest we make it impossible to vote for a
release which would otherwise pass but gets hung up on a technicality.
How about building in a different safety valve?
- Checklist (all items optional, mark only those personally verified):
+ Checklist (mark only items personally verified; items left unchecked must
+ be explained in "Notes"):
> If we are using the checklist as a way to test and measure the podling for
> graduation then I would add the following checkboxes.
I don't think we should add any design requirement that does not pertain to
voting on the release artifacts. It is already extremely challenging
attempting to meet all the absolute requirements being presented by various
discussion participants.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Dave Fisher <da...@comcast.net>.
Marvin,
I applaud your efforts here. If we are going to take PPMC release votes as binding then we should be sure that these are up to standards. Even if we don't this is still very valuable.
One note I have is I don't think we should be teaching that some of release steps are "optional" when they are required.
> Checklist (all items optional, mark only those personally verified):
A big issue in podlings (and TLPs) is making sure that enough PPMC members actually do the following checks by understanding that they are required:
> [ ] Checksums and PGP signatures are valid.
> [ ] Each expanded source archive matches content in SCM beneath RC tag.
> [ ] Incubation disclaimers correct and filenames include "incubating".
> [ ] Top-level LICENSE and NOTICE correct for each distribution.
> [ ] ASF copyright correct in each top-level NOTICE.
> [ ] All source files have license headers where appropriate.
The above should be checked. The following item ought to be checked by most of the PPMC as an indication of podling maturity.
> [ ] I follow this project's commits list.
The following are similar, but more tranisitional - for many podlings these are not issues or are easily resolved. For some podlings though these are more difficult and can require multiple releases to satisfy properly.
> [ ] All dependencies have compatible licenses.
> [ ] No compiled archives bundled in a source archive.
Legally optional:
> [ ] All tests pass.
If we are using the checklist as a way to test and measure the podling for graduation then I would add the following checkboxes.
[ ] Initial PPMC member.
[ ] Added PPMC member.
[ ] Podling Mentor.
[ ] IPMC member.
If a podling cannot get the proper 3 +1 votes from the future PMC then the IPMC should not recommend graduation to the Board.
Regards,
Dave
>
>
On Dec 1, 2013, at 11:09 AM, Marvin Humphrey wrote:
> On Fri, Nov 29, 2013 at 1:33 PM, sebb <se...@gmail.com> wrote:
>> Not sure I understand why the checklist needs to be specific.
>
> The checklist should include only items which might block the release of the
> artifacts under review. Expanding it to include unrelated concerns imposes an
> unnecessary cost each time someone goes through the checklist.
>
> Let's not make the release process any harder than it needs to be.
>
>> It does not necessarily need to be a separate check item.
>> Just a reminder that the N&L files are specific to the distributed
>> items (SCM or release artifact).
>
> I'm apprehensive that a single checklist which tries to be all things to all
> projects will ultimately prove unworkable. The design pressure is building
> and eventually, customization will be the only answer.
>
> Nevertheless, I've added a second draft to
> http://wiki.apache.org/incubator/ReleaseChecklist which attempts to address
> your concerns. Here are some of the changes:
>
> * Pluralize a few items to allow for the possibility that the release
> candidate VOTE encompasses multiple archives -- accommodating both
> projects which release multiple source archives simultaneously and
> projects which make convenience binaries available.
> * Require that LICENCE and NOTICE be "correct for each distribution". To my
> mind this is superfluous because it was implied by "correct", but it's
> certainly something that projects get wrong a lot.
> * Simplify the testing checklist item to `[ ] All tests pass.` This is
> weaker, in that it does not require building and testing of the *source*
> archive, but it is more compatible with more configurations. The
> checklist item shouldn't require that all tests pass for *all* archives,
> because that doesn't work with platform-specific binaries; this language
> was the best general compromise I could come up with.
> * Change the "license headers" item to specify "source files", in order to
> resolve an incidental ambiguity with regards to whether "files" meant
> archive files or source files.
>
> Can you live with this second draft?
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Nov 29, 2013 at 1:33 PM, sebb <se...@gmail.com> wrote:
> Not sure I understand why the checklist needs to be specific.
The checklist should include only items which might block the release of the
artifacts under review. Expanding it to include unrelated concerns imposes an
unnecessary cost each time someone goes through the checklist.
Let's not make the release process any harder than it needs to be.
> It does not necessarily need to be a separate check item.
> Just a reminder that the N&L files are specific to the distributed
> items (SCM or release artifact).
I'm apprehensive that a single checklist which tries to be all things to all
projects will ultimately prove unworkable. The design pressure is building
and eventually, customization will be the only answer.
Nevertheless, I've added a second draft to
http://wiki.apache.org/incubator/ReleaseChecklist which attempts to address
your concerns. Here are some of the changes:
* Pluralize a few items to allow for the possibility that the release
candidate VOTE encompasses multiple archives -- accommodating both
projects which release multiple source archives simultaneously and
projects which make convenience binaries available.
* Require that LICENCE and NOTICE be "correct for each distribution". To my
mind this is superfluous because it was implied by "correct", but it's
certainly something that projects get wrong a lot.
* Simplify the testing checklist item to `[ ] All tests pass.` This is
weaker, in that it does not require building and testing of the *source*
archive, but it is more compatible with more configurations. The
checklist item shouldn't require that all tests pass for *all* archives,
because that doesn't work with platform-specific binaries; this language
was the best general compromise I could come up with.
* Change the "license headers" item to specify "source files", in order to
resolve an incidental ambiguity with regards to whether "files" meant
archive files or source files.
Can you live with this second draft?
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by sebb <se...@gmail.com>.
On 29 November 2013 21:00, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Wed, Nov 27, 2013 at 5:13 PM, sebb <se...@gmail.com> wrote:
>
>> The N&L files also apply to the SCM tree;
>
> Yes, true. Here's a message from Doug Cutting to legal-discuss@apache
> on the subject: http://s.apache.org/9r7>.
>
> In my view, it's appropriate for someone reviewing a release to comment on
> whether the SCM tree has proper LICENSE and NOTICE files. However, I don't
> think that should be a checklist item because the checklist should be specific
> to the release artifacts.
Not sure I understand why the checklist needs to be specific.
> Now, there's another checklist item to which the same critique applies:
>
> [ ] I follow this project's commits list.
>
> I would rather delete this item and be consistent than expand the checklist
> with more such items.
>
>> further the N&L files may be different for the binary archive (if provided)
>
> We should allow podlings which choose to perform quality control on
> convenience binaries to customize their own checklists with additional items
> as they see fit. However, since 1) only the source archive is officially a
> release by the ASF, and 2) not all podlings make convenience binaries
> available, the default checklist should concern itself with the source archive
> alone.
But if a project does release binaries, these must have valid N&L files.
> Nevertheless, convenience binaries have their own set of common problems
> (including incorrect N&L) which I anticipate we will want to address through
> documentation suggesting a specific block of additional checklist items.
It does not necessarily need to be a separate check item.
Just a reminder that the N&L files are specific to the distributed
items (SCM or release artifact).
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Nov 27, 2013 at 5:13 PM, sebb <se...@gmail.com> wrote:
> The N&L files also apply to the SCM tree;
Yes, true. Here's a message from Doug Cutting to legal-discuss@apache
on the subject: http://s.apache.org/9r7>.
In my view, it's appropriate for someone reviewing a release to comment on
whether the SCM tree has proper LICENSE and NOTICE files. However, I don't
think that should be a checklist item because the checklist should be specific
to the release artifacts.
Now, there's another checklist item to which the same critique applies:
[ ] I follow this project's commits list.
I would rather delete this item and be consistent than expand the checklist
with more such items.
> further the N&L files may be different for the binary archive (if provided)
We should allow podlings which choose to perform quality control on
convenience binaries to customize their own checklists with additional items
as they see fit. However, since 1) only the source archive is officially a
release by the ASF, and 2) not all podlings make convenience binaries
available, the default checklist should concern itself with the source archive
alone.
Nevertheless, convenience binaries have their own set of common problems
(including incorrect N&L) which I anticipate we will want to address through
documentation suggesting a specific block of additional checklist items.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by sebb <se...@gmail.com>.
On 27 November 2013 20:45, Marvin Humphrey <ma...@rectangular.com> wrote:
> Greets,
>
> In response to Bertrand's proposal at <http://s.apache.org/awz>, I've created
> a draft release verification checklist:
>
> http://wiki.apache.org/incubator/ReleaseChecklist
>
> It should be emphasized that completing a checklist like this at release
> points is only one aspect of exercising proper IP stewardship over a codebase.
> The checklist says nothing about code provenance, and while it may catch
> licensing documentation bugs, it does little to guard against the possibility
> of actual licensing violations: bogus header swaps, "borrowed" code pasted
> into files with different licensing, and so on. We don't generally encounter
> such problems at Apache, but we need to stay vigilant.
>
> Design notes:
>
> * Brevity is important for ease of use. We don't want to explain what makes
> for a valid LICENSE and NOTICE in a checklist.
> * +0 and -0 votes are rare, so they are omitted from the template.
> * All checklist items are optional. Of course if you leave everything
> unchecked, your indifference is going to be entered into the record.
> * The dictate that all checklist items are optional is explicitly included
> in the template despite wasting precious space, because otherwise PPMC
> confusion will cause needless stress and wasted time.
> * Podlings may wish to augment this template with project-specific
> modifications, e.g. "Extended tests pass", "RAT report clean".
> * The `Apache ID` field is intended to allow whoever enters these checklists
> into the record to copy-and-paste verbatim without having to look up
> credentials. Hopefully people will actually fill it in regularly.
> * There is no field identifying the release candidate because that
> information will be carried by email subject, filepath in version control,
> etc.
> * The checklist text is designed for quick copy/paste into an email. It
> must take up as little vertical space as possible so that it is easy to
> select with a mouse/trackpad gesture.
> * The textual layout is intended to stack cleanly and to look good when
> rendered using either fixed-width or variable-width fonts.
>
> Thoughts?
The N&L files also apply to the SCM tree; further the N&L files may be
different for the binary archive (if provided)
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Nov 27, 2013 at 3:55 PM, David Crossley <cr...@apache.org> wrote:
> Marvin Humphrey wrote:
>> [ ] Incubation disclaimer is present and correct.
>
> There is also the naming of the release, which must have "incubating"
> in its name. As Clutch tries to report, many projects neglect that.
> Perhaps change that item to either:
> [ ] Incubation disclaimers are present and correct.
> or
> [ ] Incubation disclaimer is correct and filename includes "incubating".
Nice catch! I prefer your second formulation for its clarity. I've updated
the draft.
(FWIW, `disclaimer` is lowercased because while it "SHOULD" be in in a file
named `DISCLAIMER`, it doesn't have to be[1].)
Marvin Humphrey
[1] http://incubator.apache.org/guides/branding.html#disclaimers
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by David Crossley <cr...@apache.org>.
Marvin Humphrey wrote:
>
> In response to Bertrand's proposal at <http://s.apache.org/awz>, I've created
> a draft release verification checklist:
>
> http://wiki.apache.org/incubator/ReleaseChecklist
Thnaks for your huge efforts Marvin.
> [ ] Incubation disclaimer is present and correct.
There is also the naming of the release, which must have "incubating"
in its name. As Clutch tries to report, many projects neglect that.
Perhaps change that item to either:
[ ] Incubation disclaimers are present and correct.
or
[ ] Incubation disclaimer is correct and filename includes "incubating".
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Dec 2, 2013 at 8:17 PM, sebb <se...@gmail.com> wrote:
> On 2 December 2013 13:52, Bertrand Delacretaz <bd...@apache.org> wrote:
>> ...I think managing and keeping such release manifests in svn, at least
>> for incubating projects, would make the release process much clearer
>> and easier to understand.
>
> But it is much harder to update an SVN document compared with replying
> to an e-mail....
Compared to the work involved in reviewing a release, I don't think an
svn update/commit is too much to ask.
Also, having the release manifests in svn is a good example for future
podlings to look at.
But if people think that's too hard, we can also try in email.
>
> If the proposal is adopted, then I think the comments should be signed
> with ASF ids rather than initials (which may be ambiguous)
Good point, agreed.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Dave Fisher <da...@comcast.net>.
There is a small negative to this process. How do non-committers VOTE on releases?
This doesn't make me negative, but we ought to have an explanation.
On Dec 3, 2013, at 4:31 PM, Marvin Humphrey wrote:
> On Tue, Dec 3, 2013 at 7:07 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>
>> Which we already have at
>> http://svn.apache.org/repos/asf/incubator/public/trunk/ - podlings are
>> already supposed to keep their info up to date there.
>
> I suggest putting votes here:
>
> http://svn.apache.org/repos/asf/incubator/public/trunk/votes/$PODLING/$RC
>
> PS: The commits list is cvs@incubator, which I don't think many people know
> about based on how often David Crossley has to remind people to publish
> their own changes to the Incubator website.
If we have a daemon watch the commit list that process could send emails to the podling dev ML and/or general ML providing an email thread like podlings are used to receiving and discussing.
Add $RC starts a Vote.
Modify $RC shows a Vote.
Changes in the state of the $RC. Passed, Canceled, Released, In-Progress, etc. would have special emails.
Regards,
Dave
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sun, Dec 8, 2013 at 10:02 PM, Dave Fisher <da...@comcast.net> wrote:
> ...I think two more improvements are needed:
>
> (1) PPMC members should be sure to record the votes of community members who are not PPMC/committers and have no apache id.
> (2) The header should include a reference to the VOTE thread...
IMO you need only (2) as this covers (1) by reference and avoids
duplicating information.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Dave Fisher <da...@comcast.net>.
On Dec 6, 2013, at 8:53 AM, Roman Shaposhnik wrote:
> On Thu, Dec 5, 2013 at 2:32 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> On Wed, Dec 4, 2013 at 1:31 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>>>
>>> http://svn.apache.org/repos/asf/incubator/public/trunk/votes/$PODLING/$RC ...
>>
>> Added to a new "usage proposal" section at
>> https://wiki.apache.org/incubator/ReleaseChecklist - does that
>> proposal work for you guys?
>
> I like it. It basically looks like sebb-in-a-box to me (or should
> be elastic sebb these days?) ;-)
I like it. I think two more improvements are needed:
(1) PPMC members should be sure to record the votes of community members who are not PPMC/committers and have no apache id.
(2) The header should include a reference to the VOTE thread.
Adding the community votes and thread reference can help the IPMC assess the other major graduation criteria - community viability and growth. We need to assess sustainability.
Regards,
Dave
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Dec 13, 2013 at 6:42 PM, sebb <se...@gmail.com> wrote:
> The current source release artifacts must be released via the ASF mirroring
> system. Download pages must not point directly to the ASF servers; they
> must use the mirror CGI scripts Also old releases must not be left on the
> mirroring system; any download links must use the ASF archive server. The
> download pages must also include links to sigs and hashes and the KEYS file,
> all of which must be on the ASF servers (not via mirrors).
I agree that these are all important, but as they are not directly related to
the release artifacts and do not block a release, they belong in a different
checklist.
I've started a GraduationChecklist wiki page so that the suggestions do not
get lost.
https://wiki.apache.org/incubator/GraduationChecklist
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by sebb <se...@gmail.com>.
Just discovered another important aspect of a release that is often overlooked.
The current source release artifacts must be released via the ASF
mirroring system.
Download pages must not point directly to the ASF servers; they must
use the mirror CGI scripts
Also old releases must not be left on the mirroring system; any
download links must use the ASF archive server.
The download pages must also include links to sigs and hashes and the
KEYS file, all of which must be on the ASF servers (not via mirrors).
There were at least two recent graduations that do (did) not follow these rules.
One provided links to the SVN dist/release area, the other links
directly to www.apache.org/dist
On 13 December 2013 17:48, ant elder <an...@gmail.com> wrote:
> The N word wasn't particularly helpful or constructive, sorry. I do think
> the policy page should be kept simple and generic though, so isn't the
> place to be describing this experiment.
>
> ...ant
>
>
> On Fri, Dec 13, 2013 at 3:39 PM, ant elder <an...@gmail.com> wrote:
>
>> Well sorry but IMHO thats nonsense. The Maven decision was an isolated
>> incident and didn't change the way all future Incubator policy should
>> get decided. Insisting that this experiment is done via a change to
>> the main policy just makes it contentious when it doesn't need to be.
>> All the complexity in the language and approach, the three votes etc
>> is exactly why people get the idea that the ASF is a ridiculous place
>> with overbearing rules and process. Its just an experiment, use lazy
>> majority consensus and go try it with a podling.
>>
>> ...ant
>>
>> On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey <ma...@rectangular.com>
>> wrote:
>> > On Fri, Dec 13, 2013 at 12:18 AM, ant elder <an...@gmail.com> wrote:
>> >> I'm also opposed to updating the policy document, so will be voting
>> against
>> >> this just for that. Its just an experiment so you don't need to be
>> making a
>> >> permanent change to the policy page to try it, especially as its such a
>> >> clunky convoluted change.
>> >
>> > An explicit policy change is required because otherwise there would be
>> > ambiguity as to whether a release which passes under the modified regime
>> is an
>> > act of the Foundation and confers indemnity on the Release Manager.
>> >
>> > The language of the proposed change to the Policy page has been carefully
>> > composed. It is highly isolated from the rest of our policy and has no
>> force
>> > except on the the experiment.
>> >
>> > This proposal is structured as an incremental, reversible change. It is
>> > incremental because podlings must be opted in by vote of the IPMC to
>> > participate. It is reversible because once the experiment has run its
>> course
>> > the relevant section of the policy page can be removed with zero impact
>> > through lazy consensus.
>> >
>> >> (And responding to another related comment in the thread - since when
>> have
>> >> policy updates not required consensus?)
>> >
>> > The 2008 proposal to allow distribution through Maven was enacted after a
>> > contentious majority-rule vote passed 15 to 12.
>> >
>> > Marvin Humphrey
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
The N word wasn't particularly helpful or constructive, sorry. I do think
the policy page should be kept simple and generic though, so isn't the
place to be describing this experiment.
...ant
On Fri, Dec 13, 2013 at 3:39 PM, ant elder <an...@gmail.com> wrote:
> Well sorry but IMHO thats nonsense. The Maven decision was an isolated
> incident and didn't change the way all future Incubator policy should
> get decided. Insisting that this experiment is done via a change to
> the main policy just makes it contentious when it doesn't need to be.
> All the complexity in the language and approach, the three votes etc
> is exactly why people get the idea that the ASF is a ridiculous place
> with overbearing rules and process. Its just an experiment, use lazy
> majority consensus and go try it with a podling.
>
> ...ant
>
> On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
> > On Fri, Dec 13, 2013 at 12:18 AM, ant elder <an...@gmail.com> wrote:
> >> I'm also opposed to updating the policy document, so will be voting
> against
> >> this just for that. Its just an experiment so you don't need to be
> making a
> >> permanent change to the policy page to try it, especially as its such a
> >> clunky convoluted change.
> >
> > An explicit policy change is required because otherwise there would be
> > ambiguity as to whether a release which passes under the modified regime
> is an
> > act of the Foundation and confers indemnity on the Release Manager.
> >
> > The language of the proposed change to the Policy page has been carefully
> > composed. It is highly isolated from the rest of our policy and has no
> force
> > except on the the experiment.
> >
> > This proposal is structured as an incremental, reversible change. It is
> > incremental because podlings must be opted in by vote of the IPMC to
> > participate. It is reversible because once the experiment has run its
> course
> > the relevant section of the policy page can be removed with zero impact
> > through lazy consensus.
> >
> >> (And responding to another related comment in the thread - since when
> have
> >> policy updates not required consensus?)
> >
> > The 2008 proposal to allow distribution through Maven was enacted after a
> > contentious majority-rule vote passed 15 to 12.
> >
> > Marvin Humphrey
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
Well sorry but IMHO thats nonsense. The Maven decision was an isolated
incident and didn't change the way all future Incubator policy should
get decided. Insisting that this experiment is done via a change to
the main policy just makes it contentious when it doesn't need to be.
All the complexity in the language and approach, the three votes etc
is exactly why people get the idea that the ASF is a ridiculous place
with overbearing rules and process. Its just an experiment, use lazy
majority consensus and go try it with a podling.
...ant
On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Fri, Dec 13, 2013 at 12:18 AM, ant elder <an...@gmail.com> wrote:
>> I'm also opposed to updating the policy document, so will be voting against
>> this just for that. Its just an experiment so you don't need to be making a
>> permanent change to the policy page to try it, especially as its such a
>> clunky convoluted change.
>
> An explicit policy change is required because otherwise there would be
> ambiguity as to whether a release which passes under the modified regime is an
> act of the Foundation and confers indemnity on the Release Manager.
>
> The language of the proposed change to the Policy page has been carefully
> composed. It is highly isolated from the rest of our policy and has no force
> except on the the experiment.
>
> This proposal is structured as an incremental, reversible change. It is
> incremental because podlings must be opted in by vote of the IPMC to
> participate. It is reversible because once the experiment has run its course
> the relevant section of the policy page can be removed with zero impact
> through lazy consensus.
>
>> (And responding to another related comment in the thread - since when have
>> policy updates not required consensus?)
>
> The 2008 proposal to allow distribution through Maven was enacted after a
> contentious majority-rule vote passed 15 to 12.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Dec 13, 2013 at 12:18 AM, ant elder <an...@gmail.com> wrote:
> I'm also opposed to updating the policy document, so will be voting against
> this just for that. Its just an experiment so you don't need to be making a
> permanent change to the policy page to try it, especially as its such a
> clunky convoluted change.
An explicit policy change is required because otherwise there would be
ambiguity as to whether a release which passes under the modified regime is an
act of the Foundation and confers indemnity on the Release Manager.
The language of the proposed change to the Policy page has been carefully
composed. It is highly isolated from the rest of our policy and has no force
except on the the experiment.
This proposal is structured as an incremental, reversible change. It is
incremental because podlings must be opted in by vote of the IPMC to
participate. It is reversible because once the experiment has run its course
the relevant section of the policy page can be removed with zero impact
through lazy consensus.
> (And responding to another related comment in the thread - since when have
> policy updates not required consensus?)
The 2008 proposal to allow distribution through Maven was enacted after a
contentious majority-rule vote passed 15 to 12.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
On Fri, Dec 13, 2013 at 7:54 AM, Marvin Humphrey <ma...@rectangular.com>wrote:
> On Thu, Dec 12, 2013 at 8:56 PM, Dave Fisher <da...@comcast.net>
> wrote:
>
> So...
>
> * Ant likes the voting rule change, but is opposed to the checklist.
>
I'm also opposed to updating the policy document, so will be voting against
this just for that. Its just an experiment so you don't need to be making a
permanent change to the policy page to try it, especially as its such a
clunky convoluted change.
(And responding to another related comment in the thread - since when have
policy updates not required consensus?)
...ant
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Dec 12, 2013 at 8:56 PM, Dave Fisher <da...@comcast.net> wrote:
> Another rule is better than my straw man. Marvin really missed my point -
> which was 3 IPMC is the way it is done and I don't see a need to change.
I was fooled, yes.
Since there's no compromise that would secure your vote, I'll go with my best
judgment and require that the manifest be approved by a Mentor (without the
ASF Member requirement). We could further relax it to
approval-by-an-IPMC-Member, but such an approval would be inferior in the same
way that a non-Mentor's freelance +1 is inferior under the current system.
> I LIKE this process in all aspects except this change in the 3 +1 from the
> IPMC rule. Can the VOTE separate the two experiments?
So...
* Ant likes the voting rule change, but is opposed to the checklist.
* Dave likes the checklist but is opposed to the voting rule change.
Sigh.
There's no reason to have a VOTE on the checklist alone unless we want to make
it mandatory: podlings have to fill it out in order to release, but IPMC
members remain free to ignore it when they vote. Such an initiative seems
unlikely to pass.
Dave, if we can't arrive at a consensus compromise, even for authorizing an
experiment, that's unfortunate -- but as with Ant, I'm grateful for our
give-and-take and I believe that the proposal is much improved for it.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Dave Fisher <da...@comcast.net>.
On Dec 12, 2013, at 2:15 AM, Bertrand Delacretaz wrote:
> Hi Marvin,
>
> On Thu, Dec 12, 2013 at 6:21 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> I also went another round on the Manifest template and the Release Procedure
>> section of the guide (not yet committed): https://paste.apache.org/a1ya ...
>
> Looks good to me but why "it must be approved by a Mentor (who must
> also be an Apache Member" ?
Another rule is better than my straw man. Marvin really missed my point - which was 3 IPMC is the way it is done and I don't see a need to change. (Yes I know podlings can't get release votes ... with this rule I will lay odds we will start to see active -1 VOTEs from IPMC members on releases when there is any flaw. With the rule of VOTE at 3 +1 and the rest at 1 +1.)
I think we have to have a way for IPMC members to VOTE -1 on releases after the first...
>
> We do have mentors who are not members, and that's fine IMO.
Yes it is. It is very fine.
I LIKE this process in all aspects except this change in the 3 +1 from the IPMC rule. Can the VOTE separate the two experiments?
(1) Vote +1/-1 for the Release Verification Checklist experiment
(2) Vote +1/-1 for the 1 +1 Mentor/IPMC for releases after the first release by a podling.
Regards,
Dave
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Marvin,
On Thu, Dec 12, 2013 at 6:21 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> I also went another round on the Manifest template and the Release Procedure
> section of the guide (not yet committed): https://paste.apache.org/a1ya ...
Looks good to me but why "it must be approved by a Mentor (who must
also be an Apache Member" ?
We do have mentors who are not members, and that's fine IMO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Dec 11, 2013 at 1:16 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> I've just added "as a plain text file" in the release manifest creation section.
>
> I suggest using simpler, more active phrases for a few things at
> https://paste.apache.org/fBoJ - feel free to apply or not, it's mostly
> a question of style.
I like your changes and have committed most of the patch. The one thing I
left out was substantive: I did not commit the additional requirement that
manifest template changes be discussed on general@incubator. Instead, I
clarified that the template may be "augmented" rather than "customized":
<http://s.apache.org/DWA>.
I also went another round on the Manifest template and the Release Procedure
section of the guide (not yet committed): https://paste.apache.org/a1ya
* Add `Usage: http://incubator.apache.org/guides/release.html` link.
* Change `Release:` to `Release Candidate:`.
* Remove `Creation date:` because that will be tracked in SVN.
* Add `Approved by Mentor:` and remove
`Status: (vote in progress/canceled/released)`. Whether a vote is in
progress is determined by whether the manifest has been archived. Whether
it was released or not is less important than whether a Mentor has approved
the manifest, making PPMC votes binding (for releases after the first).
* Reverse the stacking order of `Contents` and `Reviewers and release votes`
just for the sake of making the usage examples easier to write.
* Move most instructions from the manifest template to the guide.
* Add back the sample usage from your original wiki proposal, now inlined
into the `Release Procedure` section of the guide.
Thoughts?
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Marvin,
On Wed, Dec 11, 2013 at 7:08 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> ...I've taken a stab at a second draft:
>
> http://incubator.apache.org/guides/release.html
>
Short and sweet, I like it!
I've just added "as a plain text file" in the release manifest creation section.
I suggest using simpler, more active phrases for a few things at
https://paste.apache.org/fBoJ - feel free to apply or not, it's mostly
a question of style.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 12, 2013 at 6:22 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> ...Next, I will start a PROPOSAL thread, to
> re-engage with the rest of the list...
There's been ample space for people to comment on this in the last few
weeks, I'd be clear that we don't expect any core changes we agree on
the final proposal in this thread. Tweaks and typos, fine, the rest
has been extensively discussed so far, let's avoid restarting from the
top ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Dec 11, 2013 at 1:20 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Looks good to me but I'd ask for a [VOTE] here before committing this.
Yes. I'm supplying this patch now for comment from the people who are
following these threads closely. Next, I will start a PROPOSAL thread, to
re-engage with the rest of the list. Finally there will be a 7-day majority
rule VOTE.
I think this particular proposal is nearing maturity and do not anticipate
making any more major adjustments (such as when we moved to the checklist)
before calling the vote. It's not perfect but IMO it's plenty good enough to
run as an experiment, and it's important that we make some incremental
progress rather than hold out for a panacea.
> Suggestions:
>
> Call that "2013 alternate release voting process" to avoid confusion.
>
> Use "At least three +1 votes from PPMC members are required" for the
> podling vote.
+1, here's the updated patch...
https://paste.apache.org/2J3w
and here's the interdiff...
https://paste.apache.org/kDAL
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Dec 11, 2013 at 7:08 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> ...here's a first take for a patch to the policy page which will be
> submitted as part of the PROPOSAL...
> https://paste.apache.org/4A1I
Looks good to me but I'd ask for a [VOTE] here before committing this.
Suggestions:
Call that "2013 alternate release voting process" to avoid confusion.
Use "At least three +1 votes from PPMC members are required" for the
podling vote.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Dec 6, 2013 at 8:53 AM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Thu, Dec 5, 2013 at 2:32 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Added to a new "usage proposal" section at
>> https://wiki.apache.org/incubator/ReleaseChecklist - does that
>> proposal work for you guys?
>
> I like it. It basically looks like sebb-in-a-box to me (or should
> be elastic sebb these days?) ;-)
Thanks for weighing in!
I've taken a stab at a second draft:
http://incubator.apache.org/guides/release.html
Also, here's a first take for a patch to the policy page which will be
submitted as part of the PROPOSAL. The voting criteria are slightly modified
in order to remain consistent with the Apache-wide "three binding +1 votes"
rule, to require that the manifest is properly completed, and to accommodate
Dave's request for a Mentor who is also an ASF Member (though I'm not totally
clear about that request).
https://paste.apache.org/4A1I
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Roman Shaposhnik <rv...@apache.org>.
On Thu, Dec 5, 2013 at 2:32 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Wed, Dec 4, 2013 at 1:31 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>>
>> http://svn.apache.org/repos/asf/incubator/public/trunk/votes/$PODLING/$RC ...
>
> Added to a new "usage proposal" section at
> https://wiki.apache.org/incubator/ReleaseChecklist - does that
> proposal work for you guys?
I like it. It basically looks like sebb-in-a-box to me (or should
be elastic sebb these days?) ;-)
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Dec 4, 2013 at 1:31 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
> http://svn.apache.org/repos/asf/incubator/public/trunk/votes/$PODLING/$RC ...
Added to a new "usage proposal" section at
https://wiki.apache.org/incubator/ReleaseChecklist - does that
proposal work for you guys?
(and thinking about it, maybe that path should be public/releases
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Dec 3, 2013 at 7:07 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Which we already have at
> http://svn.apache.org/repos/asf/incubator/public/trunk/ - podlings are
> already supposed to keep their info up to date there.
I suggest putting votes here:
http://svn.apache.org/repos/asf/incubator/public/trunk/votes/$PODLING/$RC
PS: The commits list is cvs@incubator, which I don't think many people know
about based on how often David Crossley has to remind people to publish
their own changes to the Incubator website.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Dec 3, 2013 at 2:58 PM, Dave Fisher <da...@comcast.net> wrote:
> On Dec 3, 2013, at 12:59 AM, Bertrand Delacretaz wrote:
>> ...people who review releases work directly on the
>> svn document, enter their comments there and that counts as a +1
>> towards the release....
>>
> Sure, then we need an svn tree that every IPMC and podling can edit...
-
Which we already have at
http://svn.apache.org/repos/asf/incubator/public/trunk/ - podlings are
already supposed to keep their info up to date there.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Dave Fisher <da...@comcast.net>.
On Dec 3, 2013, at 12:59 AM, Bertrand Delacretaz wrote:
> On Tue, Dec 3, 2013 at 3:18 AM, Dave Fisher <da...@comcast.net> wrote:
>> On Dec 2, 2013, at 11:17 AM, sebb wrote:
>>> ... But it is much harder to update an SVN document compared with replying
>>> to an e-mail.
>>
>> Someone running the VOTE would need to update SVN as each vote comes in.
>>
>> There would need to be an email reference attached for each VOTE....
>
> Not in my suggestion - people who review releases work directly on the
> svn document, enter their comments there and that counts as a +1
> towards the release.
>
> A big part of this is teaching people that reviewing a release is not
> just about dropping a +1 in email - we want them, especially for early
> incubating releases, to indicate what they reviewed and what they
> didn't. Working on this in svn (as the board does for its meetings) is
> efficient, leads to a concise manifest that's easy to review and
> overall a much clearer process, IMO, than complaints in long email
> threads.
Sure, then we need an svn tree that every IPMC and podling can edit. Votes show up in the commit log.
Regards,
Dave
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Dec 3, 2013 at 3:18 AM, Dave Fisher <da...@comcast.net> wrote:
> On Dec 2, 2013, at 11:17 AM, sebb wrote:
>>... But it is much harder to update an SVN document compared with replying
>> to an e-mail.
>
> Someone running the VOTE would need to update SVN as each vote comes in.
>
> There would need to be an email reference attached for each VOTE....
Not in my suggestion - people who review releases work directly on the
svn document, enter their comments there and that counts as a +1
towards the release.
A big part of this is teaching people that reviewing a release is not
just about dropping a +1 in email - we want them, especially for early
incubating releases, to indicate what they reviewed and what they
didn't. Working on this in svn (as the board does for its meetings) is
efficient, leads to a concise manifest that's easy to review and
overall a much clearer process, IMO, than complaints in long email
threads.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Dave Fisher <da...@comcast.net>.
On Dec 2, 2013, at 11:17 AM, sebb wrote:
> On 2 December 2013 13:52, Bertrand Delacretaz <bd...@apache.org> wrote:
>> Hi,
>>
>> On Wed, Nov 27, 2013 at 9:45 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>>> ...In response to Bertrand's proposal at <http://s.apache.org/awz>, I've created
>>> a draft release verification checklist:
>>>
>>> http://wiki.apache.org/incubator/ReleaseChecklist ...
>>
>> Thanks for this!
>>
>> I have just added an alternate proposal there, which avoids repeating
>> the checklist items to make it easier to "review the review".
>>
>> I think managing and keeping such release manifests in svn, at least
>> for incubating projects, would make the release process much clearer
>> and easier to understand.
>
> But it is much harder to update an SVN document compared with replying
> to an e-mail.
Someone running the VOTE would need to update SVN as each vote comes in.
There would need to be an email reference attached for each VOTE.
>
> If the proposal is adopted, then I think the comments should be signed
> with ASF ids rather than initials (which may be ambiguous)
Makes sense.
Regards,
Dave
>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by sebb <se...@gmail.com>.
On 2 December 2013 13:52, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> On Wed, Nov 27, 2013 at 9:45 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> ...In response to Bertrand's proposal at <http://s.apache.org/awz>, I've created
>> a draft release verification checklist:
>>
>> http://wiki.apache.org/incubator/ReleaseChecklist ...
>
> Thanks for this!
>
> I have just added an alternate proposal there, which avoids repeating
> the checklist items to make it easier to "review the review".
>
> I think managing and keeping such release manifests in svn, at least
> for incubating projects, would make the release process much clearer
> and easier to understand.
But it is much harder to update an SVN document compared with replying
to an e-mail.
If the proposal is adopted, then I think the comments should be signed
with ASF ids rather than initials (which may be ambiguous)
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Justin Mclean <ju...@gmail.com>.
Hi,
Been following the thread and noticed one of the items on the list is:
"Issue tracker clean for release version."
Is that really expected? I would expect progress and issue closed since
last release but not everything in the issue tracker addressed. Is it clear
what "clean" means in this context?
Committers work and fix what they want ("scratch your own itch"), some
issues may take a while to get fixed (span releases) and some may never get
fixed. A project coming into Apache may also have a number of existing
issues and fixing them all may not even be possible in a reasonable amount
of time.
Thanks,
Justin
On Mon, Dec 9, 2013 at 3:49 PM, Marvin Humphrey <ma...@rectangular.com>wrote:
> On Fri, Dec 6, 2013 at 1:55 AM, ant elder <an...@gmail.com> wrote:
>
> > All the stuff required to be checked when voting on a release should be
> > documented in the ASF doc about releases. That its not in that doc
> suggests
> > its not required. If someone thinks something is required then they
> should
> > go get consensus around that with the wider ASF and get the ASF doc
> updated.
>
> OK, I've done the research and I've migrated the manifest proposal to a new
> documentation page with the links. The ReleaseChecklist wiki page is now a
> home for optional checklist items.
>
> http://incubator.apache.org/guides/release.html
> https://wiki.apache.org/incubator/ReleaseChecklist
>
> Applying your criteria to the current checklist has resulted in the
> migration of two items to the optional list:
>
> * Each expanded source archive matches the corresponding SCM tag.
>
> It turns out the only place matching the SCM tag was documented is the
> Incubator's Release Management guide. Here's Leo Simons making the
> case
> against: <http://markmail.org/message/2ncepopzgnshtyd6>.
>
> * Build instructions are provided, unless obvious
>
> I haven't found any documentation that this is required anywhere on
> www.apache.org/dev or www.apache.org/legal. Bertrand, between me
> arguing
> that this won't come into play often enough and Ant and Olivier arguing
> that we should only include blockers documented elsewhere, I've made
> the
> judgment call that this should be moved to the optional list as well.
> Please let us know if you object.
>
> > Podling releases are not quite the same as TLP releases, thats why they
> > have the DISCLAIMER and "incubating" naming. I think we should be making
> it
> > easier for podlings to do releases, if its really necessary then make an
> > audit of the last release a requirement of graduation.
>
> I am passionately committed to making it easier for podlings to release, by
> granting limited self-governance to those who earn it.
>
> The proposal under consideration is a win for *both* streamlining the
> release
> voting process and improving release oversight.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Dec 19, 2013 at 5:07 PM, David Crossley <cr...@apache.org> wrote:
> There was a time not long ago, where hardly anything
> was documented. Rather it was just common-sense.
> So in my opinion, not being in those docs does not mean
> that it is not required.
If there are required items which have been inadvertently left off, we can add
them later. We are already set to track optional items on the
ReleaseChecklist wiki page as well.
There should be a low threshold for adding an optional item to the wiki, and a
high threshold for adding a required item to the default checklist. I have
added the following text to the Experimental Release Guide to clarify:
Each review item in the default Manifest is either required by
Foundation-wide policy and would block a release by any Apache top-level
project, or is required by Incubator policy.
I can think of one item which was left off and should probably added to the
default checklist in my opinion:
1.2 RM apache.org release signing key present in KEYS file.
> Votes should also encourage "anyone" to vote (though of course
> as non-binding). With this SVN based technique, how do they do that?
The PPMC VOTE must be called on the podling dev list. Non-binding votes may
be cast as they are now -- via email -- and I agree that they should be
encouraged.
> If the dev list PPMC vote passes including 3+ IPMC members
> then there is no need for this "second vote".
Current Incubator policy requires the second vote on general@incubator.
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
If the majority of all votes is positive, then the Podling SHALL send a
summary of that vote to the Incubator's general list and formally request
the Incubator PMC approve such a release.
The experiment maintains this procedure.
> Also some good stuff is in the old "guides/releasemanagement.html"
> so we do need to ensure that is over at "a.o/dev/".
The experimental release guide supplants the old one as a spec, but not as an
archive of opinions about best practices. A single document cannot serve well
in both capacities. We need both, and they must be separate.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by David Crossley <cr...@apache.org>.
Marvin Humphrey wrote:
> ant elder wrote:
> >
> > All the stuff required to be checked when voting on a release should be
> > documented in the ASF doc about releases. That its not in that doc suggests
> > its not required. If someone thinks something is required then they should
> > go get consensus around that with the wider ASF and get the ASF doc updated.
There was a time not long ago, where hardly anything
was documented. Rather it was just common-sense.
So in my opinion, not being in those docs does not mean
that it is not required.
(Not sure where to insert some other comments in this thread,
so will just dump them here.)
I am concerned about potentially changing the way we do things.
So, two comments with that in mind:
Votes should also encourage "anyone" to vote (though of course
as non-binding). With this SVN based technique, how do they do that?
The current new "guides/release.html" says "contains a link URL
for the Manifest". I suppose that they could be encouraged to
copy the text from SVN and reply via the dev mail list.
If the dev list PPMC vote passes including 3+ IPMC members
then there is no need for this "second vote".
The wording gives a slight twist which might sway the
understanding of why we do such things.
Also some good stuff is in the old "guides/releasemanagement.html"
so we do need to ensure that is over at "a.o/dev/".
-David
> OK, I've done the research and I've migrated the manifest proposal to a new
> documentation page with the links. The ReleaseChecklist wiki page is now a
> home for optional checklist items.
>
> http://incubator.apache.org/guides/release.html
> https://wiki.apache.org/incubator/ReleaseChecklist
>
> Applying your criteria to the current checklist has resulted in the
> migration of two items to the optional list:
>
> * Each expanded source archive matches the corresponding SCM tag.
>
> It turns out the only place matching the SCM tag was documented is the
> Incubator's Release Management guide. Here's Leo Simons making the case
> against: <http://markmail.org/message/2ncepopzgnshtyd6>.
>
> * Build instructions are provided, unless obvious
>
> I haven't found any documentation that this is required anywhere on
> www.apache.org/dev or www.apache.org/legal. Bertrand, between me arguing
> that this won't come into play often enough and Ant and Olivier arguing
> that we should only include blockers documented elsewhere, I've made the
> judgment call that this should be moved to the optional list as well.
> Please let us know if you object.
>
> > Podling releases are not quite the same as TLP releases, thats why they
> > have the DISCLAIMER and "incubating" naming. I think we should be making it
> > easier for podlings to do releases, if its really necessary then make an
> > audit of the last release a requirement of graduation.
>
> I am passionately committed to making it easier for podlings to release, by
> granting limited self-governance to those who earn it.
>
> The proposal under consideration is a win for *both* streamlining the release
> voting process and improving release oversight.
>
> Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Dec 9, 2013 at 12:30 PM, ant elder <an...@gmail.com> wrote:
>...The point is i think that podlings learn
> about the requirements but that doesn't mean we must block releases or
> make people jump through hoops to do that learning...
I agree with that, and I don't think we're saying that all items from
the http://incubator.apache.org/guides/release_manifest.txt must
absolutely be 100% correct for an incubating release. But having that
baseline at least helps make it very clear what's expected from
releases, which is not the case currently IMO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Dec 9, 2013 at 12:30 PM, ant elder <an...@gmail.com> wrote:
> On Mon, Dec 9, 2013 at 11:04 AM, Bertrand Delacretaz
>> Define "lower bar". Do you see any of the review items
>> http://incubator.apache.org/guides/release_manifest.txt as optional?
>>
> ...Probably all of those could be optional or fixed next time. I've done
> releases with invalid signatures in the past and there is some
> automated thing in the ASF distribution area that sends you an email
> about it and you just have to resign the artifact...
I have no problem with clear and documented decisions to relax some of
the release checklist criteria for an incubating release, as long as
that doesn't put the foundation at risk.
Failing tests clearly fall into this category, a reviewer can then
very much say "the tests are failing but I still give my +1 to the
release".
Dubious code provenance OTOH can potentially put the foundation at
risk, so I'd be much stricter on that.
With the suggested checklist this process, bargaining included,
becomes very clear and understandable for new podlings - they just
need to look at existing release manifests.
I like Marvin's description of
http://incubator.apache.org/guides/releasemanagement.html as an
"absurd monstrosity" and I think we're making progress with this new
checklist. The more content we can remove from the mess that's the
incubator.apache.org the better.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
On Mon, Dec 9, 2013 at 11:04 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi,
>
> On Mon, Dec 9, 2013 at 11:34 AM, ant elder <an...@gmail.com> wrote:
>> ...2) Podlings should normally graduate after the first release (and we
>> should more proactively do that) not stay to do more...
>
> I wouldn't set this as a goal. It's nice when it happens, but as you
> say the goal is for a podling to be generally healthy and to have
> understood the Apache invariants before graduating. It's not the
> number of releases.
>
Yes sometimes podlings may need to stay longer, but think about it -
if a podling does all thats required including the first release, and
then graduates, from then on they get binding votes on everything
including their releases. If something means they can't graduate yet
why does that mean they shouldn't get binding votes on subsequent
releases? Surely that should only happen if they are staying because
their first release was a disaster. The other reasons to keep them
here are separate from the competence at doing releases so saying they
don't get the binding votes on subsequent releases is just punishment
that they haven't yet resolved the unrelated issue.
>> ...If we could find a way to have Incubator PMC members accept a lower
>> bar for doing podling releases it would make a massive improvement to
>> everyones experience of the Incubator....
>
> Define "lower bar". Do you see any of the review items
> http://incubator.apache.org/guides/release_manifest.txt as optional?
>
Probably all of those could be optional or fixed next time. I've done
releases with invalid signatures in the past and there is some
automated thing in the ASF distribution area that sends you an email
about it and you just have to resign the artifact. If the podling
choose to do a release knowing some tests fail thats up to them, i can
think of a number of releases happened here missing the DISCLAIMER
file and they were told just fix it next time, etc for the rest of the
items on the list. We've even had Incubator releases including GPL
dependencies in the past. The point is i think that podlings learn
about the requirements but that doesn't mean we must block releases or
make people jump through hoops to do that learning.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Olivier Lamy <ol...@apache.org>.
On 9 December 2013 22:04, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> On Mon, Dec 9, 2013 at 11:34 AM, ant elder <an...@gmail.com> wrote:
>> ...2) Podlings should normally graduate after the first release (and we
>> should more proactively do that) not stay to do more...
>
> I wouldn't set this as a goal. It's nice when it happens, but as you
> say the goal is for a podling to be generally healthy and to have
> understood the Apache invariants before graduating. It's not the
> number of releases.
>
>> ...If we could find a way to have Incubator PMC members accept a lower
>> bar for doing podling releases it would make a massive improvement to
>> everyones experience of the Incubator....
>
> Define "lower bar". Do you see any of the review items
> http://incubator.apache.org/guides/release_manifest.txt as optional?
Good sounds so light compared to
http://incubator.apache.org/guides/releasemanagement.html
Definitely great to have a small, simple and human readable document!
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Dec 9, 2013 at 11:34 AM, ant elder <an...@gmail.com> wrote:
> ...2) Podlings should normally graduate after the first release (and we
> should more proactively do that) not stay to do more...
I wouldn't set this as a goal. It's nice when it happens, but as you
say the goal is for a podling to be generally healthy and to have
understood the Apache invariants before graduating. It's not the
number of releases.
> ...If we could find a way to have Incubator PMC members accept a lower
> bar for doing podling releases it would make a massive improvement to
> everyones experience of the Incubator....
Define "lower bar". Do you see any of the review items
http://incubator.apache.org/guides/release_manifest.txt as optional?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
On Tue, Dec 10, 2013 at 5:45 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Mon, Dec 9, 2013 at 2:34 AM, ant elder <an...@gmail.com> wrote:
>> I know you're passionate about this Marvin but as it stands I'll be
>> voting against this proposal.
>
> I plan to propose this as an experiment
Well ok, earlier you said you'd planed it as a change to the Incubator
policy page but if its just an experiment then fine by me, i've
already said in the experiment discussions that i'd support anyone
doing some experiments.
>
>> 1) This proposal doesn't help podlings with the first release
>
> It helps by clarifying what we expect from podlings. We're effectively
> replacing that absurd monstrosity, the Incubator's Release Management Guide...
>
> http://incubator.apache.org/guides/releasemanagement.html
>
> ... with a one page checklist:
>
> http://incubator.apache.org/guides/release_manifest.txt
>
> The first release will be easier because podlings will spend less time
> thrashing through docs trying to discover what is required. Compliance isn't
> that much work in the grand scheme of things -- the big problem has been that
> the Incubator couldn't tell you the spec.
>
>> 3) The proposal adds new artificial process around doing a release
>> when we should be teaching podlings how TLPs do things
>
> I think podlings which have their act together ought to have the option of
> filling in a checklist rather than being forced to wait weeks hoping some
> random IPMC member wanders by.
>
>> Incubator releases are not official ASF releases so there is not and should
>> not be the same expectations around them.
>
> A lot of people seem to think this, but it's not true. Incubator releases are
> official ASF releases.
>
>> If we could find a way to have Incubator PMC members accept a lower
>> bar for doing podling releases it would make a massive improvement to
>> everyones experience of the Incubator.
>
> We shouldn't be sticklers for inconsequential minutiae, but since the
> Incubator is a TLP like any other and its releases are subject to
> Foundation-wide policy, I don't believe we have much freedom to accept a lower
> bar. Your request is impossible.
>
That doesn't seem to be true from past evidence. I could trawl back
through the archives and pull out numerous instances of podling
releases with known flaws being approved by the Incubator PMC, ASF
directors, and in some instances with the blessing of the ASF board.
Even the Incubator policy document says "No release made by a Podling
will be endorsed by the ASF. Unendorsed releases may be made by
Podlings ..."
The main purpose of the voting is to protect the folks who make
release decisions. So long as they're not just wildly throwing about
+1 votes with no thought then the ASF will be fine with having some
wiggle room on release quality for Incubating projects. We could go
ask the board for clarification, but not so long ago Roy told us:
"The Incubator is that PMC. Make a decision and run with it. If it
doesn't work out, try another decision and run with that. The only
time the board should step in (with a hammer) is when no decisions are
being made."
Isn't that enough to at least try some experiments with easier releases?
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Dec 9, 2013 at 2:34 AM, ant elder <an...@gmail.com> wrote:
> I know you're passionate about this Marvin but as it stands I'll be
> voting against this proposal.
I plan to propose this as an experiment which podlings would opt into.
Hopefully, I can persuade you not to oppose such an experiment, just as you
once attempted to persuade someone else:
http://s.apache.org/8lUF
I'm in favour of trying this. And its just experiment remember so not a
change for ever for all podlings so please people try to support it or at
least not try to block it.
If not, that's unfortunate, but let me thank you for the give-and-take. Your
participation has very much improved the proposal.
> 1) This proposal doesn't help podlings with the first release
It helps by clarifying what we expect from podlings. We're effectively
replacing that absurd monstrosity, the Incubator's Release Management Guide...
http://incubator.apache.org/guides/releasemanagement.html
... with a one page checklist:
http://incubator.apache.org/guides/release_manifest.txt
The first release will be easier because podlings will spend less time
thrashing through docs trying to discover what is required. Compliance isn't
that much work in the grand scheme of things -- the big problem has been that
the Incubator couldn't tell you the spec.
> 3) The proposal adds new artificial process around doing a release
> when we should be teaching podlings how TLPs do things
I think podlings which have their act together ought to have the option of
filling in a checklist rather than being forced to wait weeks hoping some
random IPMC member wanders by.
> Incubator releases are not official ASF releases so there is not and should
> not be the same expectations around them.
A lot of people seem to think this, but it's not true. Incubator releases are
official ASF releases.
> If we could find a way to have Incubator PMC members accept a lower
> bar for doing podling releases it would make a massive improvement to
> everyones experience of the Incubator.
We shouldn't be sticklers for inconsequential minutiae, but since the
Incubator is a TLP like any other and its releases are subject to
Foundation-wide policy, I don't believe we have much freedom to accept a lower
bar. Your request is impossible.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
I know you're passionate about this Marvin but as it stands I'll be
voting against this proposal.
1) This proposal doesn't help podlings with the first release
2) Podlings should normally graduate after the first release (and we
should more proactively do that) not stay to do more
3) The proposal adds new artificial process around doing a release
when we should be teaching podlings how TLPs do things
IMHO the Incubator has lost the plot with this focus on release
artifacts, we should instead focus on teaching podlings about how to
build strong communities around their project. It is not the primary
objective for the Incubator to protect the ASF from a rogue podling
release. Many many releases have been done in the ASF that have gone
out with problems but I have never heard of the ASF getting in to any
trouble from them, ever. Where as, many Incubator podlings and the
public perception of the ASF have been damaged by the problems around
doing an Incubator release. Incubator releases are not official ASF
releases so there is not and should not be the same expectations
around them.
If we could find a way to have Incubator PMC members accept a lower
bar for doing podling releases it would make a massive improvement to
everyones experience of the Incubator.
...ant
On Mon, Dec 9, 2013 at 4:49 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Fri, Dec 6, 2013 at 1:55 AM, ant elder <an...@gmail.com> wrote:
>
>> All the stuff required to be checked when voting on a release should be
>> documented in the ASF doc about releases. That its not in that doc suggests
>> its not required. If someone thinks something is required then they should
>> go get consensus around that with the wider ASF and get the ASF doc updated.
>
> OK, I've done the research and I've migrated the manifest proposal to a new
> documentation page with the links. The ReleaseChecklist wiki page is now a
> home for optional checklist items.
>
> http://incubator.apache.org/guides/release.html
> https://wiki.apache.org/incubator/ReleaseChecklist
>
> Applying your criteria to the current checklist has resulted in the
> migration of two items to the optional list:
>
> * Each expanded source archive matches the corresponding SCM tag.
>
> It turns out the only place matching the SCM tag was documented is the
> Incubator's Release Management guide. Here's Leo Simons making the case
> against: <http://markmail.org/message/2ncepopzgnshtyd6>.
>
> * Build instructions are provided, unless obvious
>
> I haven't found any documentation that this is required anywhere on
> www.apache.org/dev or www.apache.org/legal. Bertrand, between me arguing
> that this won't come into play often enough and Ant and Olivier arguing
> that we should only include blockers documented elsewhere, I've made the
> judgment call that this should be moved to the optional list as well.
> Please let us know if you object.
>
>> Podling releases are not quite the same as TLP releases, thats why they
>> have the DISCLAIMER and "incubating" naming. I think we should be making it
>> easier for podlings to do releases, if its really necessary then make an
>> audit of the last release a requirement of graduation.
>
> I am passionately committed to making it easier for podlings to release, by
> granting limited self-governance to those who earn it.
>
> The proposal under consideration is a win for *both* streamlining the release
> voting process and improving release oversight.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Dec 6, 2013 at 1:55 AM, ant elder <an...@gmail.com> wrote:
> All the stuff required to be checked when voting on a release should be
> documented in the ASF doc about releases. That its not in that doc suggests
> its not required. If someone thinks something is required then they should
> go get consensus around that with the wider ASF and get the ASF doc updated.
OK, I've done the research and I've migrated the manifest proposal to a new
documentation page with the links. The ReleaseChecklist wiki page is now a
home for optional checklist items.
http://incubator.apache.org/guides/release.html
https://wiki.apache.org/incubator/ReleaseChecklist
Applying your criteria to the current checklist has resulted in the
migration of two items to the optional list:
* Each expanded source archive matches the corresponding SCM tag.
It turns out the only place matching the SCM tag was documented is the
Incubator's Release Management guide. Here's Leo Simons making the case
against: <http://markmail.org/message/2ncepopzgnshtyd6>.
* Build instructions are provided, unless obvious
I haven't found any documentation that this is required anywhere on
www.apache.org/dev or www.apache.org/legal. Bertrand, between me arguing
that this won't come into play often enough and Ant and Olivier arguing
that we should only include blockers documented elsewhere, I've made the
judgment call that this should be moved to the optional list as well.
Please let us know if you object.
> Podling releases are not quite the same as TLP releases, thats why they
> have the DISCLAIMER and "incubating" naming. I think we should be making it
> easier for podlings to do releases, if its really necessary then make an
> audit of the last release a requirement of graduation.
I am passionately committed to making it easier for podlings to release, by
granting limited self-governance to those who earn it.
The proposal under consideration is a win for *both* streamlining the release
voting process and improving release oversight.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Dec 8, 2013 at 2:49 PM, Olivier Lamy <ol...@apache.org> wrote:
> We have a lot of pending votes and I see you guys discussing about
> rules why not spend your times on having a look at those votes...
If we succeed in changing the system so that my participation doesn't let AWOL
Mentors off the hook[1], deny meritorious PPMC members self-governance[2], or
perpetuate a status quo of inferior IP oversight[3], I definitely look forward
to reviewing releases once again.
> And with such discussion we don't look very attractive. Isn't the goal of
> the ASF to have a lot of project developed here?
I think we should be more embarrassed about actual errors than about what it
looks like as we design processes intended to avoid them. The recent glitches
with improper release vote counting[4] and not completing IP clearance before
releasing[5] both would have been prevented by using the checklist.
Besides, if we're talking about how the Incubator looks to outsiders,
shouldn't we be concerned that we routinely have so much trouble getting IPMC
members to vote on releases? This proposal is designed to ameliorate that
problem.
> Sorry personally I don't have time to read/participate the whole
> thread as I prefer to spend my time on writing softwares.
Not everybody has to follow every twist and turn of development. When we have
something sufficiently mature, I'll start a PROPOSAL thread. Please watch for
that.
In the meantime, please continue to enjoy writing software! :)
Marvin Humphrey
[1] http://s.apache.org/Kca
[2] http://s.apache.org/qSW
[3] http://s.apache.org/bsy
[4] http://s.apache.org/zjp
[5] http://s.apache.org/tDf
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Olivier Lamy <ol...@apache.org>.
On 6 December 2013 20:55, ant elder <an...@gmail.com> wrote:
> On Fri, Dec 6, 2013 at 1:40 AM, Marvin Humphrey <ma...@rectangular.com>wrote:
>
>> On Thu, Dec 5, 2013 at 8:38 AM, sebb <se...@gmail.com> wrote:
>> > On 5 December 2013 10:37, Bertrand Delacretaz <bd...@apache.org>
>> wrote:
>> >> On Tue, Dec 3, 2013 at 11:39 PM, Marvin Humphrey <
>> marvin@rectangular.com> wrote:
>>
>> >>> ... Second, I'm amused that the "commits list" item was quietly
>> dropped,
>> >>> but new checklist items have been inserted regarding the dev and
>> private
>> >>> lists...
>> >>
>> >> Pure oversight on my part, sorry...but what would we do if no reviewer
>> >> follows the commit lists? I don't think that's a reason to kill a
>> release.
>> >
>> > Oversight of the commit list is vital; that is how we ensure that SCM
>> > only contains material that is permitted.
>> >
>> > The source release is then checked against SCM to ensure we are only
>> > published vetted material.
>> >
>> > If there is no review of the commit list, then the whole system breaks
>> down.
>>
>> I certainly agree that following the commits list is essential (and sought
>> to
>> emphasize as much in the post at the top of the thread). I'd barely even
>> considered the possibility that *none* of the reviewers might be following
>> the commits list.
>>
>> However, I think that Bertrand's "provenance" checklist item largely
>> achieves
>> what I'd been grasping for with the "commits list" item, and fits much
>> better
>> into the context of approving the release. If nobody's following the
>> commits
>> list, that's an issue with serious implications for the project, but it's
>> not
>> a direct release blocker. If provenance is unsettled, though, that clearly
>> blocks the release.
>>
>> Personally, I wouldn't feel confident checking the "provenance" item if I
>> wasn't watching the commits list. It's true that the person making the
>> commit
>> affirms that they have the right to their contribution, but still, I feel
>> like
>> you need to at least be aware of what contributions have gone into the
>> product.
>>
>> Maybe there ought to be a note to such effect on the explanations page.
>> But
>> in any case, I'm OK with the "commits list" item disappearing, so long as
>> the
>> "provenance" item stays.
>>
>> As of revision 14 (removing the "dev list" and "private list" items) I'm
>> now
>> generally satisfied with the content of the checklist items and hope to
>> move
>> on to refining the workflow and surrounding documentation.
>>
>>
>>
> All the stuff required to be checked when voting on a release should be
> documented in the ASF doc about releases. That its not in that doc suggests
> its not required. If someone thinks something is required then they should
> go get consensus around that with the wider ASF and get the ASF doc updated.
>
> Podling releases are not quite the same as TLP releases, thats why they
> have the DISCLAIMER and "incubating" naming. I think we should be making it
> easier for podlings to do releases, if its really necessary then make an
> audit of the last release a requirement of graduation.
>
> ...ant
+1 I don't see why releasing in incubator must be more complicated
than in TLPs and have more rules.
We have a lot of pending votes and I see you guys discussing about
rules why not spend your times on having a look at those votes...
And with such discussion we don't look very attractive. Isn't the
goal of the ASF to have a lot of project developed here?
Sorry personally I don't have time to read/participate the whole
thread as I prefer to spend my time on writing softwares.
But my participation could be: is it possible to add something in the
verification checklist as "Build great/usable software for our lovely
users"
Cheers
--
/me tired reading all of this over complicated administrative threads...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by ant elder <an...@gmail.com>.
On Fri, Dec 6, 2013 at 1:40 AM, Marvin Humphrey <ma...@rectangular.com>wrote:
> On Thu, Dec 5, 2013 at 8:38 AM, sebb <se...@gmail.com> wrote:
> > On 5 December 2013 10:37, Bertrand Delacretaz <bd...@apache.org>
> wrote:
> >> On Tue, Dec 3, 2013 at 11:39 PM, Marvin Humphrey <
> marvin@rectangular.com> wrote:
>
> >>> ... Second, I'm amused that the "commits list" item was quietly
> dropped,
> >>> but new checklist items have been inserted regarding the dev and
> private
> >>> lists...
> >>
> >> Pure oversight on my part, sorry...but what would we do if no reviewer
> >> follows the commit lists? I don't think that's a reason to kill a
> release.
> >
> > Oversight of the commit list is vital; that is how we ensure that SCM
> > only contains material that is permitted.
> >
> > The source release is then checked against SCM to ensure we are only
> > published vetted material.
> >
> > If there is no review of the commit list, then the whole system breaks
> down.
>
> I certainly agree that following the commits list is essential (and sought
> to
> emphasize as much in the post at the top of the thread). I'd barely even
> considered the possibility that *none* of the reviewers might be following
> the commits list.
>
> However, I think that Bertrand's "provenance" checklist item largely
> achieves
> what I'd been grasping for with the "commits list" item, and fits much
> better
> into the context of approving the release. If nobody's following the
> commits
> list, that's an issue with serious implications for the project, but it's
> not
> a direct release blocker. If provenance is unsettled, though, that clearly
> blocks the release.
>
> Personally, I wouldn't feel confident checking the "provenance" item if I
> wasn't watching the commits list. It's true that the person making the
> commit
> affirms that they have the right to their contribution, but still, I feel
> like
> you need to at least be aware of what contributions have gone into the
> product.
>
> Maybe there ought to be a note to such effect on the explanations page.
> But
> in any case, I'm OK with the "commits list" item disappearing, so long as
> the
> "provenance" item stays.
>
> As of revision 14 (removing the "dev list" and "private list" items) I'm
> now
> generally satisfied with the content of the checklist items and hope to
> move
> on to refining the workflow and surrounding documentation.
>
>
>
All the stuff required to be checked when voting on a release should be
documented in the ASF doc about releases. That its not in that doc suggests
its not required. If someone thinks something is required then they should
go get consensus around that with the wider ASF and get the ASF doc updated.
Podling releases are not quite the same as TLP releases, thats why they
have the DISCLAIMER and "incubating" naming. I think we should be making it
easier for podlings to do releases, if its really necessary then make an
audit of the last release a requirement of graduation.
...ant
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Dec 5, 2013 at 8:38 AM, sebb <se...@gmail.com> wrote:
> On 5 December 2013 10:37, Bertrand Delacretaz <bd...@apache.org> wrote:
>> On Tue, Dec 3, 2013 at 11:39 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>>> ... Second, I'm amused that the "commits list" item was quietly dropped,
>>> but new checklist items have been inserted regarding the dev and private
>>> lists...
>>
>> Pure oversight on my part, sorry...but what would we do if no reviewer
>> follows the commit lists? I don't think that's a reason to kill a release.
>
> Oversight of the commit list is vital; that is how we ensure that SCM
> only contains material that is permitted.
>
> The source release is then checked against SCM to ensure we are only
> published vetted material.
>
> If there is no review of the commit list, then the whole system breaks down.
I certainly agree that following the commits list is essential (and sought to
emphasize as much in the post at the top of the thread). I'd barely even
considered the possibility that *none* of the reviewers might be following
the commits list.
However, I think that Bertrand's "provenance" checklist item largely achieves
what I'd been grasping for with the "commits list" item, and fits much better
into the context of approving the release. If nobody's following the commits
list, that's an issue with serious implications for the project, but it's not
a direct release blocker. If provenance is unsettled, though, that clearly
blocks the release.
Personally, I wouldn't feel confident checking the "provenance" item if I
wasn't watching the commits list. It's true that the person making the commit
affirms that they have the right to their contribution, but still, I feel like
you need to at least be aware of what contributions have gone into the
product.
Maybe there ought to be a note to such effect on the explanations page. But
in any case, I'm OK with the "commits list" item disappearing, so long as the
"provenance" item stays.
As of revision 14 (removing the "dev list" and "private list" items) I'm now
generally satisfied with the content of the checklist items and hope to move
on to refining the workflow and surrounding documentation.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by sebb <se...@gmail.com>.
On 5 December 2013 10:37, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> On Tue, Dec 3, 2013 at 11:39 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> On Mon, Dec 2, 2013 at 5:52 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>> ... 3.6 Release consists of source code only, no binaries
>>
>> Technically we allow some "binary" formats like .jpg, .png, etc. in releases
>> without the corresponding composite files from which they were exported
>> (assuming such composite files exist)...
>
> Agreed, I have added a TODO at
> https://wiki.apache.org/incubator/ReleaseChecklist - the manifest
> should point to a page at http://incubator.apache.org that explains
> such things in a bit more detail. Good opportunity to clarify that ;-)
>
>> ...Also, I wonder whether "no binaries"
>> may provoke newbies to ask "What?! No binaries?!"...
>
> Which is good IMO, once we have a clear explanation.
>
> ...
>> 4.1 Based on its dev list activity, the project looks healthy
>>
>> 4.2 Based on its private list activity, the project looks healthy
>>
>> First, I think these two items should be struck because they belong in a
>> graduation checklist, not a release checklist...
>
> Agreed, I have removed them. Totally agree to keep the checklist as
> small as possible.
>
> I made some other minor changes as well, see wiki history if needed.
>
>>... Second, I'm amused that the "commits list" item was quietly dropped, but new
>> checklist items have been inserted regarding the dev and private lists...
>
> Pure oversight on my part, sorry...but what would we do if no reviewer
> follows the commit lists? I don't think that's a reason to kill a
> release.
Oversight of the commit list is vital; that is how we ensure that SCM
only contains material that is permitted.
The source release is then checked against SCM to ensure we are only
published vetted material.
If there is no review of the commit list, then the whole system breaks down.
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Dec 3, 2013 at 11:39 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Mon, Dec 2, 2013 at 5:52 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> ... 3.6 Release consists of source code only, no binaries
>
> Technically we allow some "binary" formats like .jpg, .png, etc. in releases
> without the corresponding composite files from which they were exported
> (assuming such composite files exist)...
Agreed, I have added a TODO at
https://wiki.apache.org/incubator/ReleaseChecklist - the manifest
should point to a page at http://incubator.apache.org that explains
such things in a bit more detail. Good opportunity to clarify that ;-)
> ...Also, I wonder whether "no binaries"
> may provoke newbies to ask "What?! No binaries?!"...
Which is good IMO, once we have a clear explanation.
...
> 4.1 Based on its dev list activity, the project looks healthy
>
> 4.2 Based on its private list activity, the project looks healthy
>
> First, I think these two items should be struck because they belong in a
> graduation checklist, not a release checklist...
Agreed, I have removed them. Totally agree to keep the checklist as
small as possible.
I made some other minor changes as well, see wiki history if needed.
>... Second, I'm amused that the "commits list" item was quietly dropped, but new
> checklist items have been inserted regarding the dev and private lists...
Pure oversight on my part, sorry...but what would we do if no reviewer
follows the commit lists? I don't think that's a reason to kill a
release.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Dec 2, 2013 at 5:52 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> I have just added an alternate proposal there, which avoids repeating
> the checklist items to make it easier to "review the review".
Having watched how the ASF Board edits the agenda in svn before each monthly
meeting, I agree that this format and workflow is an improvement. I suggest
we promote this alternative to become the working proposal; I'm going to take
the liberty of deleting my own email-centric draft.
A few comments regarding some of the checklist items...
2.1 Build instructions are provided
How often do we see release candidates without build instructions? Sure,
they're important, but unless podlings are regularly failing to supply them, I
question whether a dedicated item in the checklist is justified.
3.4 The provenance of all source files is clear (ASF or software grants)
+1, looks great!
Thank you for figuring out how to express that concept as a checklist item.
3.6 Release consists of source code only, no binaries
Technically we allow some "binary" formats like .jpg, .png, etc. in releases
without the corresponding composite files from which they were exported
(assuming such composite files exist). Also, I wonder whether "no binaries"
may provoke newbies to ask "What?! No binaries?!"
Still, I like this more obvious wording, so +1 until we see actual
confusion arising in practice.
4.1 Based on its dev list activity, the project looks healthy
4.2 Based on its private list activity, the project looks healthy
First, I think these two items should be struck because they belong in a
graduation checklist, not a release checklist. Lack of a "healthy" community
does not block a release -- in fact, a release may be the very remedy to
revitalize a sickly community! The best opportunity to start a conversation
about about community health is in the wake of a quarterly report, since the
report always contains an item assessing progress towards graduation.
Second, I'm amused that the "commits list" item was quietly dropped, but new
checklist items have been inserted regarding the dev and private lists. I
said I was willing to see the "commits list" item go, but that was in the
context of making the case that we should not bloat the checklist with
extraneous concerns.
Because I think compromising for the greater good of getting reforms passed
is important, I'm not going to insist on either restoration of the "commits
list" item or removal of these two items. Nevertheless, I think we would be
well advised to apply ruthless focus when editing a template intended for
heavy reuse. Even if we succeed in rationalizing the process, getting a
release through the Incubator will still be plenty arduous.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release Verification Checklist
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Nov 27, 2013 at 9:45 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> ...In response to Bertrand's proposal at <http://s.apache.org/awz>, I've created
> a draft release verification checklist:
>
> http://wiki.apache.org/incubator/ReleaseChecklist ...
Thanks for this!
I have just added an alternate proposal there, which avoids repeating
the checklist items to make it easier to "review the review".
I think managing and keeping such release manifests in svn, at least
for incubating projects, would make the release process much clearer
and easier to understand.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: Release Verification Checklist
Posted by Hitesh Shah <hi...@apache.org>.
Useful information for folks when verifying releases. (The checklist is still getting firmed up)
thanks
-- Hitesh
Begin forwarded message:
> From: Marvin Humphrey <ma...@rectangular.com>
> Date: November 27, 2013 12:45:51 PM PST
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Subject: Release Verification Checklist
> Reply-To: general@incubator.apache.org
>
> Greets,
>
> In response to Bertrand's proposal at <http://s.apache.org/awz>, I've created
> a draft release verification checklist:
>
> http://wiki.apache.org/incubator/ReleaseChecklist
>
> It should be emphasized that completing a checklist like this at release
> points is only one aspect of exercising proper IP stewardship over a codebase.
> The checklist says nothing about code provenance, and while it may catch
> licensing documentation bugs, it does little to guard against the possibility
> of actual licensing violations: bogus header swaps, "borrowed" code pasted
> into files with different licensing, and so on. We don't generally encounter
> such problems at Apache, but we need to stay vigilant.
>
> Design notes:
>
> * Brevity is important for ease of use. We don't want to explain what makes
> for a valid LICENSE and NOTICE in a checklist.
> * +0 and -0 votes are rare, so they are omitted from the template.
> * All checklist items are optional. Of course if you leave everything
> unchecked, your indifference is going to be entered into the record.
> * The dictate that all checklist items are optional is explicitly included
> in the template despite wasting precious space, because otherwise PPMC
> confusion will cause needless stress and wasted time.
> * Podlings may wish to augment this template with project-specific
> modifications, e.g. "Extended tests pass", "RAT report clean".
> * The `Apache ID` field is intended to allow whoever enters these checklists
> into the record to copy-and-paste verbatim without having to look up
> credentials. Hopefully people will actually fill it in regularly.
> * There is no field identifying the release candidate because that
> information will be carried by email subject, filepath in version control,
> etc.
> * The checklist text is designed for quick copy/paste into an email. It
> must take up as little vertical space as possible so that it is easy to
> select with a mouse/trackpad gesture.
> * The textual layout is intended to stack cleanly and to look good when
> rendered using either fixed-width or variable-width fonts.
>
> Thoughts?
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>