On 2015-03-22 21:06, Alan D. Cabrera wrote:
On Mar 20, 2015, at 8:10 PM, Marvin Humphrey <[email protected]> wrote:
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.
Yeah, this is my thinking as well. It’s a bit monolithic and I think that it’s
due to how the project came about. Much of the code mixes concerns and so
causes discussions about extensions of functionality awkward.
I agree we need to make the code base more modular. I’d like to see it broken
out into three parts:
steve-base - generic base level utilities and model management - the M and C of
MVC
For what it's worth, I've started refactoring the web UI to use a
library for the basic vote features like fetching issues/elections and
voting.
this is currently stored in cgi-bin/lib - this should probably be moved
elsewhere and fiddled with so it can turn into a fully operational
library for doing the voting/setup via command line too.
My plan is/was that anything you can do via the REST API, you can do
with this library as well, so you can add CLI scripts for it all as
well, should that be needed.
I realize that this still lacks the essential part, the STV
calculations, but I'm working on it! ;)
With regards,
Daniel.
steve-commands - standalone commands for vote management - command line C of MVC
steve-web - the web site that Dan is working on - the V of MVC
steve-attic - the old perl etc. code base
I think that it’s important that we deliver tools and libraries to the
community and wider world audience that are not entangled with ASF specific
processes. steve-base and steve-commands can be published to pypi as well.
I also think that it’s important to modularize the code base so that others can
experiment with either/both command line and web/REST based tooling; let a
thousand flowers bloom.
I propose that we move Dan’s pytest to steve-web, all the perl detritus to
steve-attic, and we start discussing what goes into steve-base and
steve-commands such that they can be used by other websites such as whimsy,
panopticon, etc.
The way to accomplish this is to make three project directories:
https://svn.apache.org/repos/asf
<https://svn.apache.org/repos/asf>/steve/steve-base
https://svn.apache.org/repos/asf
<https://svn.apache.org/repos/asf>/steve/steve-commands
https://svn.apache.org/repos/asf/steve/steve-web
<https://svn.apache.org/repos/asf/steve/steve-web>
https://svn.apache.org/repos/asf/steve/steve-attic
<https://svn.apache.org/repos/asf/steve/steve-attic>
We have public discussions when we move things around so that we can at least
implicitly document what are all the bits lying around
https://svn.apache.org/repos/asf/steve/trunk
<https://svn.apache.org/repos/asf/steve/trunk>
are for as well as how we can improve them to be more modular with the above
goals in mind.
I also think that we should use tox/travis CI as well as coveralls; I can get
us going on that. Finally, would anyone mind if we moved to git?
Regards,
Alan
