> > 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.
As I said above, I'm not asking for work to be done. I'm asking for people to recognize that we're here because of shoddy engineering choices -- it may be expedient to borrow another consolidation's tools, but it's untenable in the long run unless the generic stuff is properly factored out. Obviously, no one is going to fix this overnight -- but it does need to be fixed. > 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. What's the harm in leaving anything unused lying around? Thankfully we've managed to convince people that using ON to squirrel away unused source is a bad thing, but apparently it's harder to convince people that having it be a museum of previously-useful tools (sccsrm hasn't been part of our development process for many years) is bad thing. > 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. All features are not equal. The engineer signing up for the work will need to do the risk analysis and apply their best judgment. Anyway, I think we both have better things to spend our time on. -- meem
