Re: [flashrom] New development guidelines after 0.9.7

[Carl-Daniel Hailfinger]

Am 18.07.2013 19:15 schrieb Marc Jones:
> On Wed, Jul 17, 2013 at 7:21 PM, Stefan Tauner <
> [e-mail]> wrote:
> > Our current development model with elaborate reviews has not been
> > working for a while now. Therefore, beginning with the release of
> > flashrom 0.9.7 our strategy on merging patches will change radically.
> >
> > The current rules regarding committing to subversion can be found here:
> > http://flashrom.org/Development_Guidelines#Committing
> > Essentially they prohibit merging non-trivial patches without explicit
> > consent from another community member and is not too specific on the
> > requirements for an ack.
>
> Not to add undue overhead to the project, but why not go to git and gerrit?
> Automates a lot of this stuff and is already setup on coreboot.org.

<rant>
Because I think git sucks? I might be open for a switch to mercurial
because it has usable revision numbers and a user-friendly interface.
But git... without a command line and the right tree, I'll never know if
commit hash deadbeef is before or after badc0ffe. Besides that, I
managed to learn mercurial in a few hours and gave up on git after a few
days.
And gerrit needs known insecure OpenID for authentication. I'm not going
to get any OpenID capable account just to satisfy a defective login
mechanism. Apart from that, it seems gerrit pretty much killed all patch
discussion on the coreboot mailing list. It also was pretty much
unsuitable for offline use (no idea if that changed). While those
properties may work for coreboot development (with very infrequent
contributions/reviews by outsiders), I fear it will introduce an
additional barrier for flashrom.
</rant>

Regards,
Carl-Daniel

New development guidelines after 0.9.7

[Stefan Tauner]

On Thu, 18 Jul 2013 23:11:08 +0200
Carl-Daniel Hailfinger  wrote:
> While those
> properties may work for coreboot development (with very infrequent
> contributions/reviews by outsiders), I fear it will introduce an
> additional barrier for flashrom.

While I don't want to pour more oil into the flame(war) I never
intended to start, I just have to reply to that.

I have not seen a single project that suffered from less contributions
after switching from svn to git, rather the extreme opposite. I have no
numbers - maybe someone did studies about that - but I am *very* certain
that switching to git would rather lower the barrier, especially if
that would imply taking pull requests through github.

New development guidelines after 0.9.7

[Antonio Ospite]

On Thu, 18 Jul 2013 23:11:08 +0200
Carl-Daniel Hailfinger  wrote:

[...]
> <rant>
> Because I think git sucks? I might be open for a switch to mercurial
> because it has usable revision numbers and a user-friendly interface.

Sorry, just 2 (flaming?) cents from a random lurker who likes flashrom:

The "problem" with git is that it throws its design and implementation
right at your face, Linus-style; however, after you struggle a bit and
make a vague idea of how it works internally the interface becomes a
lot easier to get; and then you become an over-confident zealot, sure,
but the Stockholm syndrome is a different problem :)

Anyways, from the point of view of a possible external contributor I
just can't stand SVN, it does NOT differentiate between the Author and
the Committer of a change, so authors external to the project are not
recorded explicitly in the project history and one has to rely to
workarounds like the Signed-off-by line (which by the way in linux has
the very specific meaning of "I accept the Developer Certificate of
Origin[1]", its not just to name the author[s]).

[1] http://elinux.org/Developer_Certificate_Of_Origin

That means that just to list all my contributions I have to parse commit
messages, if I am lucky; not pretty.
> From the point of view of a possible external contributor any system

which allows to differentiate explicitly between the author and
the committer of a change is fine :)

A plus being an easy workflow to export/import and send patches with
authorship information preserved.
> But git... without a command line and the right tree, I'll never know if
> commit hash deadbeef is before or after badc0ffe. Besides that, I
> managed to learn mercurial in a few hours and gave up on git after a few
> days.

About serializing history: there are _tags_ for fixing points in time
and given how cheap they are in git, you can have as many as you want;
however in a distributed scenario sequential ids do not _always_ make
sense, do they?

And really, in a copy/paste world do we still care about human readable
ids for everything?

Going back to read-mode, sorry for the noise.

Regards,
   Antonio