refactoring mokopatches

Andy Green andy at openmoko.com
Tue Mar 11 14:18:02 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> 
> On Tue, 11 Mar 2008 12:49:59 +0000, Andy Green <andy at openmoko.com> wrote:
>> Oh absolutely.  But we should push the patches through this list before
>> they go off anywhere so we can all see what is going down.  Likewise if
>> anyone is helping out on subtasks, the path to that branch is through
>> this list and yourself... although you can expect debate sometimes,
>> which is the point.
> 
> So we agree we will be using mailine patch process. All patches should be
> sent to this list
> before they can get integrated.
> 
> Acked-by entries are also nice as we can validate at least one other person
> has tested
> the patch.

Yes I'm not interested in anything less transparent.  And in terms of
tree access, the owner of the tree is the only one who pushes anything
there.  If someone else wants to work off it, it is trivial to clone and
branch locally, then propose what you did on top back to the owner, or
keep your tree tracking the original or whatever.  We don't need more
than one pair of hands on any branch and the consequent "surprises" for
sure.

> Also, I'd propose everyone to read:
> Documentation/SubmittingPatches
> Documentation/CodingStyle
> Documentation/SubmitChecklist

We don't do too badly on it for patches these last months, but in fact
AFAIK nobody does checkpatch.pl and sparse here.  That's something we
should take on and we'll be the better for now we plan to be serious
about upstream.  But at the same time we work with U-Boot which spews
hundreds of compile warnings from all over even with pure upstream.

> So we shrink down the effort on rework based on coding style issues and
> malformed patches.
> 
> If anyone need a help with git, I've a few tips & tricks in my blog:
> http://felipebalbi.com/blog/?cat=8
> 
> I tried to make it as simple as possible :-)

Wah your git-fu kicked my ass :-)

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH1oaKOjLpvpq7dMoRAg8eAJ97pPfLC/Wgk8TRaj0ileDFeR6lJgCgg/I9
uaThoSIELCp0+SuCWWFCwpA=
=etf/
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list