* Stephen Lau <[EMAIL PROTECTED]> [2006-11-29 16:39]: > Okay, so we have the list of tools we need to port at: > http://opensolaris.org/sc/src/scm-migration/docs/devtools.html > (it's updated from the SCM repository)
There are a few more issues to discuss (from the design document): use of forest and use of mq. wx-equivalent operations for a developer are pretty dependent on the latter; handling of bringover-equivalent operations in nightly depend on the former (for contributors with access to usr/closed and other potentially separated subtrees). > So now comes the fun part, who wants to work on what? > IIRC, Darren Moffat volunteered to do webrev. I know Rich Lowe has done > *some* work on wx, whether that translates into him volunteering for > it... well, we'll see. I'll just publicly call him out here and see > what his response is ;-) It's a bit more complicated than that, of course. (But nothing Rich couldn't handle. :) ) There is functionality in wx that we would like to make accessible from the hooks, as well as available to the developer. (In fact, one idea--Danek's, but I think it's very appealing--is to have the commit hook on the developer side and one or more of the accept hooks on the server side run the same checks, or at least share a common subset.) This would necessitate some reimplementation in Python, I expect. > Anyone else? Mike K's busy right now, but he might be a good fit for figuring out use of forest for a split tree... since he's familiar with axework of that kind. I'll go pick something(s) from the list as well. > We've got the scm-migration/ongk repository which currently houses the > gatekeeper tools. The developer tools (with the exception of > zbringover, which I don't think should be priority 1) are within ON > under usr/src/tools/scripts. How do people want to do this? Should I > just create a clone of onnv-gate into a Mercurial repository > (scm-migration/devtools), and we can work within that? It seems a > little overkill to import all of ON for that... and given that we're > whacking in entirely new support, I don't know how useful it will be for > us to need to have the history around. I'm fine creating a new repo and > dumping in fresh copies of just the tools we need, in the interest of > bandwidth and space. Let me know what you guys think. No opinion, excepting that the hooks (which will be different for each of a developer repo, a privately-hosted project gate, and an opensolaris.org-hosted gate) are not in ON, but are of interest here. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
