> 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
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


Reply via email to