Peter Memishian wrote:
> > For now, many people need to work on both the ON gate and the ON-STC{2}
> > gates, which are not yet converted to mercurial. I know preparations
> > are going on for opensourcing and conversion, but there has been no
> > announcement yet. The SUNWonbld tools are officially required for that
> > gate set for now. (Not to mention other gates that might be private and
> > not yet converted, as mentioned by Jim.)
>
> That seems like a poor design to me. The SUNWonbld tools are meant to
> build ON. I can understand the desire not to reinvent the wheel, but the
> fact is that there are a number of ON-specific things hardcoded into those
> tools (e.g., the "OK warning messages" lists in nightly.sh), that simply
> don't make sense in other environments (nevermind all the subtle and
> undocumented dependencies between the Makefiles and the tools). Moreover,
> it's untenable to require folks making changes to SUNWonbld tools to track
> down every consolidation that also might be making use of the tools and
> ensure that their changes are compatible.
>
I'm not asking people to do that. Other consolidations are
self-regulating. Poor design or not, this is not going to retroactively
change and shouldn't because the better use of time is to work on
getting code into a form for opensourcing and moving towards mercurial.
That's the correct change and I'm asking you to be patient while this
stuff gets worked out. Just because the development branch of ON is
ready does not mean everyone else is.
> I realize we're already in this mess. I'm just asking people to recognize
> that this *is* a mess, and that ideally we should separate SUNWonbld from
> a yet-nonexistent more generic SUNWbld package that would allow reuse.
>
Who's going to do that work right now? I'm trying to look at this from
the pragmatic position.
> But all of this is a separate conversation.
>
> On a related note: I highly doubt there's anyone in sustaining who really
> wants to make use of e.g. sccsrm given that it's been at least 5 years
> since we allowed folks to remove files by moving them to .del-<foo> names.
> Given that SCCS is dead in ON, it seems a good time to put the final nail
> in the coffin for sccsrm, regardless of how long it takes us to kill the
> rest of the old tools.
Let's turn this around. There is potential harm in getting overzealous.
What is the risk of leaving this here for now? I really don't see
any, at least in the context of this transition. Someone can't possibly
use sccsrm on a mercurial workspace, so it is 3K on disk.
If you want to nuke it because it irks you, please at least survey the
userbase. It's likely nobody is using sccsrm in particular, but I'd
stay on the side of caution and take this on an individual EOF basis,
much as you'd do with any other feature - give ample warning, then do it.
I don't mean for this to get into a protracted argument, so I'll shut up
now.
-Paul
