[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: