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/12/01 20:09:24 UTC
Re: Release Verification Checklist
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 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