[Bro-Dev] Directly committing to master
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 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