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