"Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: > [Linda: sorry you got this twice, I accidentally sent it from my home > address] > > Howdy-- > > So conversations last week in MPK didn't yield anything new or > startling. They did, however, reveal that the ON users have > greater frustration and different prioritization than I realized. > > If anybody feels a keen desire to own any of this, even just in terms of > specifying it and/or estimating resources, that's great. Otherwise, > I'll give Linda my best estimates. > > Prioritization is NOT implied by ordering. > > Some things that we currently need: > > A. Updates to work with newer versions of Mercurial > 1. Rich did the work and sent me the patch a couple weeks back, I > need to finish reviewing it and coordinate with Danek and GK.
You need a newer copy of my patch. I can send it out for review (or at least you looking at it). > 2. In addition, Tadd Ottman sent me (unsolicited) a similar patch > this morning. I'll compare it to Rich's... I'd like to see a copy. > B. Equivalent of "resolve" script to drive Hg merge > 1. We never adopted or worked on David Powell's "hgr" script. Yes we did, and I pinged this list several times asking about what we could do to prevent commits when hgr still had work to do, I got little in the way of answer. > 2. Now Mercurial is actually providing similar support in an > upcoming release. (1.1? I'm not sure.) 1.1 allows you to resume a merge you did not complete. 'hg resolve' > C. Automated management of the split repositories > 1. In the spirit of hgext.forest, but need not be generalized. > 2. Major dissatisfier for internal developers, external folks > probably don't care much, but we might get bonus points if we figure out > how to sync open source to closed bins tarballs? Darren Moffat, Myself, and probably countless other people have private scripts to pull the 'correct' closed-bins for a given workspace. I'm not sure if any of them are suitable for integration. > D. Text-based merge support > 1. Related to the "resolve" script, but I don't know if Mercurial's > resolve will include this. It won't, but in the non-GUI case Hg seems happy popping up $EDITOR over a file marked up with >>>>====<<<< style conflicts, at least on a couple of my machines. > E. Documentation, documentation, documentation > 1. We need something linked from http://onnv.eng/, but it could > reasonably live outside > 2. Use faq-o-matic or wiki? > 3. Needs to be very basic series of "How do I do XXX?" Q-and-A > 4. Mike (and probably others) have made various updates that are > either stalled awaiting review, or not prioritized; we should finish > those, but the one-stop, living document will satisfy most of what I've > heard or observed as frustrations. > 5. I've been pointing folks to Tom Haynes's blog, because it's > excellent. But we really need to suck that information (how to setup > and run a project gate) into something that we maintain. How much does this differ from the docs you, jmcp, and I wrote prior to integration? > F. Outstanding tools bugs > 1. I need to integrate a wad that I've built/started to test. > 2. We need to sweep both bug databases. > 3. We need to capture our ongoing work in RFEs. (Bugzilla OK) While arguing with you about this is, in various respects, funny. I don't see how Bugzilla is in any respect "Ok" by the rules of its use I last understood (assuming you mean d.o.o). b.g.c just seems wrong in general at this point. -- Rich
