[flashrom] Proposed changes to flashrom hosting and workflow

[Stefan Reinauer]

* Stefan Tauner <stefan.tauner at alumni.tuwien.ac.at> [151231 19:18]:
> My counterproposal is to use gitub instead of Gerrit.

>  - We (relatively) often get patches from one-time contributors which
>    is way easier on github because "everybody" has an account there and
>    knows how to work with it (and if not it is straight forward
>    compared to gerrit).

Unlike with gerrit, you explicitly have to sign up with github. With
Gerrit you can use any Oauth2 provider that you already signed up with,
significantly lowering the entry barrier

>  - We don't really need jenkins. I am not a big fan of CI although I am
>    a fan of build testing (hence flashrom is build tested for over 30
>    architecture/OS combinations manually). Depending on how it would be
>    to interface my build bot with jenkins it would however be an
>    improvement (not sure if it is worth it though).

That is exactly what we are doing with the current infrastructure, and
it has worked quite well for the coreboot project for about five years.
Sure you can roll your own and probably end up with something slimmer,
but jenkins is well tested and security reviewed, so it is very
convenient and basically out of the way once you set it up.

>  - The only reason to avoid github for me would be due to its
>    proprietary nature and related problems (lock-in etc).
>    Please give me other reasons if you prefer coreboot.org-hosted
>    gerrit over github.

I don't feel as strongly about trusting github with all of your project
data, especially as you can recreate the repository from any checked out
tree, but I remember the libreboot guys having strong opinions about
github.

With a fair amount of overlap between developers, using one common
infrastructure for both coreboot and flashrom seems to make sense to me,
but honestly, any improvement of both process and tooling would be
greatly appreciated. Right now we are going out of our way with one-offs
to keep the environment painful.

> > Though I know stefanct often makes small corrections/modifications to
> > patches before submitting them (because our code review process makes even
> > small amounts of back-and-forth comments so cumbersome). At least this way
> > such changes can be tracked trivially on-line by diffing the N and N-1
> > patch revisions in gerrit.
> 
> The reason is not because the back-and-forth is cumbersome but because
> I am a perfectionist who does not want to bother others with my
> annoying views of details and I don't expect anybody to care about these
> changes like me (this does not always hold). The same goes for commit
> messages. With Carl-Daniel I do exchange my views about these kind of
> things *if* there is any exchange that is ;)

I think a cleaner work flow in which it is clear which changes have been
done by the original author and what changes have been done by Stefan on
top of that would be very beneficial for the project. I don't think that
the lack of transparency in this regard can or should be explained by
perfectionism.

> > The auto-tag of every commit sounds like an option I could agree with.
> > It would preserve the convenience of the global strong svn commit ID
> > even for git.
> > However, I don't know if this would be acceptable for Stefan (especially
> > from a merging perspective).
> 
> We have the infrastructure for using this kind of version strings since
> about 2,5 years and there is a patch that would make flashrom use them
> in prints which is lingering uncommented in the mailing list since
> August 2013. It might not be exactly what we want eventually, but if
> there are no comments I'll have to decide on something...

You guys should explore what coreboot has done in this area, also with
the work on reproducible builds. As an anecdote, I was insisting on the
usefulness of sequencial commit ids just about until the day we switched
coreboot to git. What you really want is a process that enables
interactive development, tools to track the process, and more frequent
releases. Unless you want to make sure that there are exactly two people
working on this project, in which case all of this infrastructure talk
is really overkill.

> My current plan is to do a 0.9.9 release in January 2016 and switch to
> git afterwards. I'd like to keep patchwork at least for a while and
> figure out a way to keep the patches.

Cool. Please let me know what your preferred direction is by the end of
this month then. We are currently in the process of migrating
coreboot.org's services and the old infrastructure as we have it today
will most likely be going away around that same time frame.

Stefan