[Bro-Dev] Directly committing to master

Gregor Maier gregor at icir.org
Mon Aug 1 11:01:34 PDT 2011

>> I actually didn't run into a problem I just noticed the direct commits
>> to master.
> I'm trying to figure out what it is about the recent commits that you
> didn't like. Is it because it may break things more easily, or because
> it is harder to track what's going into master, or ... ?

A combination of all of these I guess (none of these has happened yet 
but I think we risk them by committing directly to master).

It may break things more easily and it lacks the 4-eyes approach. 
Ultimately, one might get a bit more "sloppy" when committing to master. (*)

It's harder to track what goes into master. If we do regular merges we 
can combine a bunch of commits and but in a nice quick summary in the 
CHANGES files describing the merge.

It may break things for people using master if the happen to get an 
in-between or checkpoint commit. Similar for developers branching off 

It might make it harder to pinpoint bugs in master reported by users. 
Maybe the bug was just an (unknown) side effect of a commit that has 
been fixed by a later one. For us that's going to be harder to track 
down without knowing exactly what revision the user was running.

We've spend a lot of time last year thinking about and working out a 
development process that "works best" for Bro with a lot of discussion. 
So we should stick to it unless we have good reasons to not do so.

(*) E.g., consider some of the older code that is/was in Bro that maybe 
shouldn't have been released because it was quite limited or buggy and 
has never been tested extensively or regularly (e.g., old NFS analyzer, 
SMB analyzer, ConnStats analyzer)

just my 2ct
Gregor Maier
<gregor at icir.org>  <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA

More information about the bro-dev mailing list