From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Michael Elizabeth Chastain Cc: ac131313@cygnus.com, gdb@sources.redhat.com Subject: Re: CVS versions of gdb have same number as stable version. Date: Fri, 16 Feb 2001 11:57:00 -0000 Message-id: <5mhf1u9z9y.fsf@jtc.redback.com> References: <200102161928.LAA00929@bosch.cygnus.com> X-SW-Source: 2001-02/msg00228.html >>>>> "Michael" == Michael Elizabeth Chastain 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