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 <Diziet> 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 <Mithrandir> (at this point), I believe?
22:17 <buxy> 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.
Reply to: