Bug#543990: It should not but it is
On Sun, Aug 30, 2009 at 02:16:26AM +0200, Francisco Moya wrote: On Sat, Aug 29, 2009 at 12:17 PM, Aurelien Jarno aurel...@aurel32.netwrote: I don't understand why you insist on hiding this discussion in all your emails. It looks like you are not confident with you opinion. Since when are the discussions of debian-devel hidden? Since when talking about the Debian policy and upstream release policies is a problem? debian-devel is not hidden. But private emails and debian-private, as *you suggested*, are. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543990: It should not but it is
tags 543990 +pending thanks On Sun, Aug 30, 2009 at 4:06 AM, Ana Guerrero a...@debian.org wrote: Dear Francisco and Cleto (I expect), [...] By the way, it is not your package, but since you are the sponsor, I understand you feel resposible about it, which is quite fine. Indeed, a serious violation of the policy would be my responsibility. On Fri, Aug 28, 2009 at 11:22:08PM +0200, Francisco Moya wrote: I must have missed something. What is wrong in my statements? What file is rejected by Debian and why? What in this package contradicts the debian policy? I not only mean the letter of the DP but also the rationale behind it. What is wrong with this particular package given that ows is in Debian till 2007 and nobody complained? Since you do not quote here what you are answering, I am not sure at all what are you answering. It is usually nice quote exaclty what you are answering, it is one of the problems I have found to follow and understand you correctly in this bug report. My fault, sorry. 1. Upstream main author is David Villa, which clearly stated *his* release policy and clearly refused to change it. I try to respect upstream opinions as much as Debian allows it. You do not have to change David's release policy at all. Actually, in this case, for what I have seen, David does not have any release policy, he does Obviously you didn't even tried to contact David. You didn't even tried to see the upstream head, which enforces *his* release policy. not release tarballs, and even if he did, you are not affected but his release policy to be forced to ship binary packages. Wrong (Cf. Debian Policy 3.2.1) For what I have seen in the package, the versions that are being uploaded are numbered after the date YYMMDD from a checkout of the code in the SVN and this code include a debian/ directory. Wrong, versions (and releases) are changed at commit time. The current head generates versions and releases at commit time, see upstream head. Let me explain you the way this is usually handled in Debian: CASE A) (easy case) When upstream release tarballs with the debian/ dir. This happens from time to time. Maintainer usually ask upstream to drop this directory from the tarballs and in the meanwhile (or if upstream just do not care), the maintainer repackage upstream's tarball to remove this directory. Not in this case. The maintainer is a developer. It wouldn't make much sense to ask himself to remove the debian directory. CASE B) (complicated case) upstream does not do releases at all and has debian/ in their repo. It seems to be the case here. In short, maintainer do a svn checkout, version it someway, package it and upload it. And follows Debian policy 3.2.1. He uses the same version numbers of upstream code. More lengthy: since there are not releases maintainers ned to version it, usually people start with a 0 and use the svn revision, for example, for the revision 56 of atheist, you could number it: 0.svn56 or 0.0.svn56, so it indicates in the version number exacty what revision is, which is quite handy when bug reports are filed to upstream. Using the date as it is being used in atheist is not a good idea, what if you need to do 2 or more uploads in the same day due to upstream changes? There is a release, although is not an orthodox release. Read the source and talk to David, much better than using the BTS for this. If in the future upstream starts releasing and it breaks your invented revision number, you can use an epoch. Indeed David already provides something like an epoch in his release scheme. See atheist.py from svn. Whan packaging, packager put this fictional version number and then the packaging revision with -X. About the debian/ dir, you just ignore it and if it is the case you are using that debian/ then you add it later. Not the case, the maintainer cannot ignore his own debian directory. In this case, of fictional versions it is a very good idea ask your sponsoree add a get-orig-source: rule in his debian/rules, so you can fetch the code exaclty as the sponsoree did and just the version he wants to upload easily. Fictional versions are only appropriate if the upstream release scheme does not work for Debian. It is not the case. No, you won't find about get-orig-source: in the policy, that does not mean you can not use it, if you google it you will see how useful it is for a lot of people, even for one of the policy maintainers: http://www.eyrie.org/~eagle/notes/debian/scripts.htmlhttp://www.eyrie.org/%7Eeagle/notes/debian/scripts.html there you can find some info of how to implement and use the get-orig-source: target. Yeah, sounds quite easy. You are basically asking upstream to use two branches to maintain a 32KiB package just to cope with your best practices and it wouldn't get you anything (see below). And you know what it is very good about
Bug#543990: It should not but it is
On Sun, Aug 30, 2009 at 01:37:32PM +0200, Francisco Moya wrote: Obviously you didn't even tried to contact David. You didn't even tried to see the upstream head, which enforces *his* release policy. You are pointing me again to talk with upstream several times. That is *your* job,( sorry, your sponsoree's job...), upstream theoreticaly has nothing do to with debian. not release tarballs, and even if he did, you are not affected but his release policy to be forced to ship binary packages. Wrong (Cf. Debian Policy 3.2.1) yes, when upstream does releases, no the case. Rest of the mail skip since you are repeating again and again the same stuff and you keep reciting your own interpretation of the the debian policy as a parrot. It is also sad you did not even try to understand what other people and I tried to explain you. We all are far more experienced than you in Debian and we have tried to explain you how do things better, and you have not even tried to think about what we explained you. If I open the discussion in -devel then I would need to allocate enough time to collect opinions, summarize, etc. I'm sorry but my time is limited right now. Things may change in the future, but I consider this a minor issue and indeed we all agreed to fix this in the next release, even when I didn't find *any* convincing argument. If things are so worthless as you think they are it should be a quick discussion. And if you want to ask and discuss about policy changes, use -policy, no -devel... Ana -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543990: It should not but it is
On Sun, Aug 30, 2009 at 2:02 PM, Ana Guerrero a...@debian.org wrote: On Sun, Aug 30, 2009 at 01:37:32PM +0200, Francisco Moya wrote: Obviously you didn't even tried to contact David. You didn't even tried to see the upstream head, which enforces *his* release policy. You are pointing me again to talk with upstream several times. That is *your* job,( sorry, your sponsoree's job...), upstream theoreticaly has nothing do to with debian. Right, my job. I talked to David, but you don't seem to believe it. Do contact him *if you don't trust me*. I also told you to contact Cleto to get more information on why he doesn't want to be listed as an author. Is that also my responsibility? not release tarballs, and even if he did, you are not affected but his release policy to be forced to ship binary packages. Wrong (Cf. Debian Policy 3.2.1) yes, when upstream does releases, no the case. Your opinion and David's opinion seem to differ. He is the main author. Who is right? His opinion is also in svn head: atheist/doc/conf.py: ... from atheist import VERSION version = VERSION # The full version, including alpha/beta/rc tags. release = version David releases the code for every commit. Odd? Probably, but considering this as unreleased code is not less unusual. I already talked to David about releases, versions, and packaging. Besides, after wasting hours the bug is already pending and it will be fixed in the next upload. Do you really think we are doing any good to Debian now? Rest of the mail skip since you are repeating again and again the same stuff and you keep reciting your own interpretation of the the debian policy as a parrot. It is also sad you did not even try to understand what other people and I tried to explain you. We all are far more experienced than you in Debian and we have tried to explain you how do things better, and you have not even tried to think about what we explained you. What is really sad is that you didn't even notice that I made my best to reach a consensus. Indeed this bug is already tagged pending. If I open the discussion in -devel then I would need to allocate enough time to collect opinions, summarize, etc. I'm sorry but my time is limited right now. Things may change in the future, but I consider this a minor issue and indeed we all agreed to fix this in the next release, even when I didn't find *any* convincing argument. If things are so worthless as you think they are it should be a quick discussion. And if you want to ask and discuss about policy changes, use -policy, no -devel... Ana I don't see the correlation between severity and time to reach a consensus. This thread seems to contradict what you say.
Bug#543990: It should not but it is
On Fri, Aug 28, 2009 at 11:22:08PM +0200, Francisco Moya wrote: 4. I consider the package itself to be a small utility but extremely convenient for many people. Therefore I think it should be part of Debian (Debian Social Contract #4). [...] 6. Having a discussion like this in a place like the BTS is worse than having the same discussion in debian-devel or debian-private. As you can imagine, people which are so strongly opinionated on their release policy may easily get angry at such loose argumentation against their way of doing things. I don't understand why you insist on hiding this discussion in all your emails. It looks like you are not confident with you opinion. And as you like citing the Debian Social Contract, let me do the same: | 3. We will not hide problems | We will keep our entire bug report database open for public view at | all times. Reports that people file online will promptly become | visible to others. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543990: It should not but it is
On Sat, Aug 29, 2009 at 12:17 PM, Aurelien Jarno aurel...@aurel32.netwrote: I don't understand why you insist on hiding this discussion in all your emails. It looks like you are not confident with you opinion. Since when are the discussions of debian-devel hidden? Since when talking about the Debian policy and upstream release policies is a problem? I insist on talking about bugs in the BTS and talking about the Debian policy on the proper places. And as you like citing the Debian Social Contract, let me do the same: | 3. We will not hide problems | We will keep our entire bug report database open for public view at | all times. Reports that people file online will promptly become | visible to others. Who is talking about hidding anything? Please, do use the BTS, and report bugs or provide information. But don't use it as a communication tool because it isn't. For example, your message and this message have nothing to do with the bug report. Is the BTS the appropriate place to send them? No. Regards, F. Moya
Bug#543990: It should not but it is
Dear Francisco and Cleto (I expect), I think you clearly are misunderstanding a lot of stuff in this bug report. Your first answer was kind of violent as if you felt attacked for a bug report, I am sure it was not your intention but it is read in that way. Having bug reports in your packages is something perfectly normal in Debian and it is not bad, what is bad is not trying to address them in any way. Actually, having bug reports is a signal somebody is using the stuff you are packaging. By the way, it is not your package, but since you are the sponsor, I understand you feel resposible about it, which is quite fine. Let's see if I can explain better and maybe more lenghty what several people have tried to explain in this bug report. On Fri, Aug 28, 2009 at 11:22:08PM +0200, Francisco Moya wrote: I must have missed something. What is wrong in my statements? What file is rejected by Debian and why? What in this package contradicts the debian policy? I not only mean the letter of the DP but also the rationale behind it. What is wrong with this particular package given that ows is in Debian till 2007 and nobody complained? Since you do not quote here what you are answering, I am not sure at all what are you answering. It is usually nice quote exaclty what you are answering, it is one of the problems I have found to follow and understand you correctly in this bug report. 1. Upstream main author is David Villa, which clearly stated *his* release policy and clearly refused to change it. I try to respect upstream opinions as much as Debian allows it. You do not have to change David's release policy at all. Actually, in this case, for what I have seen, David does not have any release policy, he does not release tarballs, and even if he did, you are not affected but his release policy to be forced to ship binary packages. For what I have seen in the package, the versions that are being uploaded are numbered after the date YYMMDD from a checkout of the code in the SVN and this code include a debian/ directory. Let me explain you the way this is usually handled in Debian: CASE A) (easy case) When upstream release tarballs with the debian/ dir. This happens from time to time. Maintainer usually ask upstream to drop this directory from the tarballs and in the meanwhile (or if upstream just do not care), the maintainer repackage upstream's tarball to remove this directory. CASE B) (complicated case) upstream does not do releases at all and has debian/ in their repo. It seems to be the case here. In short, maintainer do a svn checkout, version it someway, package it and upload it. More lengthy: since there are not releases maintainers ned to version it, usually people start with a 0 and use the svn revision, for example, for the revision 56 of atheist, you could number it: 0.svn56 or 0.0.svn56, so it indicates in the version number exacty what revision is, which is quite handy when bug reports are filed to upstream. Using the date as it is being used in atheist is not a good idea, what if you need to do 2 or more uploads in the same day due to upstream changes? If in the future upstream starts releasing and it breaks your invented revision number, you can use an epoch. Whan packaging, packager put this fictional version number and then the packaging revision with -X. About the debian/ dir, you just ignore it and if it is the case you are using that debian/ then you add it later. In this case, of fictional versions it is a very good idea ask your sponsoree add a get-orig-source: rule in his debian/rules, so you can fetch the code exaclty as the sponsoree did and just the version he wants to upload easily. No, you won't find about get-orig-source: in the policy, that does not mean you can not use it, if you google it you will see how useful it is for a lot of people, even for one of the policy maintainers: http://www.eyrie.org/~eagle/notes/debian/scripts.html there you can find some info of how to implement and use the get-orig-source: target. And you know what it is very good about get-orig-source in this case? Since upstream does not release tarballs and users do not know exaclty what you are distributing in your tarball, checking the rules they can know exaclty. Imagine upstram is uploading the pdf files with documentation to the SVN while you generate them in build time. You do not need to fetch them. If there is something you should convince upstream about it is releasing tarballs of his software periodically and not ship the debian/ directory with some versioning scheme. Then you solve totally this problem. Advantanges of a package not being native for a random user: - When user see the upload is -2 -3, etc, users know it is NOT a new upstream relase and updates should not be big, just reading changelog will know exaclty what was changed. - When debian is frozen, you won't be allowed to upload a new upstream release. - When you see this versioning number,
Bug#543990: It should not but it is
Probably Chris Lamb is right in that atheist *should not* be a debian native package. But it is by decision of upstream authors. There is no separate repository for debian stuff and debian releases *do change* the atheist package version. Therefore while it is not a Debian specific package it is nonetheless [...] the case where a piece of software was written specifically to be turned into a Debian package (cf. DP 5.6.12). It wouldn't make sense to make a source package where diffs are always empty (forced by release policy) and the debian revision is always 1. Of course things may change in the future but the main upstream author does not seem to be open to discuss the release policy and version scheme (I tried). OTOH, I believe these issues should not be discussed in a bug tracking database. If doubts on the technical competence of the maintainer and/or the sponsor arise, please do contact them directly rather than filling the bug database with non-issues. Best regards, F. Moya -- Computer Architecture and Networks Group University of Castilla-La Mancha http://arco.esi.uclm.es/~francisco.moya/ Tel:(+34) 926 295 483, Fax:(+34) 926 295 354
Bug#543990: It should not but it is
reopen 543990 thanks On Fri, Aug 28, 2009 at 09:13:56AM +0200, Francisco Moya wrote: Probably Chris Lamb is right in that atheist *should not* be a debian native package. But it is by decision of upstream authors. There is no separate repository for debian stuff and debian releases *do change* the atheist package version. Therefore while it is not a Debian specific package it is nonetheless [...] the case where a piece of software was written specifically to be turned into a Debian package (cf. DP 5.6.12). This package is not specifically written to Debian for what I can see. It wouldn't make sense to make a source package where diffs are always empty (forced by release policy) and the debian revision is always 1. Of course things may change in the future but the main upstream author does not seem to be open to discuss the release policy and version scheme (I tried). You have a thousand of reasons in this thread why this should not be a native package: http://groups.google.com/group/linux.debian.devel.mentors/browse_thread/thread/35a4ed051d214826 Actually the upload that close my bug #543991, was an upload only with packaging changes... while it appeared as a new usptream release (and it is not). And I do not see what ustream has to do here, you just package their version and add -X. OTOH, I believe these issues should not be discussed in a bug tracking database. If doubts on the technical competence of the maintainer and/or the sponsor arise, please do contact them directly rather than filling the bug database with non-issues. uh I do not really follow what you point here. Yesterday, when filing #543991, I was about to file a bug about this very same issue when I saw Lamby has already fixed it. The BTS is the way we have to track this stuff... Ana -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543990: It should not but it is
Francisco Moya wrote: Probably Chris Lamb is right in that atheist *should not* be a debian native package. But it is by decision of upstream authors. There is no separate repository for debian stuff and debian releases *do change* the atheist package version. Therefore while it is not a Debian specific package it is nonetheless [...] the case where a piece of software was written specifically to be turned into a Debian package (cf. DP 5.6.12). It wouldn't make sense to make a source package where diffs are always empty (forced by release policy) and the debian revision is always 1. Of course things may change in the future but the main upstream author does not seem to be open to discuss the release policy and version scheme (I tried). Wrong, if upstream ships a file that Debian does not want to include anymore, then it won't work anymore. The right thing to do is to not include the debian directory in the orig tarball. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543990: It should not but it is
I must have missed something. What is wrong in my statements? What file is rejected by Debian and why? What in this package contradicts the debian policy? I not only mean the letter of the DP but also the rationale behind it. What is wrong with this particular package given that ows is in Debian till 2007 and nobody complained? 1. Upstream main author is David Villa, which clearly stated *his* release policy and clearly refused to change it. I try to respect upstream opinions as much as Debian allows it. 2. The package maintainer is Cleto Martin, also a developer of atheist. His commits go directly into the svn repo. There is no separate branch for packaging because, as the *main* upstream author requires, package version is also changed when the debian directory changes. Therefore this is indeed a Debian native package. It may posibly be turned into a non-native package but it would require a fork, which in my opinion is much worse than this. 3. The versioning scheme although not the most orthodox one does not create problems for Debian. No need for epochs and no problems in case of debian-only related changes. For me it is just a matter of inconvenience for them. Could you be more precise on the problems you forsee for Debian? 4. I consider the package itself to be a small utility but extremely convenient for many people. Therefore I think it should be part of Debian (Debian Social Contract #4). 5. The maintainer *is* one of the upstream developers with commit rights to the atheist repo but he is not entitled to change the release policy. Therefore if upstream ships a file that Debian does not want to include anymore then Cleto Martin, the maintainer will remove it from upstream repo. It works as long as the maintainer is an upstream developer and there is a real commitment to develop a Debian package. That is precisely what a native package is. 6. Having a discussion like this in a place like the BTS is worse than having the same discussion in debian-devel or debian-private. As you can imagine, people which are so strongly opinionated on their release policy may easily get angry at such loose argumentation against their way of doing things. Should Debian require the package maintainer (an upstream developer) to remove the debian directory from upstream source to introduce it afterwards in the diff? Wow, this really sounds tough. If upstream author writes a sentence if not in_a_Debian_system(): exit 0 then we would consider it a native package? How many debian dependencies must be introduced in order to consider it a native package? No joking, these are the complaints I heard today. Should Debian require an empty diff to go along the package for its whole life? This one is easier to swallow. Is there any other rationale behind native packages than trying to avoid empty diffs? Note that using nativeness to infer debian infrastructure packages is plainly wrong. Let's just imagine apt is ported to work on RPM repositories. Sounds familiar? Should we turn apt into non-native now? On the other hand having this kind of discussions on a BTS is just faking the stats. One more serious bug in the back of Debian distro. No wait it is closed. No, wait, it was reopened as a serious bug. No, wait it is wishlist. 9 follow-ups. This one must be a tough bug! Is it? Come on, this is a small simple package which just happens to have an unusual name and an unusual release policy. But it is still useful nonetheless. I do believe that there are hundreds of bugs which require more attention than this one. But since it seems to be such an attractor I propose two actions: 1. I'll try to convince the maintainer to turn this package into a non-native package with an empty diff. It sounds silly to me but it seems way better than splitting upstream source as proposed by Luk. What Luk propose would be equivalent to deny anybody the right to make a program ready to be used in Debian. 2. I urge you to reconsider having this discussion in a more appropriate place. Cheers, F. Moya
