Hi everybody, one thing that became clear to me in the recent (and not-so-recent) discussions broadly related to coding style, code duplication, code submission strategies, documentation requirements and similar things is that there have to be many different styles of approaching coreboot development out there.
As David said:
> Which development model works for a particular project (or sub-project
> within coreboot) depends on a lot of variables and I don't think we
> can expect many people to stick around if we make unfeasible demands
> of their workflow.
We can only avoid making unfeasible demands on other people's workflows
if we know these workflows. Developers might also benefit from guidelines
telling them how to approach certain projects.
On the other end, there's not really a standard on how we review things:
For example some people (I belong to that crowd) tend to accept stuff
that is part of active development (and for example have a long set of
commits on top), even if there are minor issues left (that look like
they create tons of patch handling work if fixed in the base commit of
the patch train), on the understanding that people follow up on comments
with later commits. Others seem, at times, to be rather close to give such
a change a -2 review until it's perfect and all comments are addressed
in that very commit.
Which approach is right? I don't know. (And therein lies the problem)
There are other points of disagreement in review style, and having
unspoken assumptions be in force with some reviewer but not with others is
a doubly confusing experience: we shouldn't expect things without stating
them (but for the reviewer they probably appear to be natural) and the
varying style means that every review can be a whole new experience full
of surprises.
So here's something I'd really love to do, but lack the time for:
- Interview developers in all kinds of contexts (hobbyists, corporate,
and so on) about how they work and what their constraints are
- Interview reviewers on what they consider important, how they work
and what they look for
- Document all that, coalescing common pieces
- Draft guidelines that bring the workflows (or variations thereof
that the developers agree can be implemented on their part) in line
with the review requirements and vice-versa.
- Iterate on the guidelines until there's rough consensus
The idea isn't to create some legal text to wield as a weapon during
review ("§3 says that I can do it this way!" "but §7.a.5 says that you
mustn't in this particular case!"), but to establish a baseline for common
understanding when working on the code we all care for in this project.
Such an effort probably takes half a year or longer (not full time,
but catching up with folks, and rewriting draft after draft accumulates)
and that's sadly nothing I can offer right now or in the near future.
But, if there's somebody in the community wondering how they could
participate, thinking that this is a useful endeavour and that it's just
their cup of tea, that project is for the taking.
(Or maybe this is just a stupid idea of mine)
Beware though: the "Iterate" step looks short and simple in this text
but it won't be since you'll have to reconcile all the forces pulling
at the text.
Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
signature.asc
Description: PGP signature
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
