Category talk:Policy

The core OE team has agreed to move the dvcs from monotone to git. This was under the condition of coming up with a sensible review and commit policy. Many opinions were voiced and quite naturally, it has become a bit hard now to string back together the loose ends. This discussion page will attempt to aid in that.

Before the discussion dried up a bit (I guess everyone said what needed to be said), Leon suggested to keep on going with the current gentlemen's agreement. Parallel to that discussion we saw the suggestion of defining a "core of OE". Philip picked this up in his reply to Leon's mail. I (Laibsch) think this might indeed be a good and well-balanced option to reconcile the views and concerns expressed. Let's try see if we can specify something here.

gentlemen's agreement

• non-core developers should not commit changes to classes/conf without ACK from a core dev (IMHO we need to make it more clear who counts as core dev)
• non-core developers should not commit changes to any of the core packages without ACK from a core dev (IMHO we need to make it more clear who counts as core dev)
  • udev
  • busybox
  • kernels (IMHO, machine maintainers should be allowed to make changes which clearly affect their machine only via an override)
  • glibc
  • what else?
• devs should of course be reasonably sure any commit does not introduce breakage elsewhere, core or otherwise
• intrusive changes are tested in topic branches first from which they are merged into .dev
• TODO: merge in content from Review process page
• what else?

core

tested automatically by autobuilder which gives feedback in case of breakage. Devs making a commit should be reasonably confident their commit does not introduce breakage in core (see gentlemen's agreement).

needs-to-build

machine

• openmoko device
• spitz
• qemuarm
• ipaq (which one specifically?)
• beagleboard (I think this one is picking up popularity)
• what else?

distro

• angstrom
• anything else?

target

• console-image
• gpe-image
• what else?

This of course very quickly leads to an explosion in numbers. We need to make sure the list is actually manageable. There will be the occasional adjustment to the list, I assume.

needs-to-run

• qemuarm console-image and gpe-image
• qemux86 console-image and gpe-image?
• anything else?