On Thu, 7 Jan 2016 01:55:01 +0100
Stefan Reinauer <stefan.reinauer(a)coreboot.org> wrote:
* Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> [151231
> 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
Registering is only a small part of the problem (and that oath stuff
did not work for everyone that smoothly in the past) of contributing
something. As I said I think most potential flashrom contributors have
a github account already.
My main point of critique is that working with gerrit is not straight
forward. I had to help several people with some steps described in the
wiki because they are not that intuitive. You receive some advantages
due to that though like the hook but grouping changesets to topics is
something that not too many newcomers initially grasp or use - on
github that's the default because everything pushed upstream is
packaged in pull requests. I deem that rather advantageous and important
even though gerrit tries to automatically group related commits
together and that seems to work quite well. We had several
contributions via github in the last year without requesting that
(rather the other way around "cant I just open a PR on github instead
of mailing") and there were 0 problems with that regarding hand-holding
the contributors (very unlike what I have experienced with gerrit).
This is no deal breaker and gerrit is surely manageable I just wanted
to object the narrative of registration being the main part of the
> - 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.
No, you are not building coreboot for 15 different operating systems
(some of them with cross compilers, some of them within virtual
machines), with 5 different libcs and for 11 different hardware
architectures and I am quite sure that jenkins does not support all of
that out of the box :)
It is not perfect at all but it was a great leap in testing flashrom
for compile-time regressions - something that has bitten us a few times
due to my cleanups in some core parts.
> - 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
If I'd be mean (which I usually are) I would say staying away from them
is not a bad side effect :) but yes that's a point. On the other side I
don't have control over much of flashrom's infrastructure and to be
honest: you (personally, Patrick and Google's flashrom hackers as a
whole) have more reasons to interfere with what I am doing than github
(who would become extinct very soon if they really do something stupid -
exactly for the reason you stated). I am not implying any hostility
from your side at all (rather the opposite!) but you need to see it from
my point of view:
When I joined the project (spring 2011) the number of contributors and
contributions were already declining rapidly and many of my own patches
piled up without even being commented on. About all other serious
contributors vanished while or even before I became familiar with the
mechanics of the community. I took over almost the whole burden of
giving support on the mailing list rather quickly and tried to suggest
and implement obvious but complex improvements while Carl-Daniel was
still somewhat active and responsive but his reactions slowly got
fainter. However, they did not completely vanish and whenever I was
about to do radical changes (of the workflow as well as the source) he
was there and restrained the approach by disliking some details and
vanishing again after speaking up and leaving me in a rather unpleasant
situation: since I became pretty much the only maintainer any criticism
of flashrom's agility became effectively a direct critique of myself
even though it was nothing I decided on my own alone (although I agree
with many of Carl-Daniel's rationales regarding a stable product).
On the other side no one stood up and tried to help either (e.g., handle
mails, reviewing or even discussing(!) any patches) which actually made
me rather ignorant regarding critics. I have written about 3000 mails
to the mailing list in less than 5 years, did two releases pretty much
on my own, leased and set up the build bot and are the only committer in
the last 1,5 years. As long as no one else shows at least some similar
dedication to the project I can't take critics very serious. Using our
patch and review process as excuse in this regard does not work either
- only a part of what I really do is reviewing patches. Much time goes
into research and support (the former often due to the latter) that is
not really related to patches at all.
All of that together with my non-freetime work led to the current
situation where everybody is becoming rather impatient with me. And
while I am looking rather optimistically at the next months I would not
be surprised if the perceived pushing away from the current model
intensifies in unpleasant forms.
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.
I don't see that overlap to exist at all. Apart from the very few
interactions with David (which I am very grateful most of the time (if
it does not only contain bashing the upstream process ;)) I don't deem
what chromiumos does as part of flashrom. The sources diverged so much
that they really have become two distinct softwares and no change in
process will change that quickly.
The only person IIRC who is a coreboot developer and who contributed to
flashrom in the last year was mrnuke (via github btw).
However, the pool of coreboot developers surely have a great potential
to contribute to flashrom and having a common infrastructure and
similar processes would make sense, yes.
> > Though I know stefanct often makes small
> > 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.
Why? What would change?
I don't think that
the lack of transparency in this regard can or should be explained by
I don't get why it is a problem - I don't have the feeling that anybody
really cares or would like to look at the respective changes. After all
the years where I pushed so many changes to the mailing list often
without ANY reaction I really doubt this would change if - for example
- I'd make two commits for any larger foreign patch. What do you
> > The auto-tag of every commit sounds like an option I could
> > 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.
Two people would be a great improvement and thus your statement gives a
hint of lack of understanding of the situation IMHO. ;)
Joking aside, I don't expect a huge change in participation through a
change of tooling due to the experience of the last years. Those who
really want to contribute find a way to do that IMHO.
> My current plan is to do a 0.9.9 release in January 2016 and
> 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.
Do you have any suggestions regarding the patchwork database? What did
coreboot do with its pw when it was switched to gerrit?
Kind regards/Mit freundlichen Grüßen, Stefan Tauner