Hi all,
I agree that the CVS code should remain usable, but (not blaming anyone!) I don't think it is a productive way to then put everybody under pressure to fix every crash by yesterday.
I just want to remind you (as an outsider and non-developer; I actually don't have any say here) that this project came into existence to grant more freedom to its developers. If you expect to have every bug fixed ASAP in (by nature) shaky code, you will start to drive people away again if you get used to this behavior.
Just want to remind you *before* it becomes a serious problem.
Greetings and happy hacking, - Felix
I really don't mind if the build is broken occasionally. We know that we will have major changes to the tree in the next few weeks, and it will be impossible to avoid regressions in the code or in the build.
However, a couple of things will help:
1) Before someone knowingly breaks the tree, they should warn everyone to stop updating their cvs copies until it is fixed again. That way they can continue to work on their features/bugs.
2) Try to limit the scope of the breakage. If it can be limited to a directory or two, please do so. Break it, fix it, then break it again later.
Too bad we are not using Subversion. It would be so handy to be able to tell everyone which revision number is the current working version.
Bob
Felix Rabe wrote:
Hi all,
I agree that the CVS code should remain usable, but (not blaming anyone!) I don't think it is a productive way to then put everybody under pressure to fix every crash by yesterday.
I just want to remind you (as an outsider and non-developer; I actually don't have any say here) that this project came into existence to grant more freedom to its developers. If you expect to have every bug fixed ASAP in (by nature) shaky code, you will start to drive people away again if you get used to this behavior.
Just want to remind you *before* it becomes a serious problem.
Greetings and happy hacking,
- Felix
Quoting Bob Jamison <rjamison@...357...>:
However, a couple of things will help:
- Before someone knowingly breaks the tree, they should
warn everyone to stop updating their cvs copies until it is fixed again. That way they can continue to work on their features/bugs.
In this case, I _had_ warned the list since I felt the commit was slightly risky. I wouldn't have comitted if I'd known for sure there would be breakage (I did do some perfunctory testing).
Note that we're early in a heavy development cycle, not leading into a freeze. IMO, a risky checkin here shouldn't be as much an issue here as it ought to be when e.g. leading into a freeze, so I weighted my risk/reward evaluation a bit differently than I would have otherwise.
- Try to limit the scope of the breakage. If it can be limited
to a directory or two, please do so. Break it, fix it, then break it again later.
?
If you're referring to compile breakage, that's never acceptable to do knowingly.
Otherwise, functional breakage really isn't related to the filesystem like that. Either the breakage is related to a specific feature, or it's part of core code that is unavoidably going to have widespread repercussions. It's still best not to do knowingly.
(FWIW, checking in a new feature that doesn't work yet does relatively little harm, I'm just talking about regressions in existing code, or build failures)
In short:
1. Don't deliberately break something in HEAD that used to work.
2. Early in a development cycle, breakage is still going to be more frequent and everyone should plan for this (e.g. as a matter of course I save "known good" builds to use for production work)
3. Keep existing unit tests up-to-date (test breakage is breakage too). I have been entertaining a proposal that we adopt Tinderbox and include "make check" in the build actions...
4. If you don't feel like an important bug is getting addressed quickly enough, and there's no bug filed, file a bug with an appropriate severity, dammit.
-mental
participants (3)
-
unknown＠example.com -
Bob Jamison -
Felix Rabe