DragonFly BSD
DragonFly submit List (threaded) for 2003-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Diary cleaning


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 18 Dec 2003 20:25:23 -0800 (PST)

:Justin C. Sherrill wrote:
:
:>http://home.shiningsilence.com:81/Status/diary.cgi
:>
:>This is the diary with changes to day names so they are spelled right,
:>and the correct day is named. 
:>
:>Is this something minor enough to just commit, or should I always submit
:>for comment? 
:>
:I think all cleanups such as spelling, page aligments etc... are just fine
:to commit without submitting them first.
:
:-DR

    We should probably start formalizing the rules.  This is what I
    suggest we start out with:

    * The release process will use tags (or a branch tag AND tags), so
      we will not need a 'code freeze' per-say, so the only real
      rule during release engineering will be 'no large change sets'.
      Only the release engineer is allowed to create/slip tags.

      Note: the first release is slated for July.

    For people with commit access:

    * Trivial non-code things can just be committed without submitting
      them first, with the understanding that if an issue crops up
      there might be, after discussion, followup commits by other
      developers.

    * Trivial code changes can also be committed without submiting them
      first, but MUST be tested (even if its only syntax or a comment,
      or something utterly simple).

      If the system breaks we throw clue-bat points at the person 
      responsible (including myself since I don't follow my own advise
      sometimes).

    * For trivial code changes, posting to submit@ and waiting 24 hours
      before committing protects you from getting clue-bat points
      assigned to you if it later breaks (i.e. the rest of us should
      have caught the issue in review).

    * For non-trivial code changes that effect existing APIs you must
      test, post to submit@ first, wait 3 days, deal with any issues
      that crop up, then you are free to commit.  There is no 'timer'
      that restarts per-say, this is just so there are no surprises.

    * Non-trivial code changes that do NOT effect existing APIs,
      such as new system calls (typically previously discussed on the
      lists) require posting to submit@ first, waiting 24 hours,
      dealing with any issues that come up, then you are free to commit.

    That seems like a reasonable first pass for me.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]