[Zope-dev] Zope 4 release management

[Alex Clark]

On 2/1/12 6:08 AM, Jens Vagelpohl wrote:
>
> On Feb 1, 2012, at 00:05 , Alex Clark wrote:
>> Bottom line: Zope stands to benefit greatly if the current active developers keep an open mind about how/where/when development of Zope software should occur. There are plenty of people that still think Zope software is cool, and plenty of skilled developers on github that could potentially help move it forward.
>
> This discussion seems to unnecessarily combine at least two distinct issues:
>
> - what RCS software to use
> - where to host it
>
> It may be easier if we disentangled them.


Traditionally it was easier, but now-a-days with github and bitbucket 
they are harder to disentangle.


>
> Speaking purely as a developer, I'm leaning to Git when it comes to the RCS software decision between Subversion and Git. But I can use both equally well. Where it is hosted, well, purely as a developer it doesn't matter to me, unless I need to give up too much personal data to get access.
>
>  From the perspective as a Zope Foundation member the RCS software decision is a technical detail that doesn't matter much. I'm more concerned with the "where" question, though. The Zope Foundation is tasked with safeguarding the software released under the Zope Foundation umbrella, and it is tasked with enforcing the contributor agreements everyone signed. Commits can only be made by signed contributors, and contributors are specifically disallowed to take outside code they don't own and commit it to the repository. We already have the technical infrastructure in place for most of this, such as ZF-controlled logins on svn.zope.org, access only via SSH key, etc. Our current "where" can be fully trusted, so to speak, and the people tasked with maintaining this infrastructure are known, accountable, and part of the foundation.
>
> My third role is secretary of the Zope Foundation Board of Directors and in that role I collect and maintain contributor applications and the (private) data associated with it. I can vouch that our current means of storing this data is reasonably secure. I can't make that assertion if the data is stored somewhere out of Zope Foundation control.
>
> My last role is admin for the ZF infrastructure and servers. In that role I would be involved in executing any changes in repository hosting. If only the RCS software changes that's a chunk of work, but doable. Git service can be added to the ZF infrastructure and packages can be migrated into Git repositories, probably on a "as-needed" basis. Most of the current authentication and safety infrastructure could stay in place.
>
> On balance and taking all my roles into account, sticking with SVN and the current hosting is the most attractive option. Moving to Git in the current hosting environment is doable, it means work, but I feel I've done my job keeping the software, access to it, and contributor data as secure as possible. Any option that involves moving to a different host altogether not only makes me feel I haven't done my job, it may also throw up legal questions.

Fair enough, all of this sounds reasonable. My only point was that it 
should be someone's role in the ZF to take a look around at the 
available options in today's software development ecosystem. If 
github.com is attractive to you, great. If it's not and you are happy 
with the status quo, also fine. But like anything else, there are pros 
and cons associated with either approach.


E.g. Plone's move to github has been a challenge for a lot of people, 
and we continue to struggle with it everyday; but I know it was the 
right move for the software and the project so I feel good about what we 
are doing.


Alex


>
> jens
>
>
>
>
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>   https://mail.zope.org/mailman/listinfo/zope-announce
>   https://mail.zope.org/mailman/listinfo/zope )


-- 
Alex Clark · http://pythonpackages.com