Hi Jim,

I got perception of the version number issue. Surely it would be a
problem for now and in the future that should be worked out.

>From our side, we just want a mechanism to identify what revision level
of driver the system has loaded. Is there any solution for that other
than the version number? We're willing to replace it with another
mechanism.

Regards,
Crisson
On Mon, 2008-11-24 at 09:20 -0500, James Carlson wrote:
> 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.
> 
-- 
*************************************
* Guang-Hao, Crisson Hu             *
* China ERI, Sun Microsystems, Inc. *
* Tel: +86-10-62673095              *
*************************************


_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to