Backporting

[Derek Atkins]

John Ralls <jralls at ceridwen.us> writes:

>> We don't really have a good procedure in place.
>
> Well, let's work one out then.
>
> It's easier to write a procedure if one starts with goals for the
> procedure to accomplish, and the first goal is obvious: To get
> bugfixes into the next release. I think a more formal statement of
> your "baking" analogy is to get bugfixes tested before committing them
> into the stable branch. Any more?

* We want to make sure we don't forget changesets (which I suppose is a
  corellary of your first statement.
* We want to make sure we don't commit extra changesets (no desire to
  add additional cruft to the stable branch)
* We want to keep the stable branch, well, stable.  In a commercial
  environment I would say that perhaps we should require a "make check"
  test that shows the bug and then the patch that fixes it, so we don't
  have a future regression?
* It would be nice to actually have the code audited before committed,
  in addition to it just being tested.  (This is why 'BP' -> "AUDIT")

I'll try to think of more....

> Regards,
> John Ralls

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available