I just finished going over the lists in Bugzilla (bugs.grommit.com) and
Bugster. Stephen and a couple other senior engineers are particularly
interested in what needs to be fixed before we can think about moving
SFW, so my comments are biased in that direction. There appear to be
several clumps of bugs:
- Mercurial Issues
- gpyfm
- Recommit
- Checks and Gate Hooks
- Incremental Merge
- Webrev
- SCCS Keywords
- Old Style, Copyright, etc Issues
- Miscellaneous
so I've organized my comments along those lines.
Bugs tagged with "#" do not have an owner.
The bugs in Bugster are all marked with the "hg_trans" keyword.
* Mercurial Issues
There are several bugs fixed in 0.9.5, plus there are other issues
that are stalled waiting for 0.9.5. Rich and Danek hooked up over IRC
on Friday, and it looked like they will be moving forward on getting
0.9.5 into SFW, after Danek finishes up with p7zip.
Rich mentioned that changing to 0.9.5 may cause some problems for the
Xen folks, but I'm still a little unclear on the details. I'm hoping
it just means they need to use matching versions of Cadmium and
Mercurial. Cadmium will issue a warning if detects a version of
Mercurial that it's not sure about. The bug for the Cadmium changes
is
281 P3 cdm needs to be updated to work under Mercurial 0.9.5
We'll be able to mark these issues as resolved once 0.9.5 is in place:
283# P1 Mercurial issue 612: "rename of a directory with built ob...
354# P1 mercurial issue762: git format diffs are confused by sour...
246# P2 Mercurial issue 222: [extensions] in a repo's .hg/hgrc fi...
301# P2 Mercurial issue 636: merge may use the wrong file content...
272# P3 Mercurial Issue 589: "undelete" sequence leads to crash
242# P3 Mercurial issue 455: Mismerge involving two concurrently ...
243# P3 Mercurial issue 498: unreliable tag computation when tags...
325# P3 Mercurial issue 672: hg merge doesn't find renames after ...
252# P3 Mercurial issue 522: hg st of a merge changeset shows pha...
323# P3 Mercurial issue 650: Unmodified file considered modified
249# P3 Mercurial issue 269: hg mv should handle newly added files
Until then, you can filter them out of the bug list by telling
Bugzilla to ignore bugs with the "fixesupstream" keyword.
This leaves 6 unresolved Mercurial issues. The first 3 involve
the possibility of repo corruption:
241# P3 Mercurial issue132: hg should revalidate its data after l...
244# P3 Mercurial issue199: detect corrupted dirstate
251# P3 Mercurial issue 413: hg add mishandles subprojects
241 is marked as "in-progress", the other 2 are still being discussed
(status "chatting"). 251 is not relevant to SFW. 241 and 244 are
relevant but relatively unlikely to be triggered.
The next 2 are both marked "chatting".
248# P3 Mercurial issue 122: commit succeeds if merge fails
324# P3 Mercurial issue 664: hg process may exit with an apparent...
Bug 248 is P3 because it makes mismerges easier. See "Incremental
Merge" below.
Bug 324 is P3 because of the risk that our tools will misbehave,
particularly on large putbacks.
If we want these 5 issues fixed any time soon, we will probably need
to work on them, particularly the ones that are marked "chatting".
The last Mercurial bug is
347 P1 recommit can strip local changes in such a way as to corr...
which is Mercurial issue 764, which has status "chatting". I'm not
sure we need to spend time on this--it may go away when we switch to
Rich's new recommit code (see "Recommit" below).
* gpyfm
There is at least one serious gpyfm bug that we need to fix, unless we
expect people to use filemerge for graphical merges:
271 P1 gpyfm gets seriously confused by merges of near identical...
There are a couple issues with gpyfm's user interface:
203 P3 gpyfm should ignore identical changes in parent and child
346# P3 multiple Accept&Next clicks don't work
I'm not sure 203 needs to be P3. I think gpyfm handles identical
changes correctly if you click on the merge button. But it does make
it more tedious if you walk through the conflicts one at a time.
There's also a gpyfm performance issue:
238 P2 gpyfm's responsiveness decreases as file size increases
This bug appears to be mostly a user feedback issue--there's no
indication (e.g., hourglass cursor) that the tools is busy. I
question why it's a P2: the bug indicates a 1-2 second delay for a
28K-line file. I don't think 1-2 seconds is unmanageable, and I've
found few files in ON that are larger (counting number of lines). P4
may be more appropriate. OTOH, this could also be the root cause of
346 (above), which has delays significantly longer than 1-2 seconds.
* Recommit
The current recommit code has some bugs, and my understanding is that
it's a big complicated and hard to get right. It also tickles a bug
in Mercurial (see bug #347 above). Rich has a simpler
reimplementation in mind that should be more reliable.
333 P1 cdm managed to turn a rename into a copy
356 P3 cdm recommit needs to cope with the tags it may be trashing
368 P3 hg recommit with no actual changes confuses the mortals
377 P3 cdm should not allow you to putback a null changeset.
The fix for 333 is the reimplementation.
356 will still need to be addressed, even under the new
implementation. I think 368 and 377 will still be needed, too. Rich
has fixes for 368 and 377 in code revew.
There's one more bug that is related to recommit:
259 P3 cdm needs a 'wx reset' equivalent.
I think all of these bugs (356, 368, 377, and 259) are high P3s. That
is, if we don't fix them for SFW, we'll definitely want to document
them.
* Checks and Gate Hooks
These two do not appear to be interesting for SFW:
303 P3 cdm needs .NOT file equivalents
373 P3 308 didn't do enough for pbchk and nits
I'm expecting that SFW may want RTI enforcement as well as
sanity-checking the permissions on a file. So these bugs are all
relevant to SFW:
352# P2 Need gate-side hooks to replace the gate pbcheck.
261 P2 Need a permchk (Permissions Check) check module
306 P3 cdm should whine at people about checks as early as is se...
369# P3 cadmium check output is garbled with -q
370# P3 RTI checks should tell me I can't connect, or otherwise f...
If we don't fix 370 for SFW, we'll want to document it.
And there are a couple checks I expect every gate will want:
355# P3 scm hooks should prevent the creation of new tags or bran...
351# P2 gate automation/gk tools need to understand mercurial.
355 probably ought to be P2.
I couldn't find a bugzilla login for Ken, so 351 and 352 are currently
marked unowned. But I believe they're both his.
There's also a bug in the existing gate checks that is relevant to SFW:
6598784# P3 pushing to locked repositories should result in sane error[...]
If we don't fix it for SFW, we'll want to document it.
* Incremental Merge
The primary Mercurial merge model is that you merge all conflicts in
one session. This will be a problem for large merges, particularly
ones where it's not feasible for a project gatekeeper to do all the
merges.
269# P2 support for interrupting a merge session
We haven't decided how to handle this issue. There's an extension
called IMerge that was created when we pointed out this problem on the
Mercurial project list. It seems to be usable, though not ideal. (Of
course, we can always work with IMerge's author to get it more to our
liking.) Another option would be to rely on hgr.
309 P3 integrate dep's hgr (text mode 'resolve'-like merge tool)
One concern that we have about both approaches is how to make
accidental mismerges hard.
I think we need some sort of incremental merge capability for SFW.
I don't think protection against accidental mismerges is a stopper for
SFW.
* Webrev
These do not appear to be stoppers for SFW:
374 P3 setting CODEMGR_WS confuses webrev
372 P3 webrev does not display executable bit change
326 P3 webrev could shake off its wx heritage
There's also a bug in Bugster:
6446689 P3 webrev(1) needs Mercurial support
I don't know whether it's redundant. I'll ping the RE (Darren Moffat)
about it.
This one is fixed in our current workspace:
6524249 P5 webrev doesn't appropriately quote arguments to print(1)
* SCCS Keywords
There is an item in the task list (which is reachable via the project
web page) for this. That item should go away, as we are tracking the
keywords issues with bugs. Most of the bugs are in Bugster.
Issues that may be relevant to SFW are
350# P3 usr/src/tools contains user-visible SCCS keywords.
264 P3 revisit nightly -O and friends for Mercurial
268# P2 class action scripts that rely on #ident may do evil things
Nobody has done the evaluation of 350. I'm guessing most of the
issues are related to displaying version information. But we probably
want to at least evaluate the bug for SFW.
264 addresses multiple issues, but the only one that is relevant to
SFW is the version string for nightly itself that gets put into the
mail message.
We did some analysis for 268 for ON. If SFW doesn't have any class
action scripts, this would obviously not be a stopper for them.
None of the remaining bugs is relevant to SFW. However, we have not
done any analysis on what the impact would be if ON moves and the bug
is not yet fixed.
6560813 P3 USB drivers should not use SCCS keywords in user-visible[...]
6560843 P3 asm sources should not rely on .file "%M%" for naming STT[...]
6560847 P3 rcm_daemon should not use SCCS keywords in rcm_mod_info strings
6576310 P3 postprint uses SCCS keywords for creation and version headers
6560794# P3 inet modules should not use SCCS keywords in user-visible[...]
6560807# P3 common drivers should not use SCCS keywords in user-visibl[...]
6560816# P3 x86 drivers should not use SCCS keywords in user-visible [...]
6560842# P3 sparc drivers should not use SCCS keywords in user-visible[...]
6560957# P3 sendmail should not use SCCS keywords in version info[...]
6560958# P3 Solaris:: perl modules should not use SCCS keywords in ver[...]
6576312# P3 OBP bootblocks use SCCS keywords in user-visible ways
6576316# P3 xntpd uses SCCS keywords to form its version strings.
4758439# P4 some files use "current date" sccs keywords
* Old Style, Copyright, etc Issues
There are several bugs that were opened in the past against wx or the
various checking programs. These will be fixed as part of the SCM
Migration work, so they're marked with hg_trans, P4. They are not
needed by SFW.
4633617 P4 wx copyright is even slower
4678979 P4 wx nits doesn't check copyrights in the forthdebug files
4739416 P4 copyright checking needs work
6252813 P4 wx copyright matching: quoting is hard
6313877 P4 wx should check for mixed copyrights
6465682 P4 wx should check that PSARC case number matches description
* Miscellaneous
This one is not needed by SFW:
4865419 P2 bfu on i386 needs /ws/on10-gate/public mounted
Strictly speaking, it's not required for ON, either. But we had
several putbacks in S10 that assumed that BFU users could run scripts
in /ws/onv10-gate. So far we've avoided that in Nevada, but I
attribute that mostly to luck.
This one is definitely needed by SFW:
6597716# P3 sfwnv should not change tool file permissions in the gate.
Without this fixed, doing a build renders the output from "hg stat
-mard" pretty much useless.
Comments, anyone?
mike
