[oe] RFC: RW for otavio
k.kooi at student.utwente.nl
Sat Jun 7 10:55:20 CEST 2008
Richard Purdie wrote:
> On Fri, 2008-06-06 at 15:02 +0200, Michael 'Mickey' Lauer wrote:
>> Ok, seems people are convinced this is a good idea.
>> Otavio, please send your mtn and ssh keys to
>> Koen<k.kooi at student.utwente.nl> and me<mlauer at vanille-media.de>.
> I have no objection to Otavio having access so please don't
> misunderstand this email in that regard. This is more a general issue I
> want to raise.
> What I'd like to see is some kind of code of conduct for developers,
> particularly new ones to ensure changes get appropriate review and we
> don't see cause any conflict.
> As guidelines:
> * Changes to class files need review on the mailing list
> * Changes to more global .conf files need review (e.g. bitbake.conf)
> * Changes to core toolchain components need review (gcc, binutils,
> libtool, pkgconfig, automake, autoconf etc.)
> * Machine configs are less sensitive but machine maintainers should be
> consulted where present and known
> * Distro config changes should be reviewed by the distro maintainers
> where known
> * Recipe changes are less sensitive but maintainers should be consulted
> where known
> The point here is to let people build up gradually. Changing the core
> infrastructure can influence a lot of people and whilst I don't want to
> discourage people hacking on it, we do need to take more care on those
> changes than ones in "lower" level recipes. I'm fairly sure most of the
> devs know and respect this, I just wonder if having some kind of more
> formal policy written down would be a good idea so people know where
> they stand?
Developers that get access trough proper channels get this text sent to
them after their key has been added:
If you are reading this, you have been granted commit access to the
award winning OpenEmbedded Project. To make things go smoothly we have
some basic rules:
1) Everything outside org.openembedded.dev/packages/ should be treated
with extreme care. Please communicate with other developers first if you
want to touch that area. If you are a distro maintainer you are of
course free to touch your distro config files without asking. If you are
a machine maintainer, please communicate first, since it's easy to get
things wrong and not all machines are good examples to copy from.
2) Think twice before using an override, usually overrides can be
avoided, especially ones like these:
You may think "I don't want to break other distributions", but in
99% of the cases your fix will unbreak other distros as well, so using
an override will cause more work for other developers, since they have
to work out the fix by themselves. You don't want other people to spend
weeks trying to solve a problem which solution is masked by a bogus
3) It's fine to fix a recipe you don't maintain, but if you are unsure
of your change, try to contact the maintainer or, if no maintainer is
listed, send a note to the OE developer mailinglist.
4) Split your changes into their logical subparts. It's easier to
track down problems afterwards with a binary search.
5) Have a clear commit messages, and mention the affected bugnumbers
6) Sync early, sync often. Nobody likes to reinvent the wheel. Merging
is easy with monotone, so don't hesitate to run sync just before your
plane takes off and your wifi gets disconnected.
You can view our policies and cheatsheets at:
I think we discussed the above text at the first OEDEM :)
More information about the Openembedded-devel