Gordon Ross writes:
> I don't care much about this version number issue, but
> I do think respecting some notion of "ownership" is an
> important thing.  Given that the i-team in Beijing has
> requested this and they "own" this driver, I'd suggest
> we let them keep it (and "hold our noses":)
> 
> Are you guys OK with letting the i-team have their way?
> We can always take out that version string later...

I think it'd be a darned shame for locally-maintained version numbers
on a subset of system components to become common enough that it ends
up forcing others to do likewise.

We discussed the version numbering issue for individual objects (ad
nauseum) on the SCM migration list, as Mercurial doesn't have the same
source-changing features as other systems, and the rough consensus was
that the numbers should be removed, and that numbering is really a
release process issue -- "mcs -a" or part of packaging or both -- and
not a source issue.

What I don't want to see are 'bugs' filed in the future saying that
since bge has its own idiosyncratic source-based numbering scheme,
some other driver that doesn't have this is 'flawed.'  Moreover, I
don't want to see RTI advocates burdened with having to search for
obscure local 'rules' about source changes for projects that
incidentally modify files in one of these special drivers.

That's exactly where this road leads.

I agree that the project team should own their code, and should do
what they think is right, but like it or not, we're actually building
both a source code base and a system as a whole, and we all have
responsibility for the whole thing.  The way in which one project team
chooses to do things _will_ have an effect on others.

So, yes, they "can" do this.  I think they just shouldn't.

-- 
James Carlson, Solaris Networking              <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to