Bug#736760: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[Andreas Tille]

Hi David,

On Mon, Feb 10, 2014 at 03:37:54PM -0400, David Prévot wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Le 10/02/2014 08:36, Andreas Tille a écrit :
> 
> > I wonder in how far it is to late for debian/watch and not for the file
> > debian/upstream.  Yey, I'm aware that we have two to three orders of
> > magnitude more debian/watch files than debian/upstream files
> 
> I’m not sure were you got those numbers, but it seems there are far more
> debian/watch files than debian/upstream files in the archive (way more
> than three times). Can somebody please enlighten us with factual numbers?

Sure way more than three times.  We have >200 debian/upstream files and
>20000 debian source packages with probably the majority featuring watch
files.  This makes O(2) (about 10^2 times) more debian/watch files.  If
you mind exact numbers feel free to query UDD.

BTW, usually - at least inside packages - name conflicts are dealt
according to a first comes first served rule.  I wonder why in this case
some (unspecified) number should be needed.
 
> >> That said I also agree that this change is mainly a matter of coherence
> >> and esthetics and thus should not break anything and thus everything
> >> should support both locations for a long period of time.
> > 
> > Seems we all agree on the esthetics issue but I for myself would think
> > that *if* we go for esthetics than we should make this strict and
> > complete or not at all.  Otherwise I see no point in wasting developer
> > time for half baken things.
> 
> It seems a bit irrelevant to force hard conditions to improvements:
> moving the very young debian/upstream file to a more accurate
> debian/upstream/$metadata

Could you please name any measure of accurateness which proves that

    debian/upstream/signing-key.pgp

is more accurate than

    debian/upstream-signing-key.pgp

Please do not mix up some esthetical feeling with accurateness.  Again,
I agree with the esthetics argument but simply pushing a change that
breaks other people's system is something I would call inaccurate.

> place should not be conditioned to moving the
> “very old” and already highly used debian/watch file to the same
> directory. If we could first agree on debian/upstream/ being the right
> place for upstream related data/files, then it would make sense to
> discuss and propose a plan to move the watch file there too (but can we
> please have this other discussion if/once we agree on a common directory
> first).

I would really have loved to have a discussion first, yes.  But there
was none.

> If I understood correctly, the DEP-12 metadata file is used by a pair of
> tools, and James started to propose patches to support both paths in
> order to allow a smooth transition. So the technical issue could be
> considered (being) taking care of.

The historic fact is that James was ignoring DEP-12 perfectly in the
first place and his patch only covers a slight part of the tools around.
I do not say that this patch is not welcome - to the contrary I really
appreciate James' effort to support his change.  I just think that it is
simply wrong to ignore and by doing so undermine any DEP.

> If I understood correctly, the following step would be to move (in the
> packages’ VCS) one file to its new path. Considering most of the
> concerned packages may be team-maintained, I’d be happy to offer my
> hands in order help this transition and (momentarily) join the relevant
> teams to (help and) do this not rewarding job.

Thanks.  Any helping hand is welcome.  I simply want to make sure that
the thing you are proposing will be really sustainable in the first
place.  The only problem I have with this issue is that changes like
this should have some agreement first and this is what a DEP is about.
Otherwise DEPs are pointless and we could stop using this method. 

If you ask me I would consider #736760 is something the TC should decide
upon.  However, they have currently more important stuff to do and thus
I would really welcome if we start discussing like real man (=respecting
each others work), work out a sustainable plan what should be done in
debian/upstream in the long term and do the change *afterwards*.

Kind regards

        Andreas.

-- 
http://fam-tille.de