On Fri, Mar 20, 2015 at 5:49 PM, Alan Cabrera <[email protected]> wrote:
> I will add that we don't necessarily have to do use the Steve code per se
> and it's my opinion that collecting votes for a release is pertinent for
> this project.

Yeah, I once looked at the STeVe code base contemplating how to support
release votes but gave up because it was too ambitious.

I'd be willing to chip in if I don't have to go it alone.

>> On Mar 20, 2015, at 5:26 PM, Daniel Gruno <[email protected]> wrote:

>>> *   Hook to LDAP for binding votes.
>>
>> Very tricky, as STeVe was designed to hide what people have voted, even if
>> you have disk access.

The use case here is public voting.  It may be that the current STeVe code is
simply not a suitable starting point.  Or it may be that we can produce some
modularized Python, portions of which could be shared by both an STV secret
ballot and public ballot under Apache release voting rules.

>>> *   Email sent out to dev list when vote launched.
>>
>> Currently, every person receives a personal email with a vote link. That's
>> part of STeVe's anonymity.

For release votes, I think one email to the dev list is appropriate.  Sending
out individual votes to all PMC members seems like overkill.

We'd also want to support adding commentary to the vote (explaining what you
checked).  Maybe even checkboxes for the standard stuff (tests, sums and sigs,
RAT output, top-level LICENSE/NOTICE, no binaries...)

And furthermore, we'd definitely want to support non-binding votes.

>>> *   Automatic close at scheduled time if enough votes have been cast.
>>
>> I think a smarter way would be to set it to remain open until N (binding)
>> votes have been cast.  That should be easy enough to implement.

The VOTE has to be held open for the minimum time, though, so that everyone
gets their chance to vote.

>> PS: I am of a forgetful nature and with a fleeting memory, so please do nag
>> once in a while if I or the others don't pick up on your ideas.

The thought of nagging you like that just feels so wrong.  I ought to be
willing to fix my own bugs.

Marvin Humphrey

Reply via email to