Hi,
recently there have been a bunch of commits directly on master. Is there a particular reason for that? I would really prefer it if we could stick to our development process where work gets committed to topic branches and the topic branches are then merged into master. (These merges can happen often. I wouldn't mind that)
cu
Gregor
We had agreed that script development would happen directly on master temporarily but I can definitely see that causing trouble. I think I agree and I'll move that development over to a branch.
The SSL fix was different. It was a very simple change and the absence of the fix was causing trouble for a few people.
.Seth
Still, isn't that kind of what fastpath is for?
Argh, good point.
.Seth
Gregor, what's the original problem you ran into?
Robin
I actually didn't run into a problem I just noticed the direct commits to master.
cu
Gregor
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 ... ?
Robin
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 master.
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
Thanks for the summary. That all makes sense, but also note that our
process always had the "maintainer exception" in there for direct
commits.
Talking with Seth, we said that at least until the beta gets out, he
will keep making direct commits to the scripts. He knows them best by
far, and at the moment I'd be merging them pretty much blindly anyway.
We'll keep doing the merges for the core, and we will switch back to
doing merges for the scripts as well once things have settled down.
The most important part is that master remains stable, so we all need
to be careful not to break things.
I also still haven't given up my hope to make use of the devel branch
eventually btw (don't laugh 
Robin
I wasn't going to mention the devel branch. 