Committing Rules and Responsibilities

I hereby declare version 1 of “Committing Rules and Responsibilities“, a document which attempts to draw together in one place all the rules which are common to the core product trees. If you check in to one or more of those trees, please make sure you are familiar with it – and let me know if you think it’s wrong or incomplete.

Now it’s done, we will try and use it and other reorganizations to simplify the top of the tinderboxes.

4 thoughts on “Committing Rules and Responsibilities

  1. Great article Gervase, very informative.

    The only suggestion I have is to hyperlink the last words “should be backed out” to a document or further writing, that details backing out a patch.

  2. a document which attempts to draw together in one place all the rules which are common to the core product trees

    I already went through this exercise a few months ago, resulting in mozilla-central tree rules and Tree Status being the only two places you have to look. (This information used to be scattered around the Tinderbox page and several wiki pages.)

    It’s not clear why you feel this needs to be done again, and why you decided on some rules that are different from what #developers and I decided on (e.g. use of stars and expectations around Talos).

    simplify the top of the tinderboxes

    Again, I did most of this work a few months ago, and have been fighting a constant battle to keep outdated warnings out of the Tinderbox header. There’s not much left to remove. Maybe a few bullets can move to “care and feeding”, and maybe the sheriff schedule doesn’t need to be there, but it’s really not bad compared to the rest of the page.

    Also, Tinderbox is going to go away entirely fairly soon. Most developers are already using TinderboxPushlog exclusively. Squeezing a little more simplicity out of a part of the old Tinderbox page seems pretty pointless; the real question is what information should be where as Tinderbox goes away.

  3. The organisation of :
    – “Committing Rules and Responsibilities” : Global generic rules
    – “Tree Status” : Specific rules for how each branch is managed
    (*MUST* be updated after release/a new release branch is created)
    – “Tinderbox” : Day to day, minute to minute change
    (for exemple at the moment has the message “The tree is CLOSED while we confirm that the mozilla-1.9.3 branch went well.”)

    seems to me quite good.

    But if tinderbox is used less and less, the frequent change info needs to move indeed.
    Can’t it go to the top of TinderboxPushlog ?
    Or show it there in a pop-up when the user hovers over a check-in rules element ? Maybe have a “Tree is OPEN/RESTRITED/CLOSED” element, and more details when you hover ?

    The “Tree Status” page might be the most problematic; it tends to fails to be updated when needed. For example when I started to write this message, it wasn’t updated for the 1.9.2 branching/switch tip to 1.9.3. Now, Beltzner has done it. In mid-july, when I pushed bz into doing something about it, it had reached the point of being really confusing after not being updated for the 3.5 release.

    But things have already significantly improved since, without external pressure, it’s now updated only one day after branching.

  4. hi…today i read about Hacking in newspaper and from that i m very much interested in studing or doing hacking.can u please help me to study the basic rules of hacking..i m not rich to join any classes..please help me..i m giving you my please reply on it..

Leave a Reply

Your email address will not be published. Required fields are marked *