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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140210200606.gh14...@an3as.eu
