On 2/19/14, 1:59 PM, Bill Havanki wrote:
I'm happy with the active vs. emeritus stuff. +1 to Josh's idea of pinging
somebody before emeritization.
I'm +0 on including C == PMC. Thinking about if someday the PMC doesn't
want that.
Making sure that we *do* talk about it is exactly why I suggested we
reference in the by-laws. Forcing ourselves to do things "right" later :)
About trimming commit access for security: Even if the ASF and ASFers lock
down their accounts, reuse of passwords on other less diligent systems
(Kickstarter is but the latest) keeps the threat alive. Also, recall that
not so long ago, Apache JIRA was breached [1]. It's not unheard of for
accounts to lock after so many days of inactivity. As long as folks are
notified, and it's easy to get unlocked, I still like the idea. It can be a
real long time, say a year or two.
[1]
http://www.theregister.co.uk/2010/04/13/apache_website_breach_postmortem/
Bill
On Wed, Feb 19, 2014 at 4:10 PM, Josh Elser <[email protected]> wrote:
Overall, it looks good to me. I didn't weigh in on the doc via comment too
much, but I agree with the comments that Sean, Bill and Mike raised.
A few extra things:
I believe we should state somewhere in the bylaws the Committer==PMC
stance. The breakdown of each role (C, PMC) makes sense to me, but putting
in writing the practice we follow is a good idea. This also forces us to
have a serious discussion with PMC to achieve a 2/3 majority (alter the
by-laws).
Regarding emeritus status (since that was also discussed on the mailing
list), I think the verb-age in the doc is good (specifically no revocation
of commit ability). The only ambiguity I see is who is in charge of
updating emeritus status of a person due to idle? This may be hard to
judge: does it include things like IRC? Non-ASF forums related to Accumulo
(vendor forums, stackoverflow, etc)? Should the idle member be contacted
before switching to idle to ensure that they're not going to just un-idle
themselves? It seems easy to stomp on someone's toes by moving them to
Emeritus -- I think requiring an attempt of contact before status change is
the easiest, general solution.
On 2/18/14, 6:49 AM, Mike Drob wrote:
Thanks for putting it in a Google Doc, Arshak!
What issues do y'all see with this document in it's current state?
Personally, I think it looks fine and would be willing to start a vote on
it, but I get the impression that east coast weather has prevented some
folk from looking at it, so maybe another couple of days is fine.
Mike
On Sun, Feb 16, 2014 at 7:18 AM, Arshak Navruzyan <[email protected]>
wrote:
Oops, yes of course! It's editable.
On Sat, Feb 15, 2014 at 7:01 PM, Bill Havanki <[email protected]
wrote:
Thanks Arshak! Can you either allow editing or commenting?
On Fri, Feb 14, 2014 at 6:10 PM, Arshak Navruzyan <[email protected]>
wrote:
Say no more ...
https://docs.google.com/document/d/1uR8vhIQcKGA6IEtbbF5D7UL_
e6WGtfXMUQHp8Fwvg_E/edit?usp=sharing
On Fri, Feb 14, 2014 at 1:54 PM, Christopher <[email protected]>
wrote:
Perhaps some ambitious volunteer could start a collaborative draft of
Accumulo's bylaws in Google Docs or something, using ZK as a starting
point. After it stabilizes a bit, we could push it to the project
webpage as a draft and vote on it?
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Feb 14, 2014 at 2:11 PM, Mike Drob <[email protected]>
wrote:
I didn't get that impression from reading their document. While C
and
PMC
are two distinct roles, there is nothing stating that there cannot
be
overlap, and the fact that there is 100% overlap is entirely
orthogonal.
On Fri, Feb 14, 2014 at 10:23 AM, Josh Elser <[email protected]
wrote:
This would change the existing Committer == PMC, no?
That's the biggest thing I noticed scanning over the document.
On 2/14/14, 1:19 PM, Mike Drob wrote:
I think we should have some Bylaws, as that gives us more
structure
to
operate under.
I propose that we adopt the ZooKeeper bylaws, replacing all
references
to
ZK with Accumulo.
http://zookeeper.apache.org/bylaws.html
What say ye?
Mike
--
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -
