Re: dehs will stop
[Why to cc on policy? Cut] On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote: 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 didn't. Just change the content of this mail into one of the pages of your site, and you're set. 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. So, you got the way to go. Please go ahead and submit those 6229 bugs. Providing a patch *is* an alternative method. We did the same sort of wishlish bug mass filling with the transition from raw debconf to po-debconf. We had less packages to bug, though. It represents an insane amount of work, but it's the way to go, I guess. What's useless is to fill the bug without the patches, but if you write the watch file for the people, nobody should complain. Good luck, Mt. signature.asc Description: Digital signature
Re: dehs will stop
On Sun, Mar 06, 2005 at 10:49:47AM +0100, Martin Quinson wrote: [Why to cc on policy? Cut] On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote: 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 didn't. Just change the content of this mail into one of the pages of your site, and you're set. 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. So, you got the way to go. Please go ahead and submit those 6229 bugs. NO! Do *not* file 6229 bugs about the same subject. Never. Adding a watchfile is up to the maintainer. It's a feature offered to maintainers, they can use it if the wish. If a watchfile for a package makes sense (for quite some packages it doesn't) I think it's useful. In no case should 6229 bugs be filed about these watchfiles that don't have ANY effect on the resulting binary packages. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: dehs will stop
Jeroen van Wolffelaar wrote: [snip] 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. So, you got the way to go. Please go ahead and submit those 6229 bugs. NO! Do *not* file 6229 bugs about the same subject. Never. Why not? As wishlist bugs with patch this seems sensible to me. Adding a watchfile is up to the maintainer. It's a feature offered to maintainers, they can use it if the wish. If a watchfile for a package makes sense (for quite some packages it doesn't) I think it's useful. If upstream doesn't publish tarballs, e.g. In this case there won't be a meaningful patch for a watchfile. In any case it's up to the maintainer to decide about its inclusion. I believe most of them will accept such a patch. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
su, 2005-03-06 kello 19:28 +0100, Thiemo Seufer kirjoitti: Jeroen van Wolffelaar wrote: Do *not* file 6229 bugs about the same subject. Never. Why not? As wishlist bugs with patch this seems sensible to me. Denial of service attacks on the bug tracking system, on mailing lists, mail servers, and maintainers is unappreciated. 6229 bug reports would result in all sorts of unnecessary and unwanted load on all sorts of systems and people. It is because of reasons like these that mass-filing of bugs must always be discussed on debian-devel beforehand, so that the utility of the bug reports can be weighed against the load and disruption they cause. In this situation, I think it is clear that filing 6229 *wishlist* bugs is completely unwarranted. If upstream doesn't publish tarballs, e.g. In this case there won't be a meaningful patch for a watchfile. In any case it's up to the maintainer to decide about its inclusion. I believe most of them will accept such a patch. Having the watch information in the package means the information becomes stale: when the package is part of a Debian release the watch information won't get updated when the upstream web site moves, or the download URL changes, or whatever. Having a centralized database (say, part of package.debian.org) allows that information to be updated centrally, continuously, and also without disturbing a thousand developers with it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
Re: Thiemo Seufer in [EMAIL PROTECTED] Do *not* file 6229 bugs about the same subject. Never. Why not? As wishlist bugs with patch this seems sensible to me. I assume that you will hand-check the patches in those 6229 bug reports that the watch files actually do the right thing before you submit the reports? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: dehs will stop
Christoph Berg wrote: Re: Thiemo Seufer in [EMAIL PROTECTED] Do *not* file 6229 bugs about the same subject. Never. Why not? As wishlist bugs with patch this seems sensible to me. I assume that you will hand-check the patches in those 6229 bug reports that the watch files actually do the right thing before you submit the reports? How else could it be a useful patch? Btw, I'm not volunteering for that task. Thiemo signature.asc Description: Digital signature
Re: dehs will stop
Lars Wirzenius wrote: su, 2005-03-06 kello 19:28 +0100, Thiemo Seufer kirjoitti: Jeroen van Wolffelaar wrote: Do *not* file 6229 bugs about the same subject. Never. Why not? As wishlist bugs with patch this seems sensible to me. Denial of service attacks on the bug tracking system, on mailing lists, mail servers, and maintainers is unappreciated. 6229 bug reports would result in all sorts of unnecessary and unwanted load on all sorts of systems and people. Since preparation of the accompanying patches would take some time, it is unlikely to cause denial of service or disruption. [snip] If upstream doesn't publish tarballs, e.g. In this case there won't be a meaningful patch for a watchfile. In any case it's up to the maintainer to decide about its inclusion. I believe most of them will accept such a patch. Having the watch information in the package means the information becomes stale: when the package is part of a Debian release the watch information won't get updated when the upstream web site moves, or the download URL changes, or whatever. Yes, it adds some (small) maintenance burden. Having a centralized database (say, part of package.debian.org) allows that information to be updated centrally, continuously, and also without disturbing a thousand developers with it. Do you really expect such a centralized database would be updated more consistently? By whom? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
su, 2005-03-06 kello 20:11 +0100, Thiemo Seufer kirjoitti: Since preparation of the accompanying patches would take some time, it is unlikely to cause denial of service or disruption. If they are sent at a slow pace, then the disruption is less, it is true. It is still detrimental to have thousands upon thousands of wishlist bugs for something like this. We don't have lintian report bugs for all the errors it finds for the same reason (well, one of the reasons): the volume would be too much. Increasing the number of open bugs in Debian with 10-20% just for watch files, or any other non-critical issue, is not a good idea. Yes, it adds some (small) maintenance burden. In case it was unclear: I am not talking about the burden on the package maintainer, that is small enough to not worry about. I am talking about information that will not be updated at all, even if the package maintainer wants it to be updated and provides a new package with the new information. There is no point in flooding a Debian stable release with new package versions that merely change a watch URL. Having a centralized database (say, part of package.debian.org) allows that information to be updated centrally, continuously, and also without disturbing a thousand developers with it. Do you really expect such a centralized database would be updated more consistently? By whom? Given that the distributed version won't be updated at all, there is a chance that a centralized database will be more up to date. Making it easy to update by, for example, providing a simple web interface that lets any DD log in and update any watch url should make it pretty likely that it actually happens. If Wikipedia can do it for tens of thousands of articles, surely we can do it for a few thousand URLs. (Or you can lobby for a virtual package in the bug tracking system and have people write bug reports when they notice a broken URL, and have a team dedicated to checking the URLs and updating the database. Or have a mail bot a la the one for db.debian.org. Or a structured wiki site.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
On Sun, Mar 06, 2005 at 06:44:37PM +0100, Jeroen van Wolffelaar wrote: On Sun, Mar 06, 2005 at 10:49:47AM +0100, Martin Quinson wrote: On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote: 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. So, you got the way to go. Please go ahead and submit those 6229 bugs. NO! Do *not* file 6229 bugs about the same subject. Never. Adding a watchfile is up to the maintainer. It's a feature offered to maintainers, they can use it if the wish. If a watchfile for a package makes sense (for quite some packages it doesn't) I think it's useful. In no case should 6229 bugs be filed about these watchfiles that don't have ANY effect on the resulting binary packages. Erm. You did cut what I said, ie, that if someone wants to write the few thousands missing watch files and provide them as wishlist bug, I'd say that they should proceed. People not wanting of those watch files can always mark the bug wontfix if it's a political opinion, or close the bug if it does not make any sense in their case. Of course, mass bug filling saying please do the job I'd like to see done is never a solution. That's not what I proposed. That's not what we did for the po-debconf transition. And hoping that maintainers are perfect and will write everybit of the needed infrastructure alone is a dream. I welcome any transversal help offer. That's QA job, and that's good, IMHO. Thanks, Mt. signature.asc Description: Digital signature
Re: dehs will stop
Lars Wirzenius [EMAIL PROTECTED] writes: Denial of service attacks on the bug tracking system, on mailing lists, mail servers, and maintainers is unappreciated. 6229 bug reports would result in all sorts of unnecessary and unwanted load on all sorts of systems and people. It is because of reasons like these that mass-filing of bugs must always be discussed on debian-devel beforehand, so that the utility of the bug reports can be weighed against the load and disruption they cause. In this situation, I think it is clear that filing 6229 *wishlist* bugs is completely unwarranted. Wouldn't it be a lot easier, if there is consensus that having a watch file is the right thing to do, to add it as a lintian warning? That seems like a far lower-impact way of notifying 6,229 package maintainers. One problem with either approach (although somewhat less so for filing bugs if someone is carefully hand-checking each one) is that there are packages in Debian that are based on an upstream release that's completely dead or unsuitable for further tracking for some reason. For such packages, the watch file is actually counter-productive, since it implies some ongoing relationship to the original upstream release that isn't accurate. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
Lars Wirzenius wrote: su, 2005-03-06 kello 20:11 +0100, Thiemo Seufer kirjoitti: Since preparation of the accompanying patches would take some time, it is unlikely to cause denial of service or disruption. If they are sent at a slow pace, then the disruption is less, it is true. It is still detrimental to have thousands upon thousands of wishlist bugs for something like this. Why? Could you provide a rationale for this assertion? We don't have lintian report bugs for all the errors it finds for the same reason (well, one of the reasons): the volume would be too much. We don't talk about automated bug filing here. If somebody writes patches to fix (valid) lintian problems it is IMHO clearly legitimate to file that as a wishlist bug. Of course there are bogus Lintian triggers, this needs to be taken into account. (Btw, I somehow doubt the volume of such bugs will become a problem anytime soon. Simply because there aren't that many people motivated to fix such stuff.) Increasing the number of open bugs in Debian with 10-20% just for watch files, or any other non-critical issue, is not a good idea. Yes, it adds some (small) maintenance burden. In case it was unclear: I am not talking about the burden on the package maintainer, that is small enough to not worry about. I am talking about information that will not be updated at all, even if the package maintainer wants it to be updated and provides a new package with the new information. Why would it be impossible for the maintainer to update the watchfile in his package? There is no point in flooding a Debian stable release with new package versions that merely change a watch URL. Such changes aren't acceptable for a stable release anyways. It would make as much sense as trying to update maintainer addresses in stable source packages. And, just to point out the obvious, watch files are supposed to help with development of new versions of a package. There's simply no point to care about them aside from the one in the newest package. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
su, 2005-03-06 kello 21:09 +0100, Thiemo Seufer kirjoitti: We don't talk about automated bug filing here. We're talking about filing over 6000 bugs for watch files. It may not be automated, but it is mass-filing. It doesn't matter if it takes weeks or months, it is still not a good idea. That is what I am primarily objecting to, and what I understand Jeroen also to be objecting to. Since there is no consensus, as far as I can see, that putting watch files into packages is a good thing, mass-filing bugs is a really bad idea. If somebody writes patches to fix (valid) lintian problems it is IMHO clearly legitimate to file that as a wishlist bug. Of course there are bogus Lintian triggers, this needs to be taken into account. Fixing packages one by one is not mass-filing bugs. Why would it be impossible for the maintainer to update the watchfile in his package? Getting the updated package into stable is the point. And, just to point out the obvious, watch files are supposed to help with development of new versions of a package. There's simply no point to care about them aside from the one in the newest package. Packages in stable may be missing from unstable, or have a different name in unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
On Mon, 2005-02-28 at 03:32 +0100, Bluefuture wrote: snip 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: snip If you're not a developer and you want to post on d-d-a, you need to find a sponsor just like with packages. As long as the message is signed by someone in the keyring, it should go through. Cheers, Pasc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dehs will stop
After another gruelling discussion on #debian-devel about the useless of dehs and the lack of watch file (75,60% of non native debian packages doesn't had one), I think that dehs is start to begin only my own personal toys, so i'm thinking to stop it and to leave alioth resources and put my development effort on something more useful to the community. I know that there are a little bit group of people that think that the old use of watch file could be converted in a Qa tools, but actually i'm the only one that is trying to find a solution that could fix that lack of watch file. But without maintainers interest, the project still lack in an usable status. There is no reason to put more work and effort on a community tool that community itself consider useless. I hope that something could change. But i don't belive it. Cheers, Stefano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
Hi Stefano, Bluefuture wrote: I know that there are a little bit group of people that think that the old use of watch file could be converted in a Qa tools, but actually i'm the only one that is trying to find a solution that could fix that lack of watch file. But without maintainers interest, the project still lack in an usable status. There is no reason to put more work and effort on a community tool that community itself consider useless. I hope that something could change. But i don't belive it. I know that I thougt dehs per se not too useful, but the watch section on qa.d.o has inspired me to write watch files for two of my packages. Not much (2 out of 7), admittedly, but I think that it's fairly useful. I think the experimental columns are overkill (as people packaging experimental stuff probably monitor upstream releases even more closely). If 25% of the packages can be watched, hey, that's a fair share. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
This one time, at band camp, Thomas Viehmann said: Hi Stefano, Bluefuture wrote: I know that there are a little bit group of people that think that the old use of watch file could be converted in a Qa tools, but actually i'm the only one that is trying to find a solution that could fix that lack of watch file. But without maintainers interest, the project still lack in an usable status. There is no reason to put more work and effort on a community tool that community itself consider useless. I hope that something could change. But i don't belive it. I know that I thougt dehs per se not too useful, but the watch section on qa.d.o has inspired me to write watch files for two of my packages. Not much (2 out of 7), admittedly, but I think that it's fairly useful. I think the experimental columns are overkill (as people packaging experimental stuff probably monitor upstream releases even more closely). If 25% of the packages can be watched, hey, that's a fair share. Just my 2 cents, but I agree - only two of my packages have useful (and really, alive) upstreams, so they are the only ones with watch files. That doesn't mean it's unhelpful though - it alerted me to a new hdparm before I would otherwise have known. Thanks for your efforts. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpgdWtIXcxQ7.pgp Description: PGP signature
Re: dehs will stop
Scripsit Bluefuture [EMAIL PROTECTED] There is no reason to put more work and effort on a community tool that community itself consider useless. 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? -- Henning MakholmNu kommer han. Kan du ikke høre knallerten?
Re: dehs will stop
I know that I thougt dehs per se not too useful, but the watch section on qa.d.o has inspired me to write watch files for two of my packages. Not much (2 out of 7), admittedly, but I think that it's fairly useful. I think the experimental columns are overkill (as people packaging experimental stuff probably monitor upstream releases even more closely). If 25% of the packages can be watched, hey, that's a fair share. Are we still talking around dehs as a personal developer tool? Is It a so hard work to add this watch file, only as an example for some of your package i had built it in some minutes: xml2 version=2 http://download.ofb.net/gale/xml2-([\d\.]+)\.tar\.gz xtermset -- version=2 ftp://ftp2.sf.net/pub/sourceforge/c/cl/clts/xtermset-([\d\.]+)\.tar\.gz ferm --- version=2 http://ferm.sourceforge.net/ferm-([\d\.]+)\.tar\.gz If we still think to fix watch file only for application that we doesn't strictly follow this will not help dehs. You must fill every file watch for everyone of your package that had a valid upstream and acessible repo. We all know naturally some exceptions like only as example if there aren't available tarball releases/snapshot but u build your package from cvs/svn/arch. Tanks, Stefano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
Scripsit Bluefuture [EMAIL PROTECTED] 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. You are entitled to believe that the idea is not good. In that case, I wish you the best of luck. I'm not a debian developer, so i could not post on dda mailing list. How does not being a DD stop you from giving explanations elsewhere? Your postings give me the impression that you have control of the contents of dehs.alioth.d.o. Why do you not make that page link to an introduction and explanation before you complain that people cannot guess what would be there if you had bothered to write it? The only reply are: 1) Dehs is useless. 2) Submitting 6229 wishlist bug is not possible/is not the solution (without proposing alternatives method) Now you have a third reply: Explain why people should care, and someone might actually start caring. -- Henning Makholm Det nytter ikke at flygte der er henna overalt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
On 02/27/2005 11:15 PM, Henning Makholm wrote: Now you have a third reply: Explain why people should care, and someone might actually start caring. The core idea of dehs (as I understand it) is to keep track of differences between the current upstream and Debian package versions. In the long run dehs is intended to gather and present more information than just the numerical version difference. Upstream changelog fragments, bug reports or NEWS, can be easily inspected (in one place) to check what upstream has done and is not yet available in a Debian package. The system can also be used spot MIA developers, long forgotten package, etc. The watch file (which is a configuration file for a personal developer tool) is useful to start gathering this information. To a small group it would be a big effort to define the gathering sources for dehs for all packages, for a maintainer its almost trivial to write a watch file for his own packages. Should people care about this? Well... People should care if the packages lag behind upstream. Good maintainers will care and will build a new package when upstream releases or will have a good reason not to do so (and there are a couple of good reasons for this). Should Debian care about a system like dehs? Considering the effort maintainers have to do (adding a watch file) I think its worth it. Debian has a high commitment to QA and having a big picture of the state of upstream/package versions could be useful. K. -- Lucas Wall [EMAIL PROTECTED] .''`. Buenos Aires, Argentina: :ø : Debian GNU/Linux http://www.kadath.com.ar `. `' http://www.debian.org PGP: 1024D/84FB46D6 `- 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: dehs will stop
Scripsit Lucas Wall [EMAIL PROTECTED] On 02/27/2005 11:15 PM, Henning Makholm wrote: Now you have a third reply: Explain why people should care, and someone might actually start caring. The core idea of dehs (as I understand it) is to keep track of [snip explanation] But why did I have to ask to get that information? Why wasn't it included in the intial gripe about people not writing watch files, or at least linked to? Why is it not available on the Dehs website itself? I do not think it is justified to complain it annoys me that people do not do X without at least referencing a place where people can learn why they should do X. -- Henning Makholm Nemo enim fere saltat sobrius, nisi forte insanit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
On 02/28/2005 01:08 AM, Henning Makholm wrote: Scripsit Lucas Wall [EMAIL PROTECTED] On 02/27/2005 11:15 PM, Henning Makholm wrote: Now you have a third reply: Explain why people should care, and someone might actually start caring. The core idea of dehs (as I understand it) is to keep track of [snip explanation] But why did I have to ask to get that information? Why wasn't it included in the intial gripe about people not writing watch files, or at least linked to? Why is it not available on the Dehs website itself? I do not think it is justified to complain it annoys me that people do not do X without at least referencing a place where people can learn why they should do X. I can't answer this. I don't know why this explanation is not included in the dehs web page, or why it wasn't mentioned with the original post. Now that you have this information, do you think dehs could be useful? Do others think something like dehs could be useful? K. -- Lucas Wall [EMAIL PROTECTED] .''`. Buenos Aires, Argentina: :ø : Debian GNU/Linux http://www.kadath.com.ar `. `' http://www.debian.org PGP: 1024D/84FB46D6 `- 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: dehs will stop
On Mon, Feb 28, 2005 at 01:35:40AM -0300, Lucas Wall wrote: Now that you have this information, do you think dehs could be useful? Do others think something like dehs could be useful? As a general tool? Maybe, but how is it better than uscan, which it duplicates? As a website? No, not really. It's slow and doesn't present any views on the information that are particularly useful and it's completely immune to shell scripting. A web interface would appear to be the wrong way to do this. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: dehs will stop
On 02/28/2005 02:02 AM, Andrew Suffield wrote: On Mon, Feb 28, 2005 at 01:35:40AM -0300, Lucas Wall wrote: Now that you have this information, do you think dehs could be useful? Do others think something like dehs could be useful? As a general tool? Maybe, but how is it better than uscan, which it duplicates? Probably dehs would not be a replacement to uscan. People don't even need to use uscan to track upstream. What dehs could offer is a consolidated source of information and a big picture. It can also be a source for information you don't directly handle or would be dispersed and hard to harvest around the net. As a website? No, not really. It's slow and doesn't present any views on the information that are particularly useful and it's completely immune to shell scripting. A web interface would appear to be the wrong way to do this. Agreed. Maybe dehs could provide information in a more shell friendly way. The web pages could just be a pretty view, used for occasional checks or big pictures viewing. K. -- Lucas Wall [EMAIL PROTECTED] .''`. Buenos Aires, Argentina: :ø : Debian GNU/Linux http://www.kadath.com.ar `. `' http://www.debian.org PGP: 1024D/84FB46D6 `- 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: dehs will stop
On Mon, Feb 28, 2005 at 12:54:46AM -0300, Lucas Wall wrote: The core idea of dehs (as I understand it) is to keep track of differences between the current upstream and Debian package versions. In the long run dehs is intended to gather and present more information than just the numerical version difference. Upstream changelog fragments, bug reports or NEWS, can be easily inspected (in one place) to check what upstream has done and is not yet available in a Debian package. This is a rather blue sky goal, given how much of a mixed bag upstream changelogs are... Doesn't seem to justify making a fuss over getting watch files into all packages, when there are so many real, reported, user-affecting bugs outstanding? The system can also be used spot MIA developers, No, it can't: neither package out-of-dateness nor infrequency of upload is a criterion for being considered MIA, nor should they be. This is simply not a good indicator of whether the package is being well-maintained. long forgotten package, etc. Can't you tell that much more easily by looking at the datestamp of the most recent upload, instead of trying to get maintainers who may already be MIA to add files to their packages before you can get any statistics? Should people care about this? Well... People should care if the packages lag behind upstream. Why? Good maintainers will care and will build a new package when upstream releases or will have a good reason not to do so (and there are a couple of good reasons for this). Good maintainers understand that QA is more than just getting the latest and greatest version of the package into the archive... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
