Sigh. If Danek only weren't the GK, it'd be easy to ignore his
arguments. ;-)
I definitely think they should be under SCM control, and I'd like them
to be available for other projects to reuse on their own project gates
if need be - so how about a separate repository that has a dependency on
onnv-gate?
onnv-gate: ongk:
usr/src/tools |-- gate/
|-- scripts/ |-- gk/
|-- common/ |-- etc/
|-- scm/ |-- scm/
|-- tw/ |-- tw/
|-- hg/ |-- hg/
|-- svn/
I'm renaming 'repohooks' from my original proposal to be 'scm' since
this may contain more than just hooks (ex: Hg extensions). I'd like for
common functionality that is SCM-agnostic to go into common/, and SCM
specific functionality to go into scm/{tw,hg,svn}
The developer tools in usr/src/tools and usr/src/tools/scripts can call
through to functionality in common/ and/or scm/{tw,hg,svn}. E.g.: I'd
like a common set of cstyle, jstyle, hdrchk, cddlchk, rtichk, etc. to
live in common, with calling-scripts in tools/scripts/.
Example:
Common cstyle code lives in usr/src/tools/common
We have a cstyle calling script that calls it from u/s/t/scripts
We have a Hg hook in u/s/t/scm/hg for putback-checks that calls
it
The 'ongk' repository contains gatekeeper scripts, tools, and has a
dependency on onnv-gate in that it will reuse functionality in
usr/src/tools/common and possibly usr/src/tools/scm/{tw,hg,svn}
We can build a SUNWongk package of the ongk repository so that project
gatekeepers can use and deploy it themselves if so desired.
SUNWonbld will continue to build and deliver the existing developer
tools. For now, let's say it will also deliver SCM-specific hooks,
though we may want to break that out into a separate package if need be.
Does this seem reasonable? I believe it satisfies my desire to have the
ongk scripts under SCM control and reusable by others. It also
satisfies Danek's desire to not have the ongk tools be so tightly
coupled to ON's putback/rti policy.
I'm not super-keen on the dependency of ongk on onnv-gate, but I don't
see a way around that if we want to break it up into two repositories.
cheers,
steve
Stephen Lau wrote:
Here is my proposal for the source tree layout. Basically we have a few
classes of tools:
1) Developer tools (the stuff in usr/src/tools/scripts)
2) Client-side/developer hooks
3) Repository-side/gate hooks
4) Gatekeeper tools
I'd like to integrate the GK tools into ON, so that we can all share a
common set of routines for things like pbchk, etc. I really want to
discourage people from re-inventing the wheel (sic: pbchk).
usr/src/tools
|-- scripts/ (developer tools continue to live here)
|-- repohooks/ (client-side SCM hooks)
|-- gate/
|-- scripts/ (ongk/gate tools)
|-- gk/ (ongk/gk tools)
|-- etc/ (ongk/etc configuration files)
|-- repohooks/ (repository/gate-side SCM hooks)
as note:
usr/src/tools/gate/scripts will be what is currently in the ongk/gate
repository. and usr/src/tools/gate/gk will be what is currently in the
ongk/gk repository.
Thoughts?
cheers,
steve
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
