Now that I've (hopefully) dug myself out of this onnv-gate Hg
regeneration hole, I'd like to start working on this SCM Migration thing.
I believe these are our current tasks:
1) Finalise a priority list of developer/GK tools to convert
(This discussion has already started it looks like)
2) Start an evaluation process for determing what Hg features or
extensions to use (i.e.: forest, mq, etc.)
3) Start a draft of a plan for overall/common tool design/architecture
so we don't have 15 engineers all running off every which way
and each reinventing the wheel
4) File bugs so we can start tracking developer/GK tool conversion
and getting REs assigned
5) Actual SCM migration conversion tools need to be developed
Some of the tools listed on the page[1] don't necessarily have to exist.
Yes, it's easy to port 'daily_update' - but we don't need it with
Mercurial. So we should keep this in mind.
I'd like to decide how we want to address SVN as well. Some of these
tools will be used by other consolidations/projects that will be using
SVN, so we should try to be mindful that we're not hacking in
Mercurialisms. (e.g.: webrev)
So here's what I see as immediate next steps:
1) Can we get some volunteers to evaluate Hg features/extensions and
decide whether or not they are appropriate for use?
2) Continue the priority list discussion
3) I'll start drafting a plan for tool design/architecture and circulate
4) I'll cleanup and get my Teamware->Hg/SVN bridge/conversion-scripts posted
5) Can the GKs (Danek? Dave?) post their tools? (A tarball is fine
initially, but I would like to see a repository later so that we can
have multiple people working and committing them to a repository with
proper revision control)
cheers,
steve
[1] http://opensolaris.org/os/project/scm-migration/
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
[email protected]
