Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!

Difference between revisions of "Category talk:Policy"

From Openembedded.org
Jump to: navigation, search
(gentlemen's agreement)
(gentlemen's agreement)
Line 13: Line 13:
 
** what else?
 
** what else?
 
* devs should of course be reasonably sure any commit does not introduce breakage elsewhere, core or otherwise
 
* 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
 
* what else?
 
* what else?
  

Revision as of 11:58, 14 July 2008

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.

Contents

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
  • 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?
Personal tools
Namespaces

Variants
Actions
Navigation
Categories
OE services
Toolbox