Re: dehs will stop
>The community might start considering it less useless if an
>explanation of what it is supposed to be good for was actually
>available. In particular, why should a maintainer care about watch
>files if he uses something else than uscan to keep track of upstream
>happenings?
>From time to time, these little microthreads start on d-d where
>somebody complains that so and so many packages do not have watch
>files, but it seems always to be left entirely to the reader's
>imagination to figure out why that is apparently a bad thing.
>If I go to, say, <http://dehs.alioth.debian.org/> in search of
>information, I find not a single word of purpose or rationale.
>The only places I can see watch files mentioned in our general
>"required reading" documentation (twice in NM-guide and once in
>dev-ref), they are presented exclusively as a maintainer convenience
>tool.
>If people don't care as much about this as you think they should,
>perhaps it would be a good idea to try explaining why they *should*
>care, instead of just lamenting their lack of a telepathic
>understanding of your intentions?
This is not true. Had u tried to do a search about dehs/watch on debian-devel about 2004/2005?
I'm not a debian developer, so i could not post on dda mailing list. I
had opened many thread over this months on debian-qa debian-devel about
dehs issues. The only reply are:
1) Dehs is useless.
2) Submitting 6229 wishlist bug is not possible/is not the solution
(without proposing alternatives method)
I had try to randomly submit wishlist bugs for 6 packages to bts with
the tag "patch" pointing to the dehs site or attaching the watch file to
the bug.
Almost all of this bug was closed and the watch file was check (in some
cases fixed) and inserted in the package on the next upload.
If the watch file is well done - preferring ftp and http download
address instead of html pages - dehs try to catch in his archive also
the UPSTREAM changelog/news as you can see here[2] clicking on the
upstream version.
So we (all other user and developer that doesn't maintain the package)
can check features and upstream bugs fixed in the new
usptream release and the upstream bugs that we still had in debian and
features we doesn't had for packages that are not in sync with upstream
version or that ones that the maintainer had not packaged for more then
one
release.
So we can start to check things like maintainer activity, vacation, mia,
see if the maintainer is simple too busy (we will could add in future in
dehs archive the upstream release date field and the debian package
upload date - for this task we need some collaboration from the uscan
developer). Then after this check, if we doesn't had a clear situation
about the upstream we could email to the maintainer what is the problem
about packaging the new version (if months has passed from the upstream
release and the maintainer doesn't has prepared uploaded the package in
debian).
We could have for reply that the new release is not in a good
and stable shape, or that he need a library not already packaged in
debian etc. etc.
I think that also monitoring upstream bugs fixed, and new feature we
could make a better distro and not only fixing bugs and put in an
harmonic shape all the packages
in debian but also getting what the upstream authors offer to debian and
to the all the linux distros with his upstream releases and development
work.
[1] http://dehs.alioth.debian.org/no_updated.html
Reply to: