James Carlson <james.d.carlson at Sun.COM> writes:
> Mike Kupfer writes:
>> >From a technical point of view, I think your proposal for a dual-scm
>> gate could work. On the other hand, given our chronic lack of staffing,
>> I have to wonder if it's a good use of our time.
>
> It's a good question, and one for which I don't have a good answer.
>
> (Btw ... I seem to be unsubscribed to this list, and unable to
> subscribe. The system won't respond to my requests, but allows me to
> post. I'm not even sure where to turn for help with oddities like
> this. :-<)
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).
I'm not sure what to do either, other than ask website-discuss.
>> We'll get some testing when SFW moves, though with fewer people and
>> reduced likelihood of their having to do merges in Mercurial. So
>> perhaps having some subset of ON developers doing putbacks through
>> Mercurial would be a benefit. And having more people with Mercurial
>> experience in the organization would definitely be a win.
>
> That last part is something I think is extremely important.
Certainly.
>> But as Rich mentioned in his response, the existing gate is complicated
>> and somewhat fragile. Adding a bidirectional component seems certain to
>> make that worse. And it's something we're going to throw away after
>> (hopefully) no more than a few week's use. So it's not clear to me that
>> the payback is worth the investment.
>
> Yes, I agree that the benefits are only temporary and that it exposes
> new risks -- particularly if we were to open it to "everybody" right
> away rather than adding committers one at a time.
>
> The risk that I see on the other side of this is that if we "go live"
> with an hg gate without having provided some reasonable way for
> project teams to try their hands at real hg-based integrations first,
> we'll be faced with two problems:
>
> - We'll have nearly zero experience in the organization in dealing
> with the procedure. People seem to have a difficult time today
> with teamware putback (often doing it from the wrong machine), and
> adding a whole new tool change is likely to result in having our
> group answering a lot of questions rather suddenly.
>
> - We'll be providing existing project teams -- even those that start
> on day T-1 -- with no reason to bother with Mercurial, because
> (from their perspective) there's no guarantee they'd ever be able
> to integrate from an hg-based workspace.
>
> 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. 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.
> 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.
>> >>>>> "Jim" == James Carlson <james.d.carlson at sun.com> writes:
>>
>> Jim> I think we'll do better if we offer a means for at least a few
>> Jim> willing folks to convert early, and better still if we can offer an
>> Jim> incentive (in the form of lower risk and maybe public kudos) for
>> Jim> projects to do so.
>>
>> I don't know that we can offer much in the way of lower risk. Projects
>> already can use Teamware until the last minute and then convert to
>> Mercurial with wx2hg. That seems pretty low-risk to me.
>
> 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.
>> What I think we can offer are
>>
>> - public kudos
>> - promises of increased level of support (compared to moving with the
>> masses)
>> - benefits inherent to using Mercurial (e.g., faster bringovers)
>
> ... 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.
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.
> 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.
[snip]
>> Jim> [1] I suggest April 1st, with not much basis other than that it's
>> Jim> still in the future, it's aligned with Sun's fiscal calendar,
>> Jim> and it seems like an appropriate day to switch gates.
>>
>> I'm not talking dates until we've finished the scheduling review. We've
>> already had multiple iterations of picking a random date and not making
>> it.
>
> Understood. We still need to advertise a date well enough in the
> future so that project teams can _plan_ around it. Announcing that
> we're going to do the conversion in (say) one month wouldn't be nearly
> as good as giving a date that's a couple of months out.
>
> 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
> far, it seems that we're shooting for having zero regressions on day
> one. That's admirable, but it's also true that we lived for many
> years without fancy tools such as 'wx', and if we had to limp along
> for a month or two with manual work-arounds for doing things like
> collapsing deltas^Wchangesets because the extensions aren't fully
> tested, I'd prefer that to slipping the date further and further out.
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.
> 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. :)
-- Rich
