Richard Lowe writes: > Odd, it should work the other way way. (if you're not subscribed, > your posts shouldn't be getting through, but you should be able to > subscribe).
Indeed. It's very strange. And the web site's "send me my password" button claims to do something ... but I get nothing. :-/ > I'm not sure what to do either, other than ask website-discuss. Will do. > > I'm expecting a really tough sales job here in getting people to > > migrate over, and if we fail at that, the consequences will be pretty > > grim. > > I'm not actually sure that's our concern, necessarily. Perhaps not yours, but certainly mine. It's a huge group of people, and if we have transition trouble, there'll be very strong (perhaps irresistible) pressure to revert the change ... and possibly even sabotage the conversion process itself. > I certainly > think that failure in the case of a bi-directionally bridged > arrangement will generate far more ill-will than practically anything > else, as it would take both gates down for what maybe an extended > period while things are put back together again. I think you're assuming something much more widespread than I am. I'm suggesting a temporary bridge that we use with a limited set of people -- a limited set of opt-in users that we're in touch with directly. It would most likely be people fixing small bugs and RFEs first, not big projects. If something goes awry, we shut the bridge down right away, and the traditional teamware path is still there. I'd even be happy with a "gatekeeper locks the gate after and checks sanity after a bridged putback" policy for the first one or two that goes through. > > It's a big change, and we're going to make mistakes, project teams are > > going to make them, and the gatekeepers probably will as well. That > > all argues (at least to me) in favor of finding incremental steps > > where we can. > > I'm not sure we should look quite *that* hard for them. OK. > > I guess I'm expecting more ETOOHARD than you are. :-> > > I, at least, don't particularly care whether people wish to migrate or > not. It's actually harder for them not to, once the gate moves, but > if they nevertheless wish not to, that's their own business. > > If the gate doesn't move, and while it still has no concrete plans to, > there's no specific reason to care for that reason. That's a key reason why I want us to publicize a conversion date, and do it early. Even if the tools aren't perfect by that date. > > ... but as a downside risk, those projects choosing to convert over > > (the "early adopters") are now dependent on us meeting out schedule > > for a full conversion of the gate. If we miss, then they're blocked > > out of the gate for as long as we miss. > > Not necessarily, manual conversion in the other direction is not > necessarily that hard, and could perhaps be automated. You mean a hg2tw script? Yes, that sounds like an alternative insurance policy to me. > For what it's worth, I'm arguing against the two live r/w gates and > automated bridging between them, I think the ability to bridge the > other way would be a worthwhile safety precaution. > > It's also worth noting that we will have to integrate mercurial -> > TeamWare, so should end up with a pretty good idea of how annoying it > is to do by hand. Probably so. > > If I were a project team lead trying to hit something in the April to > > (say) December 2008 time frame, I don't think I'd even consider that > > option. As an arbitrary OpenSolaris project team lead, I have no > > visibility into or responsibility for any problems the SCM team might > > have. > > And I, for one, wouldn't really care what you chose to do. The best > we can do, I think, is advise people who ask. I would advise you to > stick with TeamWare. Doesn't that -- ruling out on-going projects -- make the transition more difficult and less certain? > > As for not making it, I think I'd rather see us be a little more > > flexible about what gets delivered and when. Looking at the plans so [...] > I still disagree with that. > > 1. > We're already, in theory, making people do something the vast > majority, I believe, don't wish to do. Making them do more work in > the process will just make that worse. > 2. > Integrating something you *know* has problems is just plain wrong. I do agree with that. The only counter-argument I have is that we can't actually predict the future, and yet if we expect people to plan around this, we *do* need to give some stake-in-the-ground dates fairly far out. Plus, other than the few of us playing with this gate, who is going to beta test the updated tools in a scenario that's similar to real life? > > Point taken, though, about the risk involved in an backwards bridge. > > I'll talk with the gatekeepers again once we have a schedule review. > > That sentence needs more precision. I think a backward bridge is not > a bad idea, I think running both bridges at the same time, while both > gates are writable is a bad idea. The difference is important. :) Good point ... that's a different kind of flexibility than I'd originally considered. Doing that would allow people to keep private project gates on Teamware after the switch-over date and then convert prior to (or as a part of) putback. I still would like to attract people earlier ... but if the consensus is not to do it at all, I can live with that. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
