On Mon, Sep 9, 2013 at 6:47 AM, Rich Bowen <rbo...@rcbowen.com> wrote:
> Hmm. Did we do something wrong with our call for vote?
Perhaps not this one, though the voting on allura-dev@incubator was somewhat
irregular.
* No "[VOTE]" in the subject.
* Spread out over multiple threads.
* No time specification. (I recommend the phrase "at least 72 hours".)
* PPMC votes claimed as "binding", which is ambiguous.
So long as the IPMC VOTE clears, though, those irregularities don't block the
release IMO.
I'd also like to note that the dev list archives for Allura are time-consuming
and tedious to plow through -- the signal-to-noise ratio is poor due to the
large number of auto-generated messages with trivial content.
> Can anyone suggest any reason why we've gotten ZERO response to this message
> or to Dave's followup?
Allura has four Mentors. You've voted, but where are the others?
Mentors must lead the way, particularly for the first release. "Freelance"
reviews of release artifacts, by IPMC members who are not following the
podling's development, are by their nature superficial. For instance, a
freelancer can run RAT and see whether there are files with missing ALv2
headers, but can't see whether files with ALv2 headers had them installed
appropriately. We count on Mentors to endorse the podling's initial IP
handling, from supervising the code grant to monitoring the dev list and
commits list day-by-day and ensuring that everything is proper.
After the first release, we are voting on a delta, and all new changes have
happened within Apache channels which are comparatively more auditable.
However, for the initial incubating release, we are voting on development
which took place elsewhere, and Mentors have better insight than the rest of
the IPMC into the importation and assimilation of that dark matter into
Apache.
> Can some of the old hands around here give us some insight into what we need
> to do to get things moving?
Getting enough IPMC votes for incubating releases is an age-old issue for the
Incubator. Many long-term remedies have been discussed, but none of that will
help the acute problem faced by Allura.
In today's Incubator, the most effective strategy for an individual podling to
take is for its core contributors to become serious experts about Apache IP
and release policy and to present squeaky clean release candidates which make
a best effort to follow all known rules and guidelines. In Allura's case, not
only would it help to run the dev list VOTEs more cleanly, but it would help
if PPMC members who vote +1 document exactly what steps they took to validate
the release candidate.
It's nice to see a list like this accompanying a +1 vote:
* Sums and sigs OK (log below).
* Build from source tarball succeeds and passes tests on [list
platforms].
* Extended tests pass on [list platforms].
* RAT build target passes.
* Tarball name contains "incubating".
* Incubation DISCLAIMER included.
* Expanded tarball matches version control tag exactly (diff log below).
* LICENSE and NOTICE assembled according to
<http://www.apache.org/dev/licensing-howto.html> per discussion at
[link].
* LICENSE and NOTICE up-to-date, as no dependencies have been added
since initial assembly.
* All copyleft dependencies purged as documented at [issue].
* Copyright date in NOTICE is current.
* CHANGES entry is current.
* Issue tracker clean (no open issues for this release).
...
Documented diligence by podling contributors lowers the cost of reviewing and
voting for Mentors and other IPMC members, and may help to persuade those
hanging back to participate.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
