Re: CVS versions of gdb have same number as stable version.

[jtc@redback.com (J.T. Conklin)]

>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:
>> Don't other GNU projects do things like 5.0.XX, where XX starts off at
>> a high number like 80 and is periodically incremented until the next
>> release?

Michael> I will change it to "5.0.90", or whatever, if a maintainer with the
Michael> authority to approve this patch specifies an exact string and states
Michael> that they will approve that string.
Michael>
Michael> Then I'll check in such patch without another round of [RFA].

Sounds reasonable.  

>> Another alternative would be a date stamp, similar to GDB snapshots.

Michael> I think you mean "similar to gcc snapshots".  I'm not going
Michael> to do that.  gcc has additional configury to do that, and I
Michael> am not going to port that configury and then qualify it on a
Michael> bunch of platforms.

No, I meant gdb snapshots.  I don't know how GDB snapshots are made,
but my local GDB repository, which was last sync'd with the 20010108 
snapshot has VERSION=20010108 in gdb/Makefile.in.  

Michael> Instead I'm going to spend my time in gdb/7, analyzing why
Michael> gdb core dumps when I do "maint print symbols" in some gdb
Michael> that calls itself 5.0 on the user's system.  If I can get
Michael> bleeding edge CVS gdb to quit calling itself 5.0, that makes
Michael> my task easier.  (Not to mention I have a day job.)

This seems like a good use of your time.

Michael> I hate this pattern:
Michael>
Michael>   Would-be contributor notices a bug.
Michael>   Would-be contributor writes a patch.
Michael>   Maintainer says: "if you're going to fix the problem, how about 
Michael>                     doing lots more work while you are in there?"

Note that's not exactly what I said.  I think it is a good idea for a bit
of brainstorming to ensure that the problem is well understood, decisions 
are not clear cut, etc.  In the end, I think this results in a better out-
come.  Due to the distributed nature of GDB development, it increases 
latency, but that's a price that has to be paid.

As part of the debate, we determine whether a change is *the* solution
to the problem, or an incremental step towards the solution (and, in
rare cases, a step back that should be rejected).

But note, I think it is important that maintainers have the right to
reject a change and ask the submitter to do more work.  In the past,
we have accepted changes that clearly needed more work (e.g. TUI).
I'd like to avoid these types of mistakes in the future.

Michael> My patch is on the table.
Michael>   -- approved?
Michael>   -- specific counter-proposal?
Michael>   -- rejected?

None of the above?  

If I'm not misremembering the 5.0.XX convention (perhaps it's only
used for formal 5.1 test releases), I'd approve the change.  I
strongly prefer that form to "-experimental".  But I would prefer
input from others, cuz it seems somehow wrong to approve your own
proposal.

        --jtc

-- 
J.T. Conklin
RedBack Networks