--On Friday, December 19, 2003 12:11 PM -0600 kfogel@collab.net wrote:
> Now I'm asking you to at least try it out. I personally have not
> found it that inconvenient yet, though that could just be me.
Using a web-based tool doesn't work well for me. I'm a slave to email.
But, let me summarize my concerns that are implicit in that statement:
I don't believe every committer follows issues@, so there could be a vote that
'misses' developers. So, if changes in votes are sent to our commit list,
then all developers can easily know when votes are casted. We could just
mandate that all committers must follow issues@ to know when votes are being
casted, but I'm not a fan of asking that.
The format of the issue tracker isn't particularly conducive to recording the
votes. Let me explain here: the way I'd see the typical life cycle go is:
1) Issue opened by user
2) Discussion occurs about what the bug is and the 'right' fix
3) Issue fixed by developer in trunk
4) Developer 'resolves' bug in tracker
5) Developer proposes issue should be merged to 1.0 by adding a vote
6) Other developers start casting votes
7) Enough developers cast +1s and no -1s casted
8) Issue merged to 1.0 by someone
9) Issue 'closed'
My concern is that 5 & 6 done in IZ aren't going to send an email to
committers when that happens - except to issues@. But, even if we all follow
issues@, it's not enough - we have to search through all commits to see when a
vote has been opened. Another way to resolve this would be to setup a
'special' IZ instance/CC list just for merging. But, that could be a bit
unwieldy.
It's hard to do bulk updates or off-line updates with the web-based tool. I,
for one, would be likely to review changes en masse while I'm traveling. With
a STATUS file, I'll have the rev number to merge listed in the STATUS file,
and I'd also have the commit emails for that rev number. So, I can do all of
my analysis (and see any commentary relevant to only the votes) just by
looking at my latest WC and mail archives. I can test it and then cast the +1
or -1 such as it'll be.
I can then record my vote in STATUS (and comments I have on the issue), then
perform a commit when I get back on the network. If there's a conflict (i.e.
someone else voted), I'll see that and take any additional input into
consideration before committing back to the trunk.
The potential drawback of having the STATUS file is that we're increasing the
barrier to entry here and we could be creating disjoint commentary (initially
on IZ, then in STATUS). Yet, I think that's acceptable because one of the
reasons that we want votes is that we want to ensure that the committers
themselves are 'happy' with a change and are willing to back it. There might
also be commentary in an issue that'd be relevant, but you don't have handy.
So, for that, it might be useful to have an issues@ archive that you can
browse off-line. (Since you know the IZ number, you can just look at that
issue in your mailbox. So, the information overload isn't as great. You know
how to find the needle in the haystack!)
> I must have missed that. So, if we don't use a STATUS file, you're
> just not going to participate in the process? And this is unconnected
I'm more unlikely to use the web tracker for the reasons described above. A
pull-based tool isn't right for us. We want push-based tools. ;-)
Hope this better explains my rationale. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 20:44:14 2003