>>>>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> OK, I must have snoozed through that one, or maybe I wasn't on Lars> this list then. Was between the maintainers. Lars> What was the conclusion? "Yeay to 2.50"? BTW, if as you say, Lars> 2.50 is never going to be born, never mind... ;) :) If you use Gnus and still don't know about C-d, it's time for a try.
Subject: Topics Topics: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic Re: Patch Panic
Hi! I'm in a difficult position: my home Autoconf and CVS Autoconf are severely diverging, because it's been weeks that the patch queue is not flushed, hence I cannot synchronize. Today reading a few lines of acgeneral.m4 I can tell you whether it's home Autoconf or CVS Autoconf :(. I can't proceed ---my patches will start to be inapplicable--- but I would like to ---let's kill the 2.15 beast---. Anyway, independently from my sync problems, Alexandre obviously has even more work than before, and cannot devote as much time to Autoconf as he used to (this is my feeling, we didn't talk about this, so I might be completely wrong). So, again ---this is my period---, I'd like to be free from approval. But I know Alexandre cannot accept this :) So my proposal is: I can commit my patches once they are 48 hour old and not discussed. Those 48h exclude Saturday and Sunday and the other holly days, of course. As usual, I shall emphasize that a patch committed is not a patch which can no longer be discussed. And I think you can trust me to raise the issues that really need to be discussed. Akim
On May 10, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > So my proposal is: I can commit my patches once they are 48 hour old > and not discussed. Those 48h exclude Saturday and Sunday and the > other holly days, of course. The libtool team has adopted a 72-hours-of-silence-is-approval rule. You know I can't suggest or agree with anything like that for autoconf, but just in case you're willing to overrule me again... :-) > As usual, I shall emphasize that a patch committed is not a patch > which can no longer be discussed. And I think you can trust me to > raise the issues that really need to be discussed. Sounds reasonable to me. -- Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/ Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com Free Software Developer and Evangelist CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On May 10, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >> So my proposal is: I can commit my patches once they are 48 hour >> old and not discussed. Those 48h exclude Saturday and Sunday and >> the other holly days, of course. Alexandre> The libtool team has adopted a Alexandre> 72-hours-of-silence-is-approval rule. Wow, I didn't know. Heck, I really thought I had invented a new concept :) Alexandre> You know I can't suggest or agree with anything like that Alexandre> for autoconf, but just in case you're willing to overrule Alexandre> me again... :-) OK. I saw there's a zillion of mail in ACPatches, so I suppose I'll give you another break before I strike back :) Thanks for your efforts Alexandre. Akim
From: Alexandre Oliva <[EMAIL PROTECTED]> Date: 10 May 2000 06:14:36 -0300 The libtool team has adopted a 72-hours-of-silence-is-approval rule. This sounds reasonable to me, for autoconf. Of course if someone later wants to discuss a patch they can bring it up then. I also agree with Tom Tromey that it's reasonable to number the next release 3.0. (I would go further and fix the quoting rules even if it's incompatible. Call me a radical. :-)
>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> I also agree with Tom Tromey that it's reasonable to number the Paul> next release 3.0. (I would go further and fix the quoting rules Paul> even if it's incompatible. Call me a radical. :-) This is the kind of changes that are worth 3.0ing. 2.50 looks ugly (sorry :) 2.95 looks pretentious. 2.15 looks like my dreams since one year ago :)
Paul Eggert <[EMAIL PROTECTED]> writes: | From: Alexandre Oliva <[EMAIL PROTECTED]> | Date: 10 May 2000 06:14:36 -0300 | | The libtool team has adopted a 72-hours-of-silence-is-approval rule. | | This sounds reasonable to me, for autoconf. Of course if someone | later wants to discuss a patch they can bring it up then. This is fine with me, too. | I also agree with Tom Tromey that it's reasonable to number the next | release 3.0. (I would go further and fix the quoting rules even if | it's incompatible. Call me a radical. :-) I'm comfortable with just about any version numbering system.
Akim> I'm in a difficult position: my home Autoconf and CVS Autoconf Akim> are severely diverging, because it's been weeks that the patch Akim> queue is not flushed, hence I cannot synchronize. I think the next release should be called "3.0". Let's face it: you've basically rewritten autoconf. Every weekend there are 30 new patches. I don't see how we could call this "2.15" with a straight face. Tom
Hello! > I think the next release should be called "3.0". > Let's face it: you've basically rewritten autoconf. > Every weekend there are 30 new patches. > I don't see how we could call this "2.15" with a straight face. IMHO it should be at least 2.50. Badly written configure.in will certainly break. People should be advised to keep 2.13 somewhere if they occasionally need to regenerate configure in other people's packages without going into much trouble fixing them. I do keep autoconf-2.13 in /usr. It helps sometimes. Regards, Pavel Roskin
On May 10, 2000, Pavel Roskin <[EMAIL PROTECTED]> wrote: > Hello! >> I think the next release should be called "3.0". >> Let's face it: you've basically rewritten autoconf. >> Every weekend there are 30 new patches. >> I don't see how we could call this "2.15" with a straight face. > IMHO it should be at least 2.50. I'd suggested 2.95 before. I still think it's a good idea. 3.0 sounds like too much of a jump to me; 2.95 will give me some time to get used to the idea of autoconf 3 :-) > Badly written configure.in will certainly break. Bug reports, please. We shouldn't be breaking configure.in scripts at all. -- Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/ Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com Free Software Developer and Evangelist CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>> Badly written configure.in will certainly break. Alexandre> Bug reports, please. We shouldn't be breaking configure.in Alexandre> scripts at all. I already mentioned the sinclude thing, for one. Having AC_BEFORE violations be ignored seems like one, too, though of a different sort. Tom
>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: >>> Badly written configure.in will certainly break. Alexandre> Bug reports, please. We shouldn't be breaking configure.in Alexandre> scripts at all. Tom> I already mentioned the sinclude thing, for one. Having I've not forgot it! Tom> AC_BEFORE violations be ignored seems like one, too, though of a Tom> different sort. Right. I introduced -W error to this end too.
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: >> Badly written configure.in will certainly break. Alexandre> Bug reports, please. We shouldn't be breaking configure.in Alexandre> scripts at all. Seconded! Zillioned!
Hello, Alexandre! > > Badly written configure.in will certainly break. > > Bug reports, please. We shouldn't be breaking configure.in scripts at > all. My favorite: AC_CHECK_TYPE(loff_t,off_t) The following comment from acgeneral.m4 is just scary: # Dispatch respectively to _AC_CHECK_TYPE_OLD or _AC_CHECK_TYPE_NEW. # 1. More than two arguments => NEW # 2. $2 seems to be builtin type => OLD # 3. $2 seems to be a type => NEW plus a warning # 4. default => NEW Instead of using a new name, the old one is "reused" in a dangerous and incompatible way. It _is_ a serious incompatability, even if it can be justified. Pavel
| Hello, Alexandre! | > > Badly written configure.in will certainly break. | > | > Bug reports, please. We shouldn't be breaking configure.in scripts at | > all. | | My favorite: | | AC_CHECK_TYPE(loff_t,off_t) | | The following comment from acgeneral.m4 is just scary: I find this beautiful :) | # Dispatch respectively to _AC_CHECK_TYPE_OLD or _AC_CHECK_TYPE_NEW. | # 1. More than two arguments => NEW | # 2. $2 seems to be builtin type => OLD | # 3. $2 seems to be a type => NEW plus a warning | # 4. default => NEW | | Instead of using a new name, the old one is "reused" in a dangerous and | incompatible way. It _is_ a serious incompatability, even if it can be | justified. OK, give us the list of the types which should appear in $2 then! We debated about this, and on second thought, we should have been a bit more generous about the possible OLD $2. Akim
Hello! > OK, give us the list of the types which should appear in $2 then! > We debated about this, and on second thought, we should have been a > bit more generous about the possible OLD $2. I must have missed the discussion, sorry :-( I think every single word ending with "_t" should be assumed to be a type name. I don't know if it's essential to be a builtin type. Pavel
>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Hello! >> OK, give us the list of the types which should appear in $2 then! >> We debated about this, and on second thought, we should have been a >> bit more generous about the possible OLD $2. Pavel> I must have missed the discussion, sorry :-( I think every Pavel> single word ending with "_t" should be assumed to be a type Pavel> name. I don't know if it's essential to be a builtin type. As Paul pointed out, it is: that what the documentation says. But several times we've hit undocumented features on which people depend, one recent example being AC_CANONICAL_HOST, and finally, for sake of acceptance of this Autoconf, it was chosen to make it official. So I agree that `word_t' would be a nice addition to the heuristic, but I agree it's out of the track. As for uint, well, I don't know.
On May 11, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Hello! >>> OK, give us the list of the types which should appear in $2 then! >>> We debated about this, and on second thought, we should have been a >>> bit more generous about the possible OLD $2. Pavel> I must have missed the discussion, sorry :-( I think every Pavel> single word ending with "_t" should be assumed to be a type Pavel> name. I don't know if it's essential to be a builtin type. > So I agree that `word_t' would be a nice addition to the heuristic, > but I agree it's out of the track. As for uint, well, I don't know. Well, both of these would trigger the warning (which I think, in this case, should be printed by default), so I think we don't have to change it. -- Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/ Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com Free Software Developer and Evangelist CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: >> So I agree that `word_t' would be a nice addition to the heuristic, >> but I agree it's out of the track. As for uint, well, I don't >> know. Alexandre> Well, both of these would trigger the warning (which I Alexandre> think, in this case, should be printed by default), so I Alexandre> think we don't have to change it. Huh? Who are you? What have you done to Alexandre? Get out of that machine! You should know it's bad to steal the identity of other people! Man, I must say I don't understand: we're developing so much efforts to be compatible, it is so easy to catch word_t here, that I don't catch how you can be sitting at my place now, and vice versa!
On May 12, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: >>> So I agree that `word_t' would be a nice addition to the heuristic, >>> but I agree it's out of the track. As for uint, well, I don't >>> know. Alexandre> Well, both of these would trigger the warning (which I Alexandre> think, in this case, should be printed by default), so I Alexandre> think we don't have to change it. > Huh? Who are you? What have you done to Alexandre? Get out of that > machine! You should know it's bad to steal the identity of other > people! Sorry, guys. It seems xlock crashed again (it's been crashing quite often for me on GNU/Linux/alpha :-( and someone has been sending e-mail using my account :-) :-) I'm not against accepting word_t, I was just pointing out that it was not strictly necessary to cover this case, since it would be warned about whenever someone attempted to rebuild configure. So, if you feel like adding word_t to the heuristics, by all means, go ahead! -- Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/ Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com Free Software Developer and Evangelist CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> I'm not against accepting word_t, I was just pointing out Alexandre> that it was not strictly necessary to cover this case, Alexandre> since it would be warned about whenever someone attempted Alexandre> to rebuild configure. So, if you feel like adding word_t Alexandre> to the heuristics, by all means, go ahead! Hm, are you saying we can break the compatibility as long as we warn? It won't change anything for 2.50 because it's already in place, but it can change things in the future :)
On May 12, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: > Hm, are you saying we can break the compatibility as long as we warn? In case of a clear violation of the documented behavior, it may be acceptable to do so. Let's not take it as a general statement, it should be pondered on a case-by-case basis. -- Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/ Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com Free Software Developer and Evangelist CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On May 12, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >>>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> >>>>>>> writes: >> Hm, are you saying we can break the compatibility as long as we >> warn? Alexandre> In case of a clear violation of the documented behavior, it Alexandre> may be acceptable to do so. Let's not take it as a general Alexandre> statement, it should be pondered on a case-by-case basis. Aaah! This is the real and only Alexandre I know! Come on, man, fight! I'm gonna KYA :) ``Blague ą part'' (~ ``puns excluded'', I don't know how to say that in English), I agree.
Akim Demaille <[EMAIL PROTECTED]> writes: | ``Blague ą part'' (~ ``puns excluded'', I don't know how to say that | in English), I agree. How about `joking aside'?
>>>>> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes: Jim> How about `joking aside'? Is it a common idiom? It's usual to say `blague ą part' in French.
Date: Wed, 10 May 2000 12:53:00 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> # Dispatch respectively to _AC_CHECK_TYPE_OLD or _AC_CHECK_TYPE_NEW. # 1. More than two arguments => NEW # 2. $2 seems to be builtin type => OLD # 3. $2 seems to be a type => NEW plus a warning # 4. default => NEW Instead of using a new name, the old one is "reused" in a dangerous and incompatible way. It _is_ a serious incompatability, It's an incompatibility with the 2.13 _behavior_, but it's not an incompatibility with the 2.13 _documentation_, which says that $2 must be a C (or C++) builtin type. Any configure.in that specifies a non-builtin type for $2 is relying on undocumented behavior. Before the above change was accepted, I surveyed a wide variety of packages for uses of AC_CHECK_TYPE, and found only two (tcpdump and samba) that used non-builtin types for $2. tcpdump 3.2.1 used u_int, and samba used off_t and loff_t. I volunteered to submit patches for those two programs when appropriate.
Hello, Paul! > Before the above change was accepted, I surveyed a wide variety of > packages for uses of AC_CHECK_TYPE, and found only two (tcpdump and > samba) that used non-builtin types for $2. tcpdump 3.2.1 used u_int, > and samba used off_t and loff_t. I volunteered to submit patches for > those two programs when appropriate. Cool! It was a "stripped" version of samba included to the sources of GNU Mignight Commander to provide SMB support! Samba 2.0.7 still relies on the undocumented behaviour. Tcpdump 3.4 doesn't use AC_CHECK_TYPE at all. Could you show me the patch? Pavel
>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Akim> I'm in a difficult position: my home Autoconf and CVS Autoconf Akim> are severely diverging, because it's been weeks that the patch Akim> queue is not flushed, hence I cannot synchronize. Tom> I think the next release should be called "3.0". I've always dreamed of 3.0 as a real cleanup, which would include the removal of things which are more a pain than anything else. I do share a lot of the concerns that Alexandre has wrt compatibility, although there are definitely places where he is more than me. Thanks to him, I think we can say it is a member of 2.0. Tom> Let's face it: you've basically rewritten autoconf. Nah, not only, almost all Autoconf :) I'd like to keep 3.0 for something brand new: specializing loops, autosystem etc. There are novelties in this Autoconf, but basically invisible. Akim
On May 10, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > I'd like to keep 3.0 for something brand new: specializing loops, > autosystem etc. We can always have autoconf 4 :-) > There are novelties in this Autoconf, but basically invisible. That's a very good point. So I figure we should call it 2.50. After all, there's not so much difference from fifteen to fifty. Maybe people won't even notice :-) :-) -- Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/ Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com Free Software Developer and Evangelist CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> That's a very good point. So I figure we should call it Alexandre> 2.50. After all, there's not so much difference from Alexandre> fifteen to fifty. Maybe people won't even notice :-) :-) Ok for Autoconf two dot fifty vs two dot fifteen :) But really, why jump? Hm, I know the answer: why not jump. Well, I really like the idea we're walking in the steps of djm and Ben, I like to think we're here to second them. I feel close to them in this respect. When I work on Autoconf I feel Yoda and Ben next to me, and it feels good. A jump would be like a separation. We display we're different from our predecessors. We should not do that yet for the first release after them. This is for the Humanconf side of project. For the Machineconf side, because we felt so prisoner of the compatibility, we grew the next Autoconf, not a next generation.
Akim Demaille <[EMAIL PROTECTED]> writes: | >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: | | Alexandre> That's a very good point. So I figure we should call it | Alexandre> 2.50. After all, there's not so much difference from | Alexandre> fifteen to fifty. Maybe people won't even notice :-) :-) | | Ok for Autoconf two dot fifty vs two dot fifteen :) Yes.
| Akim Demaille <[EMAIL PROTECTED]> writes: | | >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: | | | | Alexandre> That's a very good point. So I figure we should call it | | Alexandre> 2.50. After all, there's not so much difference from | | Alexandre> fifteen to fifty. Maybe people won't even notice :-) :-) | | | | Ok for Autoconf two dot fifty vs two dot fifteen :) | | Yes. Hm, maybe I trapped myself, maybe I misunderstand your answer, but I intended to agree for the version numbers spelled in letters, but not in digits :). I'm for 2.15, but this is not vital for me.
Akim Demaille <[EMAIL PROTECTED]> writes: | | Akim Demaille <[EMAIL PROTECTED]> writes: | | | >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: | | | | | | Alexandre> That's a very good point. So I figure we should call it | | | Alexandre> 2.50. After all, there's not so much difference from | | | Alexandre> fifteen to fifty. Maybe people won't even notice :-) :-) | | | | | | Ok for Autoconf two dot fifty vs two dot fifteen :) | | | | Yes. | | Hm, maybe I trapped myself, maybe I misunderstand your answer, but I | intended to agree for the version numbers spelled in letters, but not | in digits :). | | I'm for 2.15, but this is not vital for me. I meant 2.50 is ok (presumably leading up to 3.0). But so is 2.15, even though increasing by such a small increment would seem to suggest far fewer changes than there have been. When I rewrote a few of the programs in each of the *utils packages (and went for a year or two between major releases), I incremented the major version number to reflect that there'd been some significant internal changes, though not many externally visible ones. To me, merely incrementing a minor version number implies that there have been mainly bug-fixing changes and perhaps a few new options, but not major architectural changes. These days, many people expect a version number to convey a lot more information about the state of a package than it used to.
>>>>> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes: Jim> These days, many people expect a version number to convey a lot Jim> more information about the state of a package than it used to. Well, OK, I'm OK with both 2.50 and 2.95. Presented lie this, 2.95 makes sense.
I meant 2.50. I think there's a general agreement on this one.
