>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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
