Richard Lowe wrote: >> What do you guys think? It's not the answer I was hoping for, since I >> was hoping SFW would provide some exposure/testing to the tools before >> they went into ON; but I can understand Mike's concern. Honestly I >> think if this *did* happen, it would just push back the migration of ON, >> since I don't know that we'll finish up all our work by September to >> integrate into ON anyway. > > I don't want migrating SFW to delay ON, however, several (varied) > people have mentioned to me that something smaller than ON moving > first would make them far less worried about this, SFW is the only > real target that qualifies (since it's the only smaller-than-ON > consolidation that's open, aiming for Hg, and ON-like).
Yeah, I've had similar conversations with people. SFW would provide a good test; unless Install magically becomes open sourced overnight. >> On the plus side it does make sure that our tools are backwards >> compatible (not that I think that's really an issue), and it will get us >> additional tools testing as people will really start using the tools on >> mercurial workspaces (since not everybody knows how to find our onnv-scm >> SUNWonbld) >> > > The obvious down side is that it presents a chicken and egg problem. > > It seems that beyond a handful of people, nobody is willing to try > this stuff out until it integrates into ON, and we don't want to > integrate into ON without a fair number of people having tried it out > and seemed happy. If we can be reasonably assured that at least the Teamware compatibility of our tools works well, then I'm less opposed to integrating into ON with less Mercurial coverage if it means we pick up SFW as a test case for our tools. I'm not keen on filing numerous bugster bugs to then track Mercurial issues once they're in ON - but so be it... I think it's a small and reasonable price to pay. Mike Kupfer wrote: > I think the plan of integrating our tools, migrating SFW, then migrating > ON sounds fine. I suppose it could delay the ON move, but at this point > I think the critical path for the ON move lies elsewhere (e.g., code > changes). Agreed - I still think a critical path is training/documentation which we are still desperately short of. So if we're in consensus about this, we should probably talk to the C-team (or at least Mark & Dave) about this plan of action and see what they think. cheers, steve -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development
