Re: [Zope-dev] Supporting interworking with repository branches on github
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/22/2011 05:19 PM, Laurence Rowe wrote:
On 22 November 2011 21:46, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/22/2011 12:13 PM, Laurence Rowe wrote:
As you are already aware, at the SF Zope sprint we used Git and github for our work. The work contained in https://github.com/zopefoundation is by people who have already signed the Zope Foundation contributor agreement.
While the Zope Foundation deliberates on version control, I think it's likely that development will continue using Git and Github. We want to do this in a way that maintains flexibility for code committed to Git to also be committed to svn.zope.org, so it would be helpful to get a list of Name, Email, username for svn.zope.org committers to facilitate the creation of an author mapping file. (Presumably this information is in LDAP or similar.)
We would of course be happy to hand administration rights of the github organization to the Zope Foundation if it was felt to be helpful in ensuring that contributions to that repository counted under the committer agreement.
Please don't try to jump the gun on the process here: you should be thinking of the existing Github branches as merely "scratchpads" for the sprint work, which should be merged into the canonical repository when they are ready. It is not appropriate for a small subset of the community to preempt this kind of choid: "ask forgiveness rather than permission" is *not* going to fly here, and trying to push harder only irritates folks you might otherwise persuade.
I think some indication of a timetable for that process is necessary.
I said earlier that this kind of decision would be best addressed at the annual meeting of the foundation in Q1 2012. I also indicated that I didn't think github vs. the SVN status quo was the only possible choice.
The view of many of those at the sprint was that it would be less work to simply fork and develop a custom publisher for Plone.
I imagine that the effort is substantially bigger than you think. I also don't think that the damage to community goodwill would be negligible here.
I think there is value to keeping that work under the auspices of the Zope Foundation as it may be helpful for other projects currently on Zope 2. But realistically, unless the Zope Foundation is interested in supporting those developers looking to work on a new project by enabling them to use a modern version control system then my view is unlikely to prevail.
First, this is not a "new project": the existing github repos contain what are really a handful of commits across two projects (Zope and Products.ZCatalog; the ZConfig and Products.PythonScripts repos don't have any commits). The deltas are very small compared to the installed base, and could be trivially landed back in SVN today, either on the respective trunks or on branches. Second, it is already feasible to work with modern VCSes against the existing SVN repository: I've been doing it with bzr for literally years now; I know of lots of documentation on using git against SVN as well. Of course, Github is more than a VCS, but its main advantage over other solutions lies in being able to accept casual contributions from non-core developers, which is hardly in scope for the early phases of the Zope4 effort. What *is* being "blocked" here is a push by a relatively small group of committers[1] to impose a unilateral change to a long-established development culture, without prior consultation, and backed by a not-very-thinly-veiled threat of a fork. [1] I count you, rossp, mikko, and garbas as having non-merged branches. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7NCEkACgkQ+gerLs4ltQ73uACfY1d309afRKU0K1d4/BTV4Uf7 RS0AnjE6xFQro9pkbH3Yqk7mnOd8FbFk =t4Eo -----END PGP SIGNATURE-----
On Wed, 23 Nov 2011 09:50:49 -0500, Tres Seaver <tseaver@palladion.com> wrote:
Second, it is already feasible to work with modern VCSes against the existing SVN repository: I've been doing it with bzr for literally years now; I know of lots of documentation on using git against SVN as well. Of course, Github is more than a VCS, but its main advantage over other solutions lies in being able to accept casual contributions from non-core developers, which is hardly in scope for the early phases of the Zope4 effort.
github enables a peer review process: while everybody who signed the plone committer agreement could just commit to the plone repo, we do pull-requests and somebody else with commit rights checks the request and merges. It's not about git locally - I'm doing that for years, too - it's about git server side. florian -- Florian Friesdorf <flo@chaoflow.net> GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC
On 11/24/2011 01:29 AM, Florian Friesdorf wrote:
On Wed, 23 Nov 2011 09:50:49 -0500, Tres Seaver<tseaver@palladion.com> wrote:
Second, it is already feasible to work with modern VCSes against the existing SVN repository: I've been doing it with bzr for literally years now; I know of lots of documentation on using git against SVN as well. Of course, Github is more than a VCS, but its main advantage over other solutions lies in being able to accept casual contributions from non-core developers, which is hardly in scope for the early phases of the Zope4 effort. github enables a peer review process: while everybody who signed the plone committer agreement could just commit to the plone repo, we do pull-requests and somebody else with commit rights checks the request and merges.
We've never had a problem with peer review before. People review the commit lists which receive all commits with full diffs and react if they see something off. That is a very well working peer review system. I don't see that improving with github; in fact I see it becoming worse: commit emails no longer get diffs at all, and people are less likely to look at a webinterface for a quick review than they are to take a quick look at an email. The move from Plone to github certainly made me stop all review work, where I reviewed all commits to core code before. Wichert.
On 24 November 2011 07:58, Wichert Akkerman <wichert@wiggy.net> wrote:
On 11/24/2011 01:29 AM, Florian Friesdorf wrote:
On Wed, 23 Nov 2011 09:50:49 -0500, Tres Seaver<tseaver@palladion.com> wrote:
Second, it is already feasible to work with modern VCSes against the existing SVN repository: I've been doing it with bzr for literally years now; I know of lots of documentation on using git against SVN as well. Of course, Github is more than a VCS, but its main advantage over other solutions lies in being able to accept casual contributions from non-core developers, which is hardly in scope for the early phases of the Zope4 effort. github enables a peer review process: while everybody who signed the plone committer agreement could just commit to the plone repo, we do pull-requests and somebody else with commit rights checks the request and merges.
We've never had a problem with peer review before. People review the commit lists which receive all commits with full diffs and react if they see something off. That is a very well working peer review system. I don't see that improving with github; in fact I see it becoming worse: commit emails no longer get diffs at all, and people are less likely to look at a webinterface for a quick review than they are to take a quick look at an email. The move from Plone to github certainly made me stop all review work, where I reviewed all commits to core code before.
I'm not sure I agree with that, it's certainly been an issue in CMF for instance. Where we really miss out is that only a fairly small group of people feel confident enough to commit their changes, and as a group we do a poor job of encouraging new contributors as patches are often left in the bug tracker. I certainly find it much easier to review a pull request and click merge from the github interface (leaving it to Jenkins to validate that the tests continue to pass.) For the long term health of the project this is vital, we're not replacing the developers we're losing. It certainly shouldn't be that difficult to produce our own emails with full changesets for Plone, it just requires someone who misses them to pick it up. Laurence
participants (4)
-
Florian Friesdorf -
Laurence Rowe -
Tres Seaver -
Wichert Akkerman