Revert "busybox: Disable busybox shadow support for Angstrom"

[Koen Kooi <k.kooi@student.utwente.nl>]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

Hi,

Graeme and I reverted "busybox: Disable busybox shadow support for 
Angstrom", the commit message explains it:

"Revert "busybox: Disable busybox shadow support for Angstrom"
* Do NOT, I repeat NOT touch such core distro files without approval of 
distro maintainters
* This is the wrong solution to the problem, please raise a discussion 
on email list!

Signed-off-by: Koen Kooi <koen@openembedded.org>
Signed-off-by: Graeme 'XorA' Gregory <<dp@xora.org.uk>

This reverts commit 4339d706baf166732d6b7d3b2bedb0c54ce76cbf."

I looked at the instructions new commiters get sent, and it says:

"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."

Maybe that is a bit unclear since it implies that packages/ is clear of 
distro files, which it isn't. Attached is the full version of the 
welcome message so people can suggest improvements.

regards,

Koen




[-- Attachment #2: welcome.txt --]
[-- Type: text/plain, Size: 1928 bytes --]

Hi,

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:

     do_compile() {
         oe_runmake 
     }	

     do_compile_myfirstdisto() {
         oe_runmake -D_GNU_SOURCE
     }
    
    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 override.

 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 if appropriate.

 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:
 
 * http://www.openembedded.org/wiki/Policies
 * http://www.openembedded.org/wiki/MonotonePhrasebook