Re: dpkg semi-hijack - an announcement (also, triggers)
On dim, mar 09, 2008 at 11:28:13 +, Ian Jackson wrote: > With this message I am unilaterally declaring myself a maintainer of > dpkg, and also declaring that Guillem is no longer a maintainer. > > I have just made the hijack upload, dpkg 1.15.0, which contains > triggers support. You can find the specification in doc/ in the > source, or in /usr/share/doc/dpkg-dev/triggers.text.gz. What a brilliant success for your new upload ! http://buildd.debian.org/~jeroen/status/package.php?p=dpkg Congrats, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpFJl4xJAHc3.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 11:28:13AM +, Ian Jackson wrote: > With this message I am unilaterally declaring myself a maintainer of > dpkg, and also declaring that Guillem is no longer a maintainer. How can you possibly consider this justified, without even passing through the TC? I find your decision to do this in appallingly bad taste. If I could produce a ten page essay on why I would be a superior maintainer for one of your packages could I simply hijack it? > [4] Why not ask the Technical Committee to rule ? > > The TC has not shown great dynamism in recent months. I have tried > quite hard as a TC member to get various questions that were put to > the TC decided, and the results have not been encouraging. > > In any case, asking the TC about this at this stage would probably > take at least a month or more. This would make it that much harder > for other packages' maintainers to make good use of triggers in lenny. > It would also allow Guillem to continue making his undesirable > wholesale edits in the meantime. > > Finally, of course, I am on the Technical Committee. For me to appeal > this dispute to it in this way would seem too much like me using it as > a personal bludgeon. You want to talk about appearances. It appears that you're acting as inherently superior to another developer without involving the TC because of the fact that you're already on it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 11:28:13AM +, Ian Jackson wrote: > With this message I am unilaterally declaring myself a maintainer of > dpkg, and also declaring that Guillem is no longer a maintainer. I find this unacceptable. This kind of situations are precisely those in which people should resort to the Technical Committee. Your main argument for not doing so is that it would take to long. This is not a justification for bypassing TC and, de facto, declaring yourself the "winner" of the dispute. I do care about having triggers in Lenny, but you have no proof of either of the following 2 facts: 1) the TC won't decide on time for Lenny 2) Guillem won't have time to review and integrate your changes on time for Lenny No matter what, the default should be to *wait*, not to decide you are on the right side and upload (with poor results apparently). Your other argument for not resorting to the TC is that you are part of it. I won't see a conflict of interest in you resorting the issue to the TC at all. But of course I would expect from you that you won't take part at all in the TC decision on the matter (no post to the bug log, no private post, no vote). Please resort to the TC and, in the meantime, revert your changes. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On dim, mar 09, 2008 at 11:28:13 +, Ian Jackson wrote: > REFERENCES, BACKGROUND and FURTHER DISCUSSION > > > [1] Guillem persistently reintroducing errors, wholesale > > Here is an example of a big code change made by Guillem: > > http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e > However this is wrong as I explained here: > http://lists.debian.org/debian-dpkg/2007/10/msg00200.html > > I also emailed Guillem privately in August 2007 to ask that he stop > this kind of thing. > > Guillem has persisted with exactly the same mistake. For example: > > http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=02680ecbbbf6da2b023891a11b38ecce5346dbbd > > It is one thing to make a coding mistake. Everyone makes mistakes. > It is quite another to make a widespread change, without discussion, > and which is even if it is correct and worthwhile only at best > stylistically helpful. And then, after having been told that it was > wrong, to continue requires a dogmatic belief in one's own > correctness. AHAHAHAHAHA I totally missed that part in the first read. You're totally on crack. Under C, NULL is defined as (void *)0 (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and "someone" is not going to #define NULL 0. I fully support Guillem changes. C99 is almost 10 years old, we're coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever environment. Or are you also coding with 6-chars long variables names because pre-ansi C didn't required compilers to remember more than 6 chars to distinguish variable names ? If you're so afraid that one of the included headers defines NULL to '0', then just assert (__builtin_types_compatible(NULL, void *)) somewhere and be done with it. But please, (char *)0 is not only wrong, it's also tasteless and ugly to the eye. > [2] Reformatting changes > > Guillem has been engaging in a programme of reformatting and restyling > of dpkg's code. > > See for example #375711 where I submit a patch to correct what seemed > to me obviously a tab/space conversion error, but which turned out to > be deliberate. (I first asked about this on debian-dpkg the 26th of > June 2006 and there was no reply until over a month later on the 31st > of May, so that I was already committed to my triggers code being > based on the original, rather Guillem's, formatting.) See also the > examples above. > > Everyone who works on free software knows that reformatting it is a > no-no. You work with the coding style that's already there. Oo I definitely don't live in the same world than yours. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPopuljMASM.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote: > > AHAHAHAHAHA I totally missed that part in the first read. You're > totally on crack. Under C, NULL is defined as (void *)0 > (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and > "someone" is not going to #define NULL 0. It is defined like that on some OSs. It's perfectly valid to do that. In case of stdarg you need to cast NULL to a pointer. > But please, (char *)0 is not only wrong, > it's also tasteless and ugly to the eye. I've suggested the use of (char *)NULL in the case that it's needed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, 09 Mar 2008, Ian Jackson wrote: > With this message I am unilaterally declaring myself a maintainer of > dpkg, and also declaring that Guillem is no longer a maintainer. For the record, Ian has been removed from the "dpkg" group on Alioth and we asked for an UNACCEPT of his upload, but I'm not sure it will be done on time as none of the ftpmasters responded yet to my queries on IRC. You can also read the log of #debian-dpkg since friday evening where I spent two hours with him trying to find some compromise so that he can contribute to dpkg. He just ignored everything we said and took this ridiculous decision. http://people.debian.org/~hertzog/debian-dpkg.log Guillem has been working on the trigger integration this week and I told so to Ian. But apparently he couldn't wait a few days more. > I have spoken at length with Raphael on IRC. We had a productive > conversation which convinced me that Raphael and I could have a > productive working relationship. We were able to resolve our > difference over future workflow, at least setting aside the fate of > the triggers branch. I don't know how you could ever expect me accepting your unilateral removal of Guillem from the team. > I have deleted the `master' branch ref for the moment to avoid anyone > being subjected to an unpleasant accident. Around 48 hours from this > message I intend to rename `master-new' to `master' to confirm the > situation. Good choice, at least it's easy to clean up the mess now that you can't commit any more. > [1] Guillem persistently reintroducing errors, wholesale > > Here is an example of a big code change made by Guillem: > > http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e > However this is wrong as I explained here: > http://lists.debian.org/debian-dpkg/2007/10/msg00200.html > > I also emailed Guillem privately in August 2007 to ask that he stop > this kind of thing. > > Guillem has persisted with exactly the same mistake. For example: > > http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=02680ecbbbf6da2b023891a11b38ecce5346dbbd > > It is one thing to make a coding mistake. Everyone makes mistakes. > It is quite another to make a widespread change, without discussion, > and which is even if it is correct and worthwhile only at best > stylistically helpful. And then, after having been told that it was > wrong, to continue requires a dogmatic belief in one's own > correctness. Can you tell us in which situations we have "#define NULL 0" as opposed to "#define NULL (void*)0" ? And why would the right fix be to revert all usage of NULL instead of, say, add the proper define in a dpkg include file to override the bad one that could come from... (I don't know see first question) ? Don't you feel like that this argument is ridiculous to remove Guillem from the team? > [2] Reformatting changes > > Guillem has been engaging in a programme of reformatting and restyling > of dpkg's code. I agree that it's necessarily a good idea to reformat the code but you brought up the subject (in an unpleasant way, as usual) and as AFAIK he didn't push more stylistic changes since then. > [3] Changes that have been blocked by Guillem: > > These are changes that I prepared or reviewed, and which have > unaccountably not been included in mainline: We still have about 60 patches in the BTS and only a tiny fraction comes from you. If you could have been more pro-active, maybe more of your patches would have been integrated but instead once the patch were ready you disappeared and after X months you come back and complain that we're blocking you. And in fact, some of your changes have been merged already: http://git.debian.org/?p=dpkg%2Fdpkg.git&a=search&h=master&st=author&s=Ian+Jackson And more of your small changes would have been already integrated if you didn't decide alone to make them depend on the prior integration of your triggers branch (as you did for #432893). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 05:21:47PM +, Kurt Roeckx wrote: > On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote: > > > > AHAHAHAHAHA I totally missed that part in the first read. You're > > totally on crack. Under C, NULL is defined as (void *)0 > > (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and > > "someone" is not going to #define NULL 0. > > It is defined like that on some OSs. Not in Debian, and dpkg is mostly a Debian tool, working on the glibc, that defines NULL the proper way. > It's perfectly valid to do that. No it's not, and OSes that do, are not C99 compliant (and not even C89 IIRC, but I've no C89 spec at hand to check). > In case of stdarg you need to cast NULL to a pointer. That's the very reason why NULL shall be a pointer. Here is the relevant C99 quote: § 7.17 Common definitions [...] 3 The macros are NULL which expands to an implementation-defined null pointer constant; and 0 is not a pointer, hence disqualifies. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSZTl8htzfa.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, 09 Mar 2008, Raphael Hertzog wrote: > > [2] Reformatting changes > > > > Guillem has been engaging in a programme of reformatting and restyling > > of dpkg's code. > > I agree that it's necessarily a good idea to reformat the code but you ^ not > brought up the subject (in an unpleasant way, as usual) and as AFAIK he > didn't push more stylistic changes since then. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:34:48PM +0100, Pierre Habouzit wrote: > On Sun, Mar 09, 2008 at 05:21:47PM +, Kurt Roeckx wrote: > > On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote: > > > > > > AHAHAHAHAHA I totally missed that part in the first read. You're > > > totally on crack. Under C, NULL is defined as (void *)0 > > > (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and > > > "someone" is not going to #define NULL 0. > > > > It is defined like that on some OSs. > > Not in Debian, and dpkg is mostly a Debian tool, working on the glibc, > that defines NULL the proper way. > > > It's perfectly valid to do that. > > No it's not, and OSes that do, are not C99 compliant (and not even C89 IIRC, > but I've no C89 spec at hand to check). > > > In case of stdarg you need to cast NULL to a pointer. > > That's the very reason why NULL shall be a pointer. > > Here is the relevant C99 quote: > > > § 7.17 Common definitions > [...] > 3 The macros are > NULL > which expands to an implementation-defined null pointer constant; and 6.3.2.3 Pointers [...] 3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is assigned to or compared for equality to a pointer, the constant is converted to a pointer of that type. Such a pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. [...] 55) The macro NULL is defined in as a null pointer constant; see 7.17. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Ian Jackson wrote: [4] Why not ask the Technical Committee to rule ? The TC has not shown great dynamism in recent months. I have tried quite hard as a TC member to get various questions that were put to the TC decided, and the results have not been encouraging. In any case, asking the TC about this at this stage would probably take at least a month or more. This would make it that much harder for other packages' maintainers to make good use of triggers in lenny. It would also allow Guillem to continue making his undesirable wholesale edits in the meantime. Finally, of course, I am on the Technical Committee. For me to appeal this dispute to it in this way would seem too much like me using it as a personal bludgeon. If you don't recognize the authority or the necessity of the Technical Committee on such matters but instead decide take matters into your own hands, I'd expect from you to resign from the comittee. I can't understand how a Debian Developer, let alone a Technical Comittee member, can find it acceptable to hijack a package actively maintained because of technical disagreements with its maintainer. Especially if that package is a core package such as dpkg. You're hurting the credibility of the comittee and of the whole project. That's much more important than a disagreement on a technical matter. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:48:41PM +0100, Kurt Roeckx wrote: > 6.3.2.3 Pointers > [...] > 3 An integer constant expression with the value 0, or >such an expression cast to type void *, is called a null >pointer constant.55) If a null pointer constant is assigned >to or compared for equality to a pointer, the constant is >converted to a pointer of that type. Such a pointer, called >a null pointer, is guaranteed to compare unequal to a >pointer to any object or function. That's not really want the C99 version said. It says: 3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:00:31PM +, Kurt Roeckx wrote: > On Sun, Mar 09, 2008 at 06:48:41PM +0100, Kurt Roeckx wrote: > > 6.3.2.3 Pointers > > [...] > > 3 An integer constant expression with the value 0, or > >such an expression cast to type void *, is called a null > >pointer constant.55) If a null pointer constant is assigned > >to or compared for equality to a pointer, the constant is > >converted to a pointer of that type. Such a pointer, called > >a null pointer, is guaranteed to compare unequal to a > >pointer to any object or function. > > That's not really want the C99 version said. It says: > 3 An integer constant expression with the value 0, or > such an expression cast to type void *, is called a null > pointer constant.55) Well, I read it that way: An integer constant expression with the value 0 (or such an expression) cast to type void *, is called a null pointer constant.55) IOW, a null pointer constant is similar to (void *)0. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWPAsJS0OE8.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008, Ian Jackson wrote: > Finally, of course, I am on the Technical Committee. For me to appeal > this dispute to it in this way would seem too much like me using it as > a personal bludgeon. You could also appeal this dispute to it and not take part in the vote, so that the TC's decision is not tainted with your personal opinion. -- Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:34:48PM +0100, Pierre Habouzit wrote: > Here is the relevant C99 quote: > > > § 7.17 Common definitions > [...] > 3 The macros are > NULL > which expands to an implementation-defined null pointer constant; and > > > 0 is not a pointer, hence disqualifies. Just to confirm Kurt's point, 0 is a "null pointer constant" in C. But it is not necessarily a pointer. You can't terminate a varargs list of pointers (e.g. execl) with NULL unless you cast it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote: > I fully support Guillem changes. C99 is almost 10 years old, we're > coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever > environment. Hmm... Not really. GCC's default mode is still C89+GNU extensions. It is true that the GNU extensions overlap C99 somewhat. But this does not destroy the validity of your claim (that dpkg is coded for a relatively decently modern compiler). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 07:09:39PM +0100, Pierre Habouzit wrote: > Well, I read it that way: > > An integer constant expression with the value 0 (or such an > expression) cast to type void *, is called a null pointer constant.55) Well, don't read it that way - the commas in the original version are correct and intentional :-) -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:16:03PM +, Lionel Elie Mamane wrote: > On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote: > > > I fully support Guillem changes. C99 is almost 10 years old, we're > > coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever > > environment. > > Hmm... Not really. GCC's default mode is still C89+GNU extensions. It > is true that the GNU extensions overlap C99 somewhat. But this does > not destroy the validity of your claim (that dpkg is coded for a > relatively decently modern compiler). dpkg is built using gcc --std=gnu99. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpzQc0plyevs.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 07:17:44PM +0100, Pierre Habouzit wrote: > On Sun, Mar 09, 2008 at 06:16:03PM +, Lionel Elie Mamane wrote: >> On Sun, Mar 09, 2008 at 05:50:16PM +0100, Pierre Habouzit wrote: >>> I fully support Guillem changes. C99 is almost 10 years old, we're >>> coding dpkg for Debian, in a sane C99/POSIX/X-OPEN/whatever >>> environment. >> Hmm... Not really. GCC's default mode is still C89+GNU extensions. It >> is true that the GNU extensions overlap C99 somewhat. But this does >> not destroy the validity of your claim (that dpkg is coded for a >> relatively decently modern compiler). > dpkg is built using gcc --std=gnu99. Ah, then, yes. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Pierre Habouzit writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> What a brilliant success for your new upload !
> http://buildd.debian.org/~jeroen/status/package.php?p=dpkg
This was due to a buggy translation update (predating my efforts, but
not yet uploaded by anyone). It seems that I used a lenny chroot
instead of a sid one, and you get the FTBFS on sid only.
This will be fixed shortly.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Pierre Habouzit writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> AHAHAHAHAHA I totally missed that part in the first read. You're
> totally on crack. Under C, NULL is defined as (void *)0
> (and *NOT* (char *)0 that is TOTALLY wrong for obvious reasons), and
> "someone" is not going to #define NULL 0.
ISO/IEC 9899:1999 (E) aka C99:
Section 6.3.2.3:
An integer constant expression with the value 0, or such an
expression cast to type void*, is called a _null pointer
constant_. [*] If a null pointer constant is converted to a pointer
type, the resulting pointer, called a null pointer, is guaranteed to
compare unequal to a pointer to any object or function.
[*] The macro NULL is defined in (and other headers) as a
null pointer constant; see 7.17.
Section 7.17:
The macros are
NULL
which expands to an implementation-defined null pointer constant; ...
Note that a `null pointer constant' is only a pointer if it is
converted to a pointer type. Just `0' is an `integer constant
expression with the value 0', and is therefore a `null pointer
constant' which is therefore permitted as a definition for NULL.
So C99 permits an implementation (that is, permits stddef.h) to
#define NULL 0
> If you're so afraid that one of the included headers defines NULL to
> '0', then just assert (__builtin_types_compatible(NULL, void *))
> somewhere and be done with it. But please, (char *)0 is not only wrong,
> it's also tasteless and ugly to the eye.
In what way is (char*)0 wrong in these contexts ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, 09 Mar 2008, Raphael Hertzog wrote: > On Sun, 09 Mar 2008, Ian Jackson wrote: > > With this message I am unilaterally declaring myself a maintainer of > > dpkg, and also declaring that Guillem is no longer a maintainer. > > For the record, Ian has been removed from the "dpkg" group on Alioth and > we asked for an UNACCEPT of his upload, but I'm not sure it will be done > on time as none of the ftpmasters responded yet to my queries on IRC. The package got unaccepted by Anthony Towns. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun March 9 2008 12:27:59 Faidon Liambotis wrote: > I can't understand how a Debian Developer, let alone a Technical > Comittee member, can find it acceptable to hijack a package actively > maintained because of technical disagreements with its maintainer. > Especially if that package is a core package such as dpkg. How would you feel if a bunch of less-than-stellar programmers took over one of your programs (Ian wrote dpkg) and blocked your changes for six months while they reformatted the white space and tried to learn basic C programming? The old dpkg team has not so much been actively maintaining dpkg as actively blocking maintenance of dpkg. They've been fumbling around for six months, messing with white space and making minor changes, while blocking Ian's enhancements. Every indication is that the old dpkg team is way out of its depth and should work their way up through simpler programming tasks before taking on something as crucial as dpkg. On the other hand, fer crissake Ian stop using 0 for NULL! You can use (char*)NULL if it helps. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Raphael Hertzog writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> You can also read the log of #debian-dpkg since friday evening where I
> spent two hours with him trying to find some compromise so that he can
> contribute to dpkg. He just ignored everything we said and took this
> ridiculous decision.
> http://people.debian.org/~hertzog/debian-dpkg.log
Please do go and read it. Here is the part right at the end, just
where it's all going wrong:
22:16 Perhaps I'm misunderstanding. Just so that we're completely
clear: Your view is that you are not willing to agree the
commit-to-trunk, or upload, of triggers, without Guillem's
blessing ?
22:17 (at this point), I believe?
22:17 yes (at least for a few days more until we really have no other
choices)
I got fed up of waiting. I asked in August. I asked again in October
and November. I asked again two weeks ago. And now I'm told `few
more days'.
Guillem said nothing to me personally. Nothing! All I have is an
idea from you that it will be a `few more days'.
> > I have deleted the `master' branch ref for the moment to avoid anyone
> > being subjected to an unpleasant accident. Around 48 hours from this
> > message I intend to rename `master-new' to `master' to confirm the
> > situation.
>
> Good choice, at least it's easy to clean up the mess now that you
> can't commit any more.
Well, making a mess in a revision control system is never a good idea.
> Can you tell us in which situations we have "#define NULL 0"
> as opposed to "#define NULL (void*)0" ?
Some C libraries do this for the benefit of broken old programs which
use NULL when they mean an integer or character0. C99 says it's legal
for NULL to be 0.
> And why would the right fix be to revert all usage of NULL instead of,
> say, add the proper define in a dpkg include file to override the bad
> one that could come from... (I don't know see first question) ?
Err, redefining NULL in dpkg ?
> Don't you feel like that this argument is ridiculous to remove Guillem
> from the team?
This and the other things I've complained of. He won't discuss these
matters with me.
> > [2] Reformatting changes
> >
> > Guillem has been engaging in a programme of reformatting and restyling
> > of dpkg's code.
>
> I agree that it's necessarily a good idea to reformat the code but you
> brought up the subject (in an unpleasant way, as usual) and as AFAIK he
> didn't push more stylistic changes since then.
Some commits:
d9091a81b6dc449038821451696577ebbd270715 21 Jan Refactor max open...
02680ecbbbf6da2b023891a11b38ecce5346dbbd 9 Jan Use NULL instead of 0
> We still have about 60 patches in the BTS and only a tiny fraction comes
> from you. If you could have been more pro-active, maybe more of your
> patches would have been integrated but instead once the patch were ready
> you disappeared and after X months you come back and complain
> that we're blocking you.
We had this discussion on IRC. No-one told me that after triaging a
bug to make a patch I should ping it every few weeks to chase it into
the tree. Indeed that's a terrible way of working. Am I supposed to
keep myself a list of all of my lost work ?
> And more of your small changes would have been already integrated if you
> didn't decide alone to make them depend on the prior integration of your
> triggers branch (as you did for #432893).
There was an merge conflict with my triggers branch. It was make the
fix depend on the triggers branch or do it twice. Since the triggers
branch ought to have been committed long ago I don't see the problem.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, On Sun, 2008-03-09 at 19:27 +, Faidon Liambotis wrote: > You're hurting the credibility of the comittee and of the whole > project. > That's much more important than a disagreement on a technical matter. On the other hand allowing dpkg to be maintained in the way that it presently is, is also hurting the credibility of the whole project. NOT THAT I AGREE WITH THE HIJACKING. That too, is not the proper solution to this. William signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:34:36PM +, Ian Jackson wrote:
> Pierre Habouzit writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
> > If you're so afraid that one of the included headers defines NULL to
> > '0', then just assert (__builtin_types_compatible(NULL, void *))
> > somewhere and be done with it. But please, (char *)0 is not only wrong,
> > it's also tasteless and ugly to the eye.
> In what way is (char*)0 wrong in these contexts ?
According to execlp manpage:
The list of arguments must be terminated by a NULL pointer,
and, since these are vari‐adic functions, this pointer _must_
be cast (char *) NULL.
--
"rm -rf" only sounds scary if you don't have backups
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:53:23PM +, Mike Bird wrote: > On Sun March 9 2008 12:27:59 Faidon Liambotis wrote: > > I can't understand how a Debian Developer, let alone a Technical > > Comittee member, can find it acceptable to hijack a package actively > > maintained because of technical disagreements with its maintainer. > > Especially if that package is a core package such as dpkg. > > How would you feel if a bunch of less-than-stellar programmers took over > one of your programs (Ian wrote dpkg) and blocked your changes for six > months while they reformatted the white space and tried to learn basic > C programming? /usr/share/doc/dpkg/changelog.Debian.gz shows that the dpkg team closed 148 bugs in the last 6 months. How many did you closed in the same period ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLGDqeWLoFj.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, 09 Mar 2008, Ian Jackson wrote: > > Can you tell us in which situations we have "#define NULL 0" > > as opposed to "#define NULL (void*)0" ? > > Some C libraries do this for the benefit of broken old programs which > use NULL when they mean an integer or character0. C99 says it's legal > for NULL to be 0. Fortunately Debian is concerned with the glibc only. And from what I can read (by others in this thread), using NULL instead of (char*)0 is always ok except when used to finish a vararg where (char*)NULL would be a simple compromise between readability and correctness. > > Don't you feel like that this argument is ridiculous to remove Guillem > > from the team? > > This and the other things I've complained of. He won't discuss these > matters with me. And I can understand him, you have never shown any willingness to discuss calmly and to make compromise. (And your coding style preference sucks and you cry when it evolves in dpkg because others dare touch your original code) > > I agree that it's necessarily a good idea to reformat the code but you > > brought up the subject (in an unpleasant way, as usual) and as AFAIK he > > didn't push more stylistic changes since then. > > Some commits: > d9091a81b6dc449038821451696577ebbd270715 21 Jan Refactor max open... > 02680ecbbbf6da2b023891a11b38ecce5346dbbd 9 Jan Use NULL instead of 0 When you complained, it was about indenting and spaces. Here I see improvements in readability of the program and a nicer check to decide between two ways to close all the open file descriptors (without hardcoding a specific OS in #ifdef). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Raphael Hertzog writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> The package got unaccepted by Anthony Towns.
OH FOR FUCK'S SAKE WHAT DOES IT TAKE TO GET SOMETHING DONE AROUND HERE?
SIX MONTHS THIS IMPORTANT CODE HAS JUST BEEN SITTING THERE
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Ian Jackson writes ("Re: dpkg semi-hijack - an announcement (also, triggers)"):
> Raphael Hertzog writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
> OH FOR FUCK'S SAKE WHAT DOES IT TAKE TO GET SOMETHING DONE AROUND HERE?
> SIX MONTHS THIS IMPORTANT CODE HAS JUST BEEN SITTING THERE
My tree is here:
http://git.debian.org/?p=users/iwj/dpkg.git;a=summary
This has 1.15.1 which should fix the broken German translation which
causes the FTBFS. I'm going to go away and calm down and/or find
something to hit.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 11:28:13AM +, Ian Jackson wrote: > > [1] Guillem persistently reintroducing errors, wholesale > > Here is an example of a big code change made by Guillem: > > http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e > However this is wrong as I explained here: > http://lists.debian.org/debian-dpkg/2007/10/msg00200.html OK, you are correct here, but (char *) NULL would be clearer overall. > I also emailed Guillem privately in August 2007 to ask that he stop > this kind of thing. > > Guillem has persisted with exactly the same mistake. For example: > > http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=02680ecbbbf6da2b023891a11b38ecce5346dbbd > > It is one thing to make a coding mistake. Everyone makes mistakes. > It is quite another to make a widespread change, without discussion, > and which is even if it is correct and worthwhile only at best > stylistically helpful. And then, after having been told that it was > wrong, to continue requires a dogmatic belief in one's own > correctness. Here, either make sense in C99. NULL does give slightly more context than 0 however, so there's nothing technically wrong with the change, even if your preferred style is to use 0. I seriously can't believe that you hijacked this over a disagreement about the definition/usage of NULL. Include and be done with it already--it's not like this is a pressing or difficult problem that warranted this action! -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote: > And what is the problem exactly? The delay in patch integration? A six month delay is unacceptable for code review. If it takes six months, then new leadership is clearly required. William signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun March 9 2008 13:44:08 Roger Leigh wrote: > I seriously can't believe that you hijacked this over a disagreement > about the definition/usage of NULL. Include and be done > with it already--it's not like this is a pressing or difficult problem > that warranted this action! Roger, NULL is just a minor distraction. Ian hijacked his own program back from the people who had been blocking updates for six months - including the triggers enhancement which is needed for boot time improvements and which should simplify some other packaging issues. This is not some hairy untested update - it has been working well in Ubuntu for a long time. There is no good reason why Debian is lagging Ubuntu by six months on our own packaging tool. The excuse given by the somewhat less than stellar dpkg team is that they need more time to understand the changes. If you look at the changes in git you'll see they are not small but neither are they particularly large, and that they are clear and even documented. There's nothing there that should have taken more than a couple of days to review. By blocking functionality for six months the old dpkg team has actively harmed Debian. Yet another distraction raised by the dpkg blocking team is that they want Ian to rebase. They insist it is their team policy, but when asked they point to a policy that recommends that the developer choose whether to rebase and gives no role to other team members in deciding whether the developer should rebase. Raphael has been given ample opportunity to post a link to a different policy or to retract his claims. He has chosen to do neither, which for me personally means I can no longer trust Raphael. Now Anthony Towns has leapt in with both feet and handed dpkg back to the obstructionists. If Anthony has posted an explanation I have not seen it. You will recall Anthony - he alienated many Debian developers with the Dunk-Tank fiaco and thereby significantly delayed the release of Etch. This apparently makes Anthony a natural ally of the dpkg blocking team. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On 09/03/2008, Mike Bird wrote: > Ian hijacked his own program back from the people who had been > blocking updates for six months - including the triggers enhancement > which is needed for boot time improvements Is dpkg handling the boot sequence? Or are you confusing that with dependency-based initscripts? -- Cyril Brulebois pgpO4ipOJOweh.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, On Sun, 2008-03-09 at 13:19 -0800, Mike Bird wrote: > including the triggers enhancement which is > needed for boot time improvements and which should simplify some other > packaging issues. I think you mean package install-time improvements, due to postponing ldconfig until the end of the installation. However, I am not sure how useful this is because many maintainer scripts not generated by debhelper call ldconfig locally. Obviously the maintainer scripts autogenerated by debhelper would be ok though. William signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
William Pitcock a écrit : > Hi, > > On Sun, 2008-03-09 at 13:19 -0800, Mike Bird wrote: >> including the triggers enhancement which is >> needed for boot time improvements and which should simplify some other >> packaging issues. > > I think you mean package install-time improvements, due to postponing > ldconfig until the end of the installation. However, I am not sure how > useful this is because many maintainer scripts not generated by > debhelper call ldconfig locally. There is no need to delay calls to ldconfig anymore. Upstream has added a secondary cache system in glibc 2.7, which make calls to ldconfig very cheap when no changes to the libraries have been done. Moreover as explained in the bug report, there are some concerns in delaying all calls to ldconfig, as they may cause some problems for libraries that are not in the standard search path, but defined in /etc/ld.so.conf. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
William Pitcock wrote: > On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote: > > And what is the problem exactly? The delay in patch integration? If you'd look at submitting patches to dpkg from the perspective of any recent patch submitter, I'd think that the problem would be clear. -- see shy jo signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
William Pitcock wrote: > I think you mean package install-time improvements, due to postponing > ldconfig until the end of the installation. However, I am not sure how > useful this is because many maintainer scripts not generated by > debhelper call ldconfig locally. > > Obviously the maintainer scripts autogenerated by debhelper would be ok > though. Triggers, if they ever reach the archive, should allow a vast improvement in the majority of maintainer script fragments inserted by debhelper, and in the simplicity, correctness, and speed of package installations. -- see shy jo signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun March 9 2008 14:46:50 Cyril Brulebois wrote: > On 09/03/2008, Mike Bird wrote: > > Ian hijacked his own program back from the people who had been > > blocking updates for six months - including the triggers enhancement > > which is needed for boot time improvements > > Is dpkg handling the boot sequence? Or are you confusing that with > dependency-based initscripts? I hope I'm not mis-stating Frans's position when I say that Frans believes dpkg triggers are the best way to install dependency-based initscripts[0]. Otherwise the installer unnecessarily and repetitively globally recalculates initscript dependencies for each package installed. I expect dpkg triggers would also be valuable for things like mktexlsr runs when working with texlive. --Mike Bird [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465587#35 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 02:17:15PM -0800, Mike Bird wrote: > On Sun March 9 2008 14:46:50 Cyril Brulebois wrote: > > Is dpkg handling the boot sequence? Or are you confusing that with > > dependency-based initscripts? > > I hope I'm not mis-stating Frans's position when I say that Frans > believes dpkg triggers are the best way to install dependency-based > initscripts[0]. Otherwise the installer unnecessarily and repetitively > globally recalculates initscript dependencies for each package installed. > > I expect dpkg triggers would also be valuable for things like mktexlsr > runs when working with texlive. AOL. Try installing anything tex-related on a slow or mid-speed machine. So, what about leaving the bikeshed painted in Ian's color, and starting from that point? There are two strong technical arguments: 1. triggers being a vital piece, and 2. diverging from Ubuntu is badly counter- productive. And then you can duke it out about NULL vs (char*)0 to your heart's content. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Mike Bird <[EMAIL PROTECTED]> writes: > Ian hijacked his own program back from the people who had been blocking > updates for six months - including the triggers enhancement which is > needed for boot time improvements dpkg triggers are nice to have, but they are not the reason why we haven't switched to a dependency-based init system yet. Please try to only refer to issues you have fully understood. Marc -- BOFH #389: /dev/clue was linked to /dev/null pgpTBgriEu3BK.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
I'm going to have to agree with this; I admin m68k buildds; I had to preinstall most of the texex packages simply because it was taking hours (and that is not an exaggeration) to install them all, and then remove them all again. A trigger based system would help relieve this problem. I had a similar slowdown installing texex packages on a slower powerpc That being said, I neither agree nor disagree with the hijacking of dpkg, but triggers are important, especially for slower architectures. Michael On Mon, 10 Mar 2008, Adam Borowski wrote: Date: Mon, 10 Mar 2008 00:07:15 +0100 From: Adam Borowski <[EMAIL PROTECTED]> To: debian-devel@lists.debian.org Subject: Re: dpkg semi-hijack - an announcement (also, triggers) Resent-Date: Sun, 9 Mar 2008 23:11:16 + (UTC) Resent-From: debian-devel@lists.debian.org On Sun, Mar 09, 2008 at 02:17:15PM -0800, Mike Bird wrote: On Sun March 9 2008 14:46:50 Cyril Brulebois wrote: Is dpkg handling the boot sequence? Or are you confusing that with dependency-based initscripts? I hope I'm not mis-stating Frans's position when I say that Frans believes dpkg triggers are the best way to install dependency-based initscripts[0]. Otherwise the installer unnecessarily and repetitively globally recalculates initscript dependencies for each package installed. I expect dpkg triggers would also be valuable for things like mktexlsr runs when working with texlive. AOL. Try installing anything tex-related on a slow or mid-speed machine. So, what about leaving the bikeshed painted in Ian's color, and starting from that point? There are two strong technical arguments: 1. triggers being a vital piece, and 2. diverging from Ubuntu is badly counter- productive. And then you can duke it out about NULL vs (char*)0 to your heart's content. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun March 9 2008 16:07:58 Marc 'HE' Brockschmidt wrote: > Mike Bird <[EMAIL PROTECTED]> writes: > > Ian hijacked his own program back from the people who had been blocking > > updates for six months - including the triggers enhancement which is > > needed for boot time improvements > > dpkg triggers are nice to have, but they are not the reason why we > haven't switched to a dependency-based init system yet. Please try to > only refer to issues you have fully understood. Marc, A necessary condition is not the same as a sufficient condition. Triggers are "needed" - a necessary condition, or at least a highly desirable condition - for efficient installation of packages in order to avoid unnecessary repetitive global reorderings of the initscript dependency DAG as each package is installed. "The reason why we haven't switched yet" does not exist, as there are several reasons not one, but if a single reason did exist it would have been a sufficient condition, not a necessary condition. In simple terms: "dpkg triggers" is a highly desirable precondition for dependency-based initscripts, but so are several other preconditions, not least of which is a substantial test period. The issues are well addressed in Frans' posting, the URL of which I have already posted once in this thread and will now post again[0]. I believe it was you who wrote "Please try to only refer to issues you have fully understood." --Mike Bird [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465587#35 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
[Not subscribed, Cc if you want me to see it.] On Sun, Mar 09, 2008 at 01:19:58PM -0800, Mike Bird wrote: > Ian hijacked his own program back from the people who had been blocking > updates for six months So Ian Murdock would be perfectly entitled to kick out the DAM, DPL, TC, DSA, and all others to really fix Debian? > including the triggers enhancement which is needed for boot time > improvements No, it isn't (better documented by other replies). > By blocking > functionality for six months the old dpkg team has actively harmed Debian. I was going to ask on which grounds exactly you were judging the dpkg team's competence (and that of iwj's: have you reviewed the branch yourself? can you confidently say that it's all fine?), but instead I'll ask this: How have you helped Debian in the last six months, if the dpkg team has actively harmed it for the last six? > He has chosen to > do neither, which for me personally means I can no longer trust Raphael. Tragedy. Daniel signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 07:52:28PM +0100, Raphael Hertzog wrote: > On Sun, 09 Mar 2008, Raphael Hertzog wrote: > > On Sun, 09 Mar 2008, Ian Jackson wrote: > > > With this message I am unilaterally declaring myself a maintainer of > > > dpkg, and also declaring that Guillem is no longer a maintainer. > > For the record, Ian has been removed from the "dpkg" group on Alioth and > > we asked for an UNACCEPT of his upload, but I'm not sure it will be done > > on time as none of the ftpmasters responded yet to my queries on IRC. > The package got unaccepted by Anthony Towns. Beyond that, any additional uploads of dpkg will be REJECTed until you guys resolve this nonsense. Flamewars on -devel, ignoring functional patches for months on end, package hijacks and requests for UNACCEPTs aren't the way to maintain dpkg. Cheers, aj signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
[Not CCing -dpkg anymore, not relevant there] Mike Bird <[EMAIL PROTECTED]> writes: > Triggers are "needed" - a necessary condition, or at least a highly > desirable condition - for efficient installation of packages in order > to avoid unnecessary repetitive global reorderings of the initscript > dependency DAG as each package is installed. No. They would be nice, nothing more. > "The reason why we haven't switched yet" does not exist, as there > are several reasons not one, but if a single reason did exist it > would have been a sufficient condition, not a necessary condition. > > In simple terms: "dpkg triggers" is a highly desirable precondition for > dependency-based initscripts, but so are several other preconditions, > not least of which is a substantial test period. The issues are > well addressed in Frans' posting, the URL of which I have already > posted once in this thread and will now post again[0]. You seem to believe that Frans decides if and when we are going to switch to a dep-based init system. That is not the case. The release team will decide together with the involved package maintainers if this is a feature that can reasonably be enabled for lenny [1]. At this point, the main problem is that there is not enough experience with the system, it misses broad testing and that there are still heaps of packages around which ship init scripts without dependency information. Oh, and fuck you too for the "in simple terms". At this point I would love to hear who you are and why you parade around -devel, giving the impression to be better informed about the preconditions for transitions than the people actually in charge. Marc Footnotes: [1] Either as default for all system or only for fresh installs. -- BOFH #429: Temporal anomaly pgpXQcQYiblfr.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun March 9 2008 17:30:51 Daniel Stone wrote: > [Not subscribed, Cc if you want me to see it.] > > On Sun, Mar 09, 2008 at 01:19:58PM -0800, Mike Bird wrote: > > Ian hijacked his own program back from the people who had been blocking > > updates for six months > > So Ian Murdock would be perfectly entitled to kick out the DAM, DPL, TC, > DSA, and all others to really fix Debian? I think it unlikely that the DAM, DPL, TC, and DSA would block useful updates to Debian for six months while they tried to learn C. Your question is a remote hypothetical. However, in that unlikely event, I would certainly support Ian Murdock if he hijacked Debian to fix it. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On 2008-03-10, Mike Bird <[EMAIL PROTECTED]> wrote: > I think it unlikely that the DAM, DPL, TC, and DSA would block useful > updates to Debian for six months Welcome to real world. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun March 9 2008 18:40:25 Marc 'HE' Brockschmidt wrote: > Mike Bird <[EMAIL PROTECTED]> writes: > > In simple terms: "dpkg triggers" is a highly desirable precondition for > > dependency-based initscripts, but so are several other preconditions, > > not least of which is a substantial test period. The issues are > > well addressed in Frans' posting, the URL of which I have already > > posted once in this thread and will now post again[0]. > > You seem to believe that Frans decides if and when we are going to > switch to a dep-based init system. Your English is much better than my German. Nevertheless either your English is inadequate for the role you are attempting to fill or else you are deliberately trying to provoke an argument. I said that "the issues are well addressed in Frans' posting". That is not an assertion that Frans decides if and when Debian will switch. > Oh, and fuck you too for the "in simple terms". Auf Wiederlesen, --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On 09-Mar-08, 19:30 (CDT), Daniel Stone <[EMAIL PROTECTED]> wrote: > I was going to ask on which grounds exactly you were judging the dpkg > team's competence (and that of iwj's: have you reviewed the branch > yourself? can you confidently say that it's all fine?), The problem is not the dpkg team has reviewed the patch and had problems with it, it's that they've ignored it for 6 months. I don't approve of IanJ's hijack attempt, but in this he's got a legitimate complaint. So do the rest of us who've been waiting for triggers for *years*. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 10:38:44PM -0500, Steve Greenland wrote: > On 09-Mar-08, 19:30 (CDT), Daniel Stone <[EMAIL PROTECTED]> wrote: > > I was going to ask on which grounds exactly you were judging the dpkg > > team's competence (and that of iwj's: have you reviewed the branch > > yourself? can you confidently say that it's all fine?), > The problem is not the dpkg team has reviewed the patch and had problems > with it, it's that they've ignored it for 6 months. That's not the full picture. Ian's been trying to be involved in the dpkg team for longer than six months, and not been incredibly effective at that; eg from July: I will of course be careful about controversial changes. For example, I'll refrain from committing my formatting fixup from #375711 until we've come to a conclusion. I hope you can trust my judgement about what would be a controversial change. -- http://lists.debian.org/debian-dpkg/2007/07/msg00013.html Ian then reposted the triggers spec and published a git tree for the patch, with the following comment: I'd appreciate it if no-one reformatted it or change the style. If you have disagreements with the code please discuss it here on the list before making any changes. Checking a significantly changed version into the main Debian git will cause snarl-ups because our merges will constantly need resolving. -- http://lists.debian.org/debian-dpkg/2007/08/msg00014.html -- http://lists.debian.org/debian-dpkg/2007/08/msg9.html Ian then reimplemented the status file parsing using flex, in a way he reported was faster, but hadn't tested, and suggested it get included in sid. I have written over the weekend a replacement for lib/fields.c and most of lib/parse.c, which uses flex (and flex start conditions) to generate a table-driven scanner-cum-parser. I haven't tested this fully for correctness yet, but I have done basic functionality tests and some performance tests. ... The downside is that it's 100K longer in code size. ... Anyway, I think we should deploy the flex-based scanner in sid (after I've tested it a bit more) and then think at our leisure about how to improve the shared code situation. -- http://lists.debian.org/debian-dpkg/2007/08/msg00028.html Guillem replied to that patch within about four days, but the git tree Ian developed it in was based on the triggers tree, so can't be easily merged independently. In October, Joey proposed his v3 source package format, which is one of the other major outstanding patches. I don't believe it has any stylistic problems, but it still seems to be being reinvented/redisgned, rather than being applied. -- http://lists.debian.org/debian-dpkg/2007/10/msg9.html -- http://lists.debian.org/debian-dpkg/2008/02/msg00012.html http://lists.debian.org/debian-dpkg/2008/02/msg00079.html http://lists.debian.org/debian-dpkg/2008/02/msg00131.html Also in October, Colin Watson asked what the status of triggers was. Ian replied: The implementation of triggers is not going to change incompatibly. It's well-tested now in Ubuntu and should just be merged into Debian's dpkg. -- http://lists.debian.org/debian-dpkg/2007/10/msg00107.html Guillem replied to that: Err, well of course it's highly desirable to not do such kind of changes without good reason, but I don't think the fact that it has been deployed in a derivative distro means that we should blindly merge any such code drops without review and/or possible changes. -- http://lists.debian.org/debian-dpkg/2007/10/msg00132.html Ian replied to that: Don't be ridiculous. This is offensive to me personally. This code has been * designed with extensive input from this mailing list in Debian fora * written by dpkg's original maintainer * tested extensively * available for merging for several months -- http://lists.debian.org/debian-dpkg/2007/10/msg00138.html Guillem didn't reply to that; his next comment on triggers a couple of weeks later was, in response to Ian: > This isn't a matter of preference, I'm afraid. I reverted this > because the change was wrong. NULL is incorrect in that context (a > stdarg function expecting a char*), because it may be #define'd to 0. That's true, but then I agree with others [0] that an environment that defines NULL to 0 (even if the standard allows that) is not sane. Such ancient environment will also not be able to cope with modern software like gtk, anyway. [0] http://lwn.net/Articles/93577/ -- http://lists.debian.org/debian-dpkg/2007/10/msg00228.html There were a couple of messages that sounded promising in regards to a productive conclusion at the end of that month: -- http://lists.debian.org/debian-dpkg/2007/10/msg00230.html -- http://lists.debian.org/debian-dpkg/2007/10/msg00231.html Nothing much happened in Nov or Dec; both Ian and Guillem posted about random oth
Re: dpkg semi-hijack - an announcement (also, triggers)
Petter Reinholdtsen wrote: > I believe your understanding of Frans' position is fairly correct, but > it differ from mine, and I am the one behind the dependency boot > sequencing proposal. I am not convinced yet that triggers are needed, > nor wanted, for dependency boot sequencing. This is partly because I > believe the failure modes Frans mention in his post are unlikely to > happen (or impossible, but it is harder to prove). You are simplifying my reservations to a single point. My main point is that insserv is just way too noisy in general, thereby making upgrades harder to check by sysadmins and downright confusing to less experienced users. insserv's failure modes are IMO extremely non-obvious. > So those of you wanting to test dependency based boot sequencing do > not have to wait for triggers for it to work properly. 80% of the > packages got the dependency headers already, and those already using > it report that it work quite well. :) I do agree that more testing is needed and I'd love to see people basing their opinions on their own experience instead of just trusting either Petter or me. We are talking about a very fundamental function in any installation and changing that in a fundamental way as insserv does deserves a lot more care and review than it is currently getting. Marc 'HE' Brockschmidt wrote: > You seem to believe that Frans decides if and when we are going to > switch to a dep-based init system. That is a completely ridiculous simplification of Mike's mail and also does not do justice to the concerns I raised. I have never said or even implied that implementing insserv should be blocked just because of my concerns. I have only pointed out my concerns to the RMs when I saw a request to elevate something to a standard that IMHO is currently not up to Debian quality. Have you actually tried insserv? Well, I _have_ tested it for about two weeks on my laptop and basically had problems both with the switch and with every upgrade involving init scripts after that. That its maintainer requested elevation of insserv to standard just a few weeks after he announces it ready for testing _and_ getting some non-trivial negative feedback was rather an unpleasant surprise to me. So, until you do try insserv yourself and can actually comment based on experience, please don't dismiss concerns raised by others out of hand. Thanks. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, 09 Mar 2008, Joey Hess wrote: > William Pitcock wrote: > > On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote: > > > And what is the problem exactly? The delay in patch integration? > > If you'd look at submitting patches to dpkg from the perspective of any > recent patch submitter, I'd think that the problem would be clear. For the record William responded publicly to a private message (clearly tagged that way as it started with "private reply" in the first line) and deliberately cut the rest of my answer! Here it is: | And what is the problem exactly? The delay in patch integration? | | I already explained to Ian that Guillem has orphaned other packages to | spend more time on dpkg. We're aware of the lack of manpower but Ian | instead of helping us productively has always had conflictual | relationship with us. :-( (so William Pitcock and Mike Bird are deliberately inflaming the discussions and I'll avoid responding to them in the future and I advise anyone to do the same) BTW, your git source package code is in the sourcev3 branch and I plan to merge that branch before lenny if I don't get distracted too much by all this story. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
* Anthony Towns | In January, Tollef posted about his file exclusion branch, for review. | Guillem did some review and proposed merging it for .17; afaics Ian | couldn't find the git repository at first attempt, then offered to review, | but never did. | |-- http://lists.debian.org/debian-dpkg/2008/01/msg00011.html | http://lists.debian.org/debian-dpkg/2008/01/msg00100.html | http://lists.debian.org/debian-dpkg/2008/01/msg00118.html | http://lists.debian.org/debian-dpkg/2008/01/msg00126.html | http://lists.debian.org/debian-dpkg/2008/01/msg00140.html FWIW (and since my name has been dragged into this thread), the acceptance of that branch is waiting on me actually getting around to addressing the issues pointed out by the dpkg team members (and doing a rebase/squash). My interactions with the dpkg team has mostly been good; I've had to prod for review a couple of times, but nothing unreasonable. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Mike Bird <[EMAIL PROTECTED]> writes: > Your English is much better than my German. Nevertheless either your > English is inadequate for the role you are attempting to fill or else > you are deliberately trying to provoke an argument. My english has its flaws, but I'm usually able to follow a discussion. Now that you mention it, I still have an important question. You may be able to answer it, being a native speaker and author of this line: "the triggers enhancement which is needed for boot time improvements" -- Mike Bird, <[EMAIL PROTECTED]> In what cases is "needed" not having its, ehm, obvious meaning? You seem to suggest that "need" in "I need to breath to live" means "breathing 'is a highly desirable precondition' for living", which to my (German, after all) ears sounds a bit weird. Marc -- BOFH #164: root rot pgp3gxGlJR1yF.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
Frans Pop <[EMAIL PROTECTED]> writes: > Marc 'HE' Brockschmidt wrote: >> You seem to believe that Frans decides if and when we are going to >> switch to a dep-based init system. > That is a completely ridiculous simplification of Mike's mail and also does > not do justice to the concerns I raised. I have never said or even implied > that implementing insserv should be blocked just because of my > concerns. Mike did give that impression, which is what I'm argumenting against. My reply to him was *not* an answer to your concerns, which I find *quite* relevant [1]. My only point in this thread is that the claim "the triggers enhancement which is needed for boot time improvements" is a load of bullshit uttered by someone trying to make a point. Marc Footnotes: [1] The important thing is that I believe that dpkg triggers have *nothing* to do with this switch - if the other (known and unknown) problems with insserv have been resolved, we should do it, no matter if dpkg has triggers or not. -- BOFH #231: We had to turn off that service to comply with the CDA Bill. pgpygkW1ZTxGV.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
Le lundi 10 mars 2008 à 01:45 -0800, Mike Bird a écrit : > Hi Marc, > > "needed" has several similar but distinct meanings. None of the meanings > is more obvious than any other. "Need" I remind you that if you had taken > the time to do the "necessary" homework you could have saved the readers > of this thread the "necessity" of ignoring your post? > > needed[2]: > To want strongly; to feel that one must have something. > > Example: > After ten days of hiking, I needed a shower and a shave. Hi Mike, Another example: After ten days of trolling, the Debian project needs Mike Bird to go to hell. kthxbye, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: dpkg semi-hijack - an announcement (also, triggers)
On Mon March 10 2008 02:08:35 Marc 'HE' Brockschmidt wrote: > In what cases is "needed" not having its, ehm, obvious meaning? You seem > to suggest that "need" in "I need to breath to live" means "breathing > 'is a highly desirable precondition' for living", which to my (German, > after all) ears sounds a bit weird. Hi Marc, "needed" has several similar but distinct meanings. None of the meanings is more obvious than any other. "Need" I remind you that if you had taken the time to do the "necessary" homework you could have saved the readers of this thread the "necessity" of ignoring your post? needed[2]: To want strongly; to feel that one must have something. Example: After ten days of hiking, I needed a shower and a shave. --Mike Bird [2] http://en.wiktionary.org/wiki/need -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Am Montag, den 10.03.2008, 11:24 +0100 schrieb Josselin Mouette: > Le lundi 10 mars 2008 à 01:45 -0800, Mike Bird a écrit : > > Hi Marc, > > > > "needed" has several similar but distinct meanings. None of the meanings > > is more obvious than any other. "Need" I remind you that if you had taken > > the time to do the "necessary" homework you could have saved the readers > > of this thread the "necessity" of ignoring your post? > > > > needed[2]: > > To want strongly; to feel that one must have something. > > > > Example: > > After ten days of hiking, I needed a shower and a shave. > > Hi Mike, > > Another example: > After ten days of trolling, the Debian project needs Mike Bird > to go to hell. > Could all of you now please switch this to private mail? This is debian-devel, neither debian-english-semantics nor debian-kindergarten. Thanks Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
I demand that Marc 'HE' Brockschmidt may or may not have written... [snip] > In what cases is "needed" not having its, ehm, obvious meaning? You seem > to suggest that "need" in "I need to breath to live" means "breathing > 'is a highly desirable precondition' for living", which to my (German, > after all) ears sounds a bit weird. It sounds weird to me too, at least without s/breath to/breathe to/ :-) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Kill all extremists! I'm no stranger, just a friend you haven't met... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, I'd like to clarify few more things, which have been brough up the past few days. Even if I don't usually accept open invitations to flamefests (re the OP). On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote: > On Sun, Mar 09, 2008 at 10:38:44PM -0500, Steve Greenland wrote: > > On 09-Mar-08, 19:30 (CDT), Daniel Stone <[EMAIL PROTECTED]> wrote: > > > I was going to ask on which grounds exactly you were judging the dpkg > > > team's competence (and that of iwj's: have you reviewed the branch > > > yourself? can you confidently say that it's all fine?), > > The problem is not the dpkg team has reviewed the patch and had problems > > with it, it's that they've ignored it for 6 months. > > That's not the full picture. This was a nice summary. > > I don't approve of IanJ's hijack attempt, but in this he's got a > > legitimate complaint. > > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying > his triggers patch dependent on: > > - reversion to two space indenting - reversion of unrelated commits > - a policy of bulk conversion of intentation style, instead of > the current policy of gradual conversion from two-space to > four-space > > - having explicit casts to (char*) of NULL in order to support > some non-Debian architectures - having the commits not split into logical parts - having unrelated features/changes in the same branch > - having the git log not be bisectable or particularly meaningful > except historically > - having Ian be part of the dpkg team The missing changelog entries are actually minor compared to the rest of the problems with the branch. The branch has never been in an acceptable state, it needs cleanup, which Ian has refused to do, repeatedly, and wasted probably more time and everyone's energy starting this (and previous) massive flamefests than what would have taken to just fix it. About rebasing (-i), we've asked for the branch to be rebased as part of the needed cleanup (or any other method which would have resulted in a clean branch or series of patches). He could have kept his existing branch if he so desired, but I don't really see much point in that given that the resulting cleaned up branch would not resemble the original one anyway. One of his excuses was that he had based other feature branches on this one, which is another bad idea, as this was tying unrelated changes together. Also I don't think we'd have insisted on rebasing (even if I personally would prefer so) if the branch would not have been a mess, FWIW, we've merged clean branches before in the team. And I don't really understand this aversion to rebasing a branch that should be pulled from at some point (I'm obviously not talking about the official branches here), most people would find sending messed up patches unacceptable, but not this? > If he hadn't done that, afaict the patch would've been handled pretty > much the way Tollef's was. I've to say, overall, interactions with Ian have been mostly unpleasant, demotivating and confrontational. Not really my definition of "fun". > I don't believe anyone on the dpkg team at any point gave Ian a definite > answer on any of the above issues over the past months; though I doubt > he would have accepted a "no" on any of them anyway. Maybe we've not sent a strong enough message, but there was repeated long conversations, AFAIR, on mail and IRC about how we'd like to see such a branch or series of patches being submitted. Anyway, after the freeze was announced it was clear that Ian was not going to fix the branch, and because having this feature for lenny is highly desirable I was just going to have to fix it myself and review during that process, but got quite sick for a week, during which he started all this mess. I'm back on the clean/split/merge process, and should finish soonish if I don't get distracted by more useless flamefests... Also given that he does not have commit access any longer I'll be taking care of integrating any reasonable change that might be on any of his branches, in the same way we'll be getting eventually at all the remaining patches that are waiting on the BTS. And I'm also quite disappointed with the amount of people that have jumped to conclusions without knowing the context of all this. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi Guillem,
Ian wrote that you recently committed 402 diff lines of stuff
like this:
-static void usage(void) {
+void
+usage(void)
+{
It's easy to see negatives such as making it harder to merge
long-awaited features. What positives do you see for Debian?
--Mike Bird
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi,
On Tue, 2008-03-11 at 22:06 -0700, Mike Bird wrote:
> Hi Guillem,
>
> Ian wrote that you recently committed 402 diff lines of stuff
> like this:
> -static void usage(void) {
> +void
> +usage(void)
> +{
>
> It's easy to see negatives such as making it harder to merge
> long-awaited features. What positives do you see for Debian?
The horse is dead. Stop beating it.
William
signature.asc
Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
Guillem Jover writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> I'd like to clarify few more things, which have been brough up the past
> few days. Even if I don't usually accept open invitations to flamefests
> (re the OP).
Guillem emerges! At last!
The key claim Guillem makes is this:
> The missing changelog entries are actually minor compared to the rest
> of the problems with the branch.
>
> The branch has never been in an acceptable state, it needs cleanup,
He explains what he means by `cleanup' by listing a series of things
that are allegedly wrong with my triggers branch:
> On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote:
> > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying
> > his triggers patch dependent on:
> >
> > - reversion to two space indenting
The history of this change is as follows:
* At some point, without any kind of discussion, Guillem
unilaterally reformats several files to 8-character indents.
* On the *26th of June 2006* I noticed this because it caused
an unnecessary merge conflict while I was trying to do a merge
between the Ubuntu and Debian versions of dpkg.
* I thought it was a mistake because surely no-one would
deliberately change the indent depth in an existing piece of free
software. (A plausible mechanism for the mistake involves an
editor with tab-width set to 2; these kind of things do happen
occasionally.)
* I therefore posted saying to debian-dpkg that this loooked like a
mistake. I also filed a bug, #375711, with a patch to revert the
change.
* On the *30th of May 2007* I got the same merge conflict again in a
later merge. My bug report had gone unanswered. By this point
there is a considerable body of changes in Ubuntu which ought to
be merged into Debian, all of which have the original formatting
as I requested in my bug report.
* So I post to debian-dpkg again and Guillem tells me it was
deliberate.
Since then I have been trying to do as little work as possible. I did
the triggers based on the Ubuntu branch (with the original 2-space
indent) because that was less work since the plan was to deploy it in
Ubuntu first.
Since then it has been a constant source of friction, obviously.
I note that my bug report #375711 hasn't even been closed !
I will admit that my pride has been sorely injured too. I don't
necessarily expect that to be particularly convincing. But this kind
of behaviour from Guillem is just not on.
> - reversion of unrelated commits
> > - having explicit casts to (char*) of NULL in order to support
> > some non-Debian architectures
These two are the same complaint. I note that the dpkg team are quite
happy to add patches to support other operating systems:
76877c6f670321ffdff5f35e879ae1f07a335a46 is a fix which makes dpkg
(a) conform to standards and (b) work on Solaris, but is not necessary
on Linus.
I also reverted one other commit which made a semantic change which I
considered a mistake. After some discussion, new semantics were
agreed and implemented in my branch.
> > - a policy of bulk conversion of intentation style, instead of
> > the current policy of gradual conversion from two-space to
> > four-space
No, my policy is NO CHANGES TO INDENTATION STYLE OR OTHER STYLISTIC
MATTERS
> - having unrelated features/changes in the same branch
> - having the commits not split into logical parts
> > - having the git log not be bisectable or particularly meaningful
> > except historically
This is revlog polishing. Ie a waste of time.
There were no changes in those branches which are not textually
interrelated with triggers and therefore best merged first.
Of course now I have a `master' branch which contains everything.
Historical information is of course the point of revision logs.
> > - having Ian be part of the dpkg team
This is a complete red herring. I only did this in my branch when I
forked after other approaches have failed.
I have of course been discussing the special-purpose triggers branch
that I prepared in August and which I updated to be a fast-forward
from mainline in October. That is what the team should have just
taken.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
William Pitcock writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> On Tue, 2008-03-11 at 22:06 -0700, Mike Bird wrote:
> > It's easy to see negatives such as making it harder to merge
> > long-awaited features. What positives do you see for Debian?
>
> The horse is dead. Stop beating it.
While I don't agree with everything Mike Bird has written and I think
it would be better for him to avoid posting so much:
It would be flogging a dead horse if we didn't have the core packaging
software maintained by an obstructive and naive programmer supported
by someone who is more interested in pretty revision logs than good
code.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Wed, 12 Mar 2008, Ian Jackson wrote: The history of this change is as follows: * At some point, without any kind of discussion, Guillem unilaterally reformats several files to 8-character indents. ... Well, I don't want to interrupt your guys thrilling discussion about indentation of source code and I can not really imagine that you are not aware of apt-cache show indent but isn't it a usual behaviour that a group decides about a certain policy of formatting code and then sticks to it? Just a shy try to calm down from a poor outsider who really wonders how people could flame about whitespaces... Good luck in comming back to a constructive discussion Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Le mercredi 12 mars 2008 à 10:01 +, Ian Jackson a écrit :
> Guillem Jover writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
> > I'd like to clarify few more things, which have been brough up the past
> > few days. Even if I don't usually accept open invitations to flamefests
> > (re the OP).
>
> Guillem emerges! At last!
Did you miss the part where Guillem explained he was sick?
> The key claim Guillem makes is this:
[snip]
The key claim I’d retain from his mail is this one:
I've to say, overall, interactions with Ian have been mostly
unpleasant, demotivating and confrontational. Not really my
definition of "fun".
I guess I can understand what he means after this week’s “discussion”.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: dpkg semi-hijack - an announcement (also, triggers)
On Wed, Mar 12, 2008 at 01:19:58PM +0100, Robert Millan wrote: > > And most importantly, you wouldn't contemplate deploying somewhere else an > implementation of triggers that hasn't been accepted in dpkg, because of the > danger of creating (and maintaining) a sustained incompatibility. Oh wait, I see that you already did. This can be real fun... -- Robert Millan I know my rights; I want my phone call! What use is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Wed, Mar 12, 2008 at 10:01:35AM +, Ian Jackson wrote: > > On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote: > > > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying > > > his triggers patch dependent on: > > > > > > - reversion to two space indenting > > The history of this change is as follows: > * At some point, without any kind of discussion, Guillem > unilaterally reformats several files to 8-character indents. > * On the *26th of June 2006* I noticed this because it caused > an unnecessary merge conflict while I was trying to do a merge > between the Ubuntu and Debian versions of dpkg. > * I thought it was a mistake because surely no-one would > deliberately change the indent depth in an existing piece of free > software. (A plausible mechanism for the mistake involves an > editor with tab-width set to 2; these kind of things do happen > occasionally.) > * I therefore posted saying to debian-dpkg that this loooked like a > mistake. I also filed a bug, #375711, with a patch to revert the > change. > * On the *30th of May 2007* I got the same merge conflict again in a > later merge. My bug report had gone unanswered. By this point > there is a considerable body of changes in Ubuntu which ought to > be merged into Debian, all of which have the original formatting > as I requested in my bug report. > * So I post to debian-dpkg again and Guillem tells me it was > deliberate. > > Since then I have been trying to do as little work as possible. I did > the triggers based on the Ubuntu branch (with the original 2-space > indent) because that was less work since the plan was to deploy it in > Ubuntu first. Formally, you speak of branches we should merge from, but when you merge a branch into trunk, it is the latter that you take as the reference wrt unrelated changes like indentation. It seems to me that the root of the problem is that out of the three branches you mentioned, you didn't really agree on which is the real trunk. If you did, you would have split indentation and triggers in two completely different patches/proposals/discussions (often this is a good idea even if your patches depend on each other; occasionally I've submitted patches that break my own patches [1]). And most importantly, you wouldn't contemplate deploying somewhere else an implementation of triggers that hasn't been accepted in dpkg, because of the danger of creating (and maintaining) a sustained incompatibility. >From my POV, this means you were already challenging Guillem way before starting this thread. [1] for your amusement, this happened to me on dpkg: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355654#10 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440636#5 -- Robert Millan I know my rights; I want my phone call! What use is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Tue March 11 2008 10:45:43 pm Guillem Jover wrote: > Anyway, after the freeze was announced it was clear that Ian was not > going to fix the branch, and because having this feature for lenny is > highly desirable I was just going to have to fix it myself and review > during that process, but got quite sick for a week, during which he > started all this mess. By "fix" you mean rewrite the history, it appears. The end result would be the same either way. I think both you and Ian are making a mountain out of a molehill here. So what if the history isn't pretty? It won't impact anybody running dpkg. It likely won't even impact the people hacking on dpkg. In fact, 2 years hence, I bet nobody cares. Just git merge and be done with it. In the overall picture, it's just not that important. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Ian Jackson wrote:
> William Pitcock writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
>> On Tue, 2008-03-11 at 22:06 -0700, Mike Bird wrote:
>>> It's easy to see negatives such as making it harder to merge
>>> long-awaited features. What positives do you see for Debian?
>> The horse is dead. Stop beating it.
>
> While I don't agree with everything Mike Bird has written and I think
> it would be better for him to avoid posting so much:
>
> It would be flogging a dead horse if we didn't have the core packaging
> software maintained by an obstructive and naive programmer supported
> by someone who is more interested in pretty revision logs than good
> code.
Confrontation is not going to solve this dispute in your advantage, on
the contrary...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Wed March 12 2008 10:26:52 Luk Claes wrote: > Ian Jackson wrote: > > It would be flogging a dead horse if we didn't have the core packaging > > software maintained by an obstructive and naive programmer supported > > by someone who is more interested in pretty revision logs than good > > code. > > Confrontation is not going to solve this dispute in your advantage, on > the contrary... Luk, Please recall that Ian wrote dpkg (replacing Murdock's earlier PERL dpkg). Ian knows dpkg better than any of the current team. If a mini-cabal were senselessly blocking updates to one of my babies because they preferred to spend their time indenting and renaming unused parameters, I would have forked long before six months had elapsed. Ian has shown orders of magnitude more patience than Raphael himself showed in his own dealings with Andreas over developers-reference. Ian appears to have chosen to speak truth to power rather than forking. Do you have a constructive alternative to suggest? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, On Wed, 2008-03-12 at 11:16 -0700, Mike Bird wrote: > Ian appears to have chosen to speak truth to power rather than > forking. Do you have a constructive alternative to suggest? $ echo ":/dpkg/i" >> ~/.killfile William signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
Andreas Tille writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> Well, I don't want to interrupt your guys thrilling discussion
> about indentation of source code and I can not really imagine
> that you are not aware of
> apt-cache show indent
Running indent on an existing body of code is a bad idea.
> but isn't it a usual behaviour that a group decides about a
> certain policy of formatting code and then sticks to it?
This is done at the beginnings of projects precisely to avoid this
kind of nonsense. If I had written a `coding style' document in the
root of the dpkg tree then Guillem would probably have now felt
entitled to just change it.
> Just a shy try to calm down from a poor outsider who really
> wonders how people could flame about whitespaces...
What I'm flaming about is that WE STILL DON'T HAVE TRIGGERS !
The _excuse_ that has been given is that the git log was not pretty
enough and they didn't like the formattting.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
John Goerzen writes ("Re: dpkg semi-hijack - an announcement (also, triggers)"):
> I think both you and Ian are making a mountain out of a molehill here. So
> what if the history isn't pretty? It won't impact anybody running dpkg. It
> likely won't even impact the people hacking on dpkg. In fact, 2 years
> hence, I bet nobody cares. Just git merge and be done with it.
That's what I did, in Augustt and in October. The third time I did
it I uploaded the result. It got unaccepted because the dpkg team are
more interested in blocking.
I'm not sure how I'm making a mountain out of a molehill.
I'm complaining that Guillem and Raphael have refused for 6 months to
take my code because of complaints which are both trivial and wrong.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Wed, 12 Mar 2008 07:58:15 -0600, John Goerzen <[EMAIL PROTECTED]> wrote: >I think both you and Ian are making a mountain out of a molehill here. So >what if the history isn't pretty? It won't impact anybody running dpkg. It >likely won't even impact the people hacking on dpkg. In fact, 2 years >hence, I bet nobody cares. Just git merge and be done with it. > >In the overall picture, it's just not that important. Right. But currently, this has a good chance to keep Triggers out of lenny, which is a bloody shame. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: dpkg semi-hijack - an announcement (also, triggers)
Le Thursday 13 March 2008 15:32:18 John Goerzen, vous avez écrit : > > Right. But currently, this has a good chance to keep Triggers out of > > lenny, which is a bloody shame. > > I understand, which is my point. People need to get a sense of > perspective. What is the more important goal: triggers in lenny or a > pretty git history? I think I didn't see it on this discussion, but there is also the risk of a factual fork of dpkg between Ubuntu and Debian, and that would even be worse.. To both.. Romain -- We are reincarnated souls from that time, Living on earth, heat, air and water in dis ya time.
Re: dpkg semi-hijack - an announcement (also, triggers)
On Thu March 13 2008 8:34:19 am Marc Haber wrote: > On Wed, 12 Mar 2008 07:58:15 -0600, John Goerzen > > <[EMAIL PROTECTED]> wrote: > >I think both you and Ian are making a mountain out of a molehill here. > > So what if the history isn't pretty? It won't impact anybody running > > dpkg. It likely won't even impact the people hacking on dpkg. In fact, > > 2 years hence, I bet nobody cares. Just git merge and be done with it. > > > >In the overall picture, it's just not that important. > > Right. But currently, this has a good chance to keep Triggers out of > lenny, which is a bloody shame. I understand, which is my point. People need to get a sense of perspective. What is the more important goal: triggers in lenny or a pretty git history? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
* Mike Bird | Please recall that Ian wrote dpkg (replacing Murdock's earlier | PERL dpkg). Ian knows dpkg better than any of the current team. Ian had one upload of dpkg after September 1996, which was in 1998 before he suddenly regained interest in it about a year or so ago. I'm not questioning his motives, I am just pointing out that iwj maintained it for about two out of its fourteen-year life. Calling the project Ian's and implying that he has a god-given right to take back dpkg because he first wrote it is just silly. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Wed, 2008-03-12 at 10:01:35 +, Ian Jackson wrote:
> Guillem Jover writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
> > On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote:
> > > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying
> > > his triggers patch dependent on:
> > >
> > > - reversion to two space indenting
I seems I'll need to clarify this as well, as it's not correct, and has
been brought somewhere else... The rest has already been explained
several times, and I don't think there's any need to be repetitive.
> The history of this change is as follows:
> * At some point, without any kind of discussion, Guillem
> unilaterally reformats several files to 8-character indents.
This is not correct. The changes referred to in bug 375711 were
introduced when:
Wichert reindents configure.c:
<http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=1b7b5f21>
Initial version by Wichert of showpkg.c:
<http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=54cc8a5f>
New function by Fumitoshi Ukai in archives.c:
<http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=520ad305>
Initial version of tarfn.c (git history does not go further and the
ChangeLog is not detailed enough, from the header I assume it was
Bruce Perens):
<http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=1b80fb16>
> * On the *26th of June 2006* I noticed this because it caused
> an unnecessary merge conflict while I was trying to do a merge
> between the Ubuntu and Debian versions of dpkg.
I doubt actually this caused any merge conflict, given that those files
had been this way for a long long time.
> * I thought it was a mistake because surely no-one would
> deliberately change the indent depth in an existing piece of free
> software. (A plausible mechanism for the mistake involves an
> editor with tab-width set to 2; these kind of things do happen
> occasionally.)
It does not matter if it was a mistake or not, this kind of change
should have never landed in any unrelated non-official branch mixed
with other stuff. And I disagree that no one would want to change
coding style as I explained in:
<http://lists.debian.org/debian-dpkg/2007/05/msg00086.html>
> * I therefore posted saying to debian-dpkg that this loooked like a
> mistake. I also filed a bug, #375711, with a patch to revert the
> change.
> * On the *30th of May 2007* I got the same merge conflict again in a
> later merge. My bug report had gone unanswered. By this point
> there is a considerable body of changes in Ubuntu which ought to
> be merged into Debian, all of which have the original formatting
> as I requested in my bug report.
The patch in that bug had been partially applied (explained at [0]):
<http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=b31f79e7>
And I guess at this point I should have just closed the bug, but this
was a continuos source of conflict, so leaving it open seemed to be
the less annoying.
I disagree with the rest of the patch[1], which was also wrong (due to
the resulting mixed indentantion), as I explained at:
[0] <http://lists.debian.org/debian-dpkg/2007/08/msg6.html>
[1]
<http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=diff;att=1;bug=375711>
> * So I post to debian-dpkg again and Guillem tells me it was
> deliberate.
I said in [0] that "I think that those changes were done on purpose".
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Fri, Mar 14, 2008 at 06:14:26AM +0200, Guillem Jover wrote: > I seems I'll need to clarify this as well To be honest, I'd love to see you ignore this entire thread if it means you'll spend time whipping the triggers stuff into whatever shape you think it needs to be in to go into sid. Perhaps you and Ian can decide on an intermediary who knows the dpkg code base and can help get this done? Simon. -- Think of me as CVS with a brain and with some taste. - Linus Torvalds signature.asc Description: Digital signature
