On Mon, Dec 2, 2013 at 5:52 AM, Bertrand Delacretaz
<bdelacre...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
