On 10.08.2015 04:17, David Hendricks wrote:
On Sat, Aug 8, 2015 at 1:23 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I would like to avoid git at all costs, even if it means I have to host something non-git as main repo myself and pay for the hosting. Cloning git into a local svn on my side is not an option because it combines the worst usability aspects of git hosting (no version numbers) and svn clients (no offline commits).
+1 to what Patrick said, too.
I would be open to using mercurial (as master) because it at least has some sort of usability and can provide (conceptually limited) version numbers. I have worked for a few years with mercurial and the version numbers are extremely helpful even if they are per-branch and only semi-stable.
The point of this is that maintaining two different SCMs and code review systems is a pain. Just keeping SVN up-to-date requires dealing with several (maybe dozens?) extra packages that would not be needed otherwise (Stefan can clarify).
@Stepan: It would be good to know which of patchwork or svn (or both) cause extra maintenance burden. AFAICS at least svn seems to be automatically getting security updates on ra (coreboot server). Patchwork seems to require manual updating similar to what gerrit/jenkins require.
If we migrate off patchwork, is there a way to keep/import the old data into some other tool?
About jenkins: Seems to be a good idea and would help detect patch bitrot.
Agreed, but still doesn't really help lower the maintenance burden.
Given that it feels like most of the upstream flashrom effort over the last two years was mostly trying to forward-port patches cleanly and/or make them work again, I think the maintenance burden from a flashrom developer POV would be lowered. Or did you mean the server administration burden?
About gerrit: Last time I tried gerrit the usability was horrible:
- needs registration (like a forum)
- has no usable mail interface (like a forum)
Who says people can't send patches via mail? Those who want to stick with the current process (but with an arguably better SCM) can certainly do so. I don't see why it must be one or the other.
Hm. In the end, we have to decide whether the tree will be managed directly by humans or indirectly via Gerrit. I doubt we can have both at the same time without pretty explosions.
Registration does kind of suck, but again, many active developers already have a GitHub account (if not a Google account).
IIRC OpenID had/has soem security bugs which partially stems from the design. That's one o the reasons why I wanted to avoid Gerrit.
- you can't work on drafts for a review unless you keep the web browser
window open (like a forum)
That't simply incorrect. One can upload drafts and work on them just as with any other patch. Here's some more info: http://www.coreboot.org/pipermail/coreboot/2012-November/071963.html
Thanks, I stand corrected. I thought only patch drafts were possible, but apparently comment drafts on regular patches are possible as well.
If we really want to move to gerrit, we should close the mailing list as well and switch to a forum which has roughly the same usability as gerrit. I really mean it. We seriously should consider moving to a forum _if_ developers prefer forum interfaces to mail.
Would you also make the same recommendation for the coreboot mailing list? I doubt that anybody on the CB mailing list would want to do that.
I do prefer email interfaces, but I have no idea what others think. That said, it seems the switch from patchwork to gerrit for coreboot seems to have been welcomed back then. I assume the switch was done to get some gerrit features (jenkins integration) not present in patchwork.
Regards, Carl-Daniel
2015-08-11 2:28 GMT+02:00 Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net>:
@Stepan: It would be good to know which of patchwork or svn (or both) cause extra maintenance burden.
AFAICS at least svn seems to be automatically getting security updates
on ra (coreboot server).
We run apache (with mod_dav_svn) just for svn. It's automatically updated alright, but it still increases the system's surface.
If we migrate off patchwork, is there a way to keep/import the old data into some other tool?
Since it's unstructured data that will be hard to automate.
Hm. In the end, we have to decide whether the tree will be managed
directly by humans or indirectly via Gerrit. I doubt we can have both at
the same time without pretty explosions.
Even with gerrit, it's always managed by humans. Gerrit never presses the 'submit' button by itself.
IIRC OpenID had/has soem security bugs which partially stems from the
design. That's one o the reasons why I wanted to avoid Gerrit.
OpenID provides open federation. There are some impersonation attacks, some of which can be defused by using https. Gerrit also supports OAuth2 now, which uses preshared credentials per authentication provider (currently for Google and Github). That reduces the impersonation risk, but is a maintenance mess - and definitely not "Open Web".
There are three conflicting goals with regard to identification: 1. to not store credentials on every. single. server. on. the. net. (hence no local auth scheme) 2. to not lock users (and services) into a few select identity providers (hence OpenID) 3. to prevent some (not all) impersonation attacks (hence preshared credentials in OAuth2)
We now provide both: reliable authentication (OAuth2) and open federation (OpenID). That allows users to decide on the trade-off (while we don't need to protect a credentials database).
I assume the switch was done to get some gerrit features (jenkins
integration) not present in patchwork.
The switch was done because patchwork became a dumping ground for non-actionable diffs.
The main advantages of gerrit over patchwork (IMHO) are: 1. you can directly work from the list of open commits (in patch work you can only reply by hunting down the thread that it archived in your local mail client. if you weren't subscribed back then, you're out of luck) 2. through the git push model of contributing you're guaranteed to have context for the commit. compare "all history that leads to this commit" to the diffs in patchwork: uh, that might be based on r5200 or maybe r1500 or is it even manually edited and doesn't apply cleanly to anything?
That we automatically test-build the commits and thus have some basic sanity checks is a very useful bonus. But at least for me that wasn't the reason for switching tools.
Patrick
-
Carl-Daniel Hailfinger -
Patrick Georgi