[LinuxBIOS] Patch quality

[Stefan Reinauer]

* ron minnich <rminnich at gmail.com> [071029 23:51]:
> One possibility is, the next time someone comes in, rather than just
> critiquing the code, we get a group of people -- say 3 or 4 -- each of
> whom takes on the responsibility for a directory, starting at the
> leaves. Something like this:
> 
> superio (s)
> southbridge(s)
> northbridges(s)
> cpu
 
In addition: New components are undangerous to add as long as they are
signed off and do not contain proprietary licensed code. We can just
commit them before finding a shepherd - Nothing will break except the
fresh code is maybe not working yet. 

The advantage is clear: Instead of keeping iterations of work on the
vendor side while we waste our time on writing mails, we can spend the
same time fixing the code ourselfes and take that burdon off the
committers. Repeatedly asking for patches because of missing full stops
and unsigned char -> uint8_t conversions is more effort than producing a
stressful interface to potential committers. We need to become easier to
handle in this way.

> once those are absorbed, we do the mainboard, and then, the target.
> 
> This is the 'shepherd' model.

I like this idea a lot. The shepherds are the extended and more
work-directed versions of reviewers. (which should not go away)

> This team would form dynamically and communicate (via the list?) on
> the changes that have to be made. But people would have to sign up for
> a given piece, and a deadline.
 
How would signing up work? We have a pretty active community with many
people having something to contribute. Assigning tasks and duties and
deadlines might very well scare people off that would have something
valuable to say, otherwise. Therefore I believe we should handle this
very casual. 

> But if we can't do better when someone like Morgan comes in, it's
> going to hurt us. I don't feel (me included) that we did what we
> needed to do. The 'code critique' approach works in some cases, but
> for those who need more assistance, we need a different procedure,
> which would be more active and helpful.

I feel we became far to strict with the requirements to the contributors
lately. 

1. We do not want to educate anyone that does not ask for it
2. We do want to get as many contributions as possible, therefore it
   should be as easy as possible.
3. We need to beware of legal issues
4. We aim at having code of the best possible quality.
5. We do not want to break the tree.

Code reviews must protect us from issues with 3 and 5.

Shepherdship shall help us with 2 and 4.

Can we constitute this in the development guidelines?

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866