[flashrom] Proposed changes to flashrom hosting and workflow

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Tue Aug 11 02:28:44 CEST 2015


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




More information about the flashrom mailing list