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.html<http://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 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. Is it so hard to look through the eyes of them? There is no such "what if upstream is uploading..." because they are upstream developers. In any other case use NMUs. 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. Wrong, talk to David. Most (if not all) of his utilities are distributed through the svn repo. 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. As I explained lots of times before, upstream releases change even when the debian directory changes. From current head I see a new release whenever there is a commit in the repo (see atheist.py from head svn). David does not want more than a release per day. Therefore, all of the commits in the repo during the same day belongs to the same release. Several alternatives to "quickly needed fixes" where discussed and they are all acceptable for Debian. A release with -2 in their release scheme means that changes were not commited into the repo. Therefore it wouldn't be the case of changes made by the maintainer (who is a developer). In that case the right debian release would be -1.1 (non maintainer upload). > - When debian is frozen, you won't be allowed to upload a new upstream > release. Totally right. In that case only non-maintainer uploads would be able to fit their release scheme. They have changed the versioning scheme a little in head svn, hopefully they will change it further in the future. Again something to talk about in a different place. - When you see this versioning number, you think it is not a package > developed > only for Debian. Maybe upstreams only care about Debian, but if the > software > is usful it will be picked by other distros. As far as I know native packages were originally devised to avoid empty diffs when the roles of developer and maintainer fall into the same person. Afterwards some clever people noticed that native packages cost more to Debian than non-native packages because the whole source is uploaded on each packaging-only change. AFAIK that was the rationale behind reducing the number of native packages as much as possible. It is not a matter of being useful to other people. There are virtually no packages which could not be useful to other people. And the most representative example is apt. APT is being used on non-deb distributions and it is native. There are also upstream managerial benefits of orthogonalizing maintainer/developer roles. But this is not something Debian should decide. Besides, the orig/diff separation is not the right way to reduce the size of the uploads. For example, a doc-only change (even a typo) would also require a full-source upload. I guess there will be a better way in the future. But in this case there is nothing to win. From atheist.py you can easily infer that source will be changed on every commit made, even when the debian directory is touched. > > 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. > > > > He can perfeclty maintain the debian/ directory wherever he wants, no need > to > fork at all. Just do as mentioned above... Uh? Therefore you, as a developer with commit rights into upstream repo just ignore the main developer and do whatever you want in a separate repo. Well, our idea of a team differs significantly. > And no, this is not a debian native package, it is not software developed > direclty for and in Debian. Again, this is explained above. This wishlist bug is being worked on. See atheist.py from head. I already commited a change to close this bug in head. > BTW if Cleto is developer of atheist why he does not appear in > debian/copyright? You mentioned earlier in this thread upstream was David > Villa > (message 44). And David happens to be also a Debian maintainer. Ask him, not me. But I wouldn't use a BTS to talk about these personal questions. > > 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? > > > > Read above. Read above. > > 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). > > > > While honestly I still do not understand what the program does, nobody in > this > thread had doubt of the usefulness of this piece of software. I didn't infer you had. > 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. > > Nothing to do here, again, explained above. > > > > > 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. > > This is the only thing annoys me about the whole issue. In Debian we > discuss > the stuff, we ask and we argue. You are the only who has get angry here and > did not want to discuss. > The BTS is being used exaclty for what it has been created, report issues > and > discuss about them. The BTS is a powerful tool to improve Debian. It gives extremely valuable data to improve process, allocate resources and focus on the important things. A discussion like this distorts the data and makes it more difficult to extract the right info. On the other hand a discussion like this is perfectly appropriate in debian-devel and it would benefit from a larger audience. As a general rule of thumb a BTS should not be used as a replacement of communication tools. About 10% of this thread is about the bug, the remaining 90% is about generic package management issues. [...] > > 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. > > > > > The policy is a great tool we have, but there is something called "usual > (best) practices", and you do not see very familiar with them (*). When you > got > feedback in this bug report from several other developers, it is nto > because > we wanted to annoy you, it is because we saw you did not know about this > and > wanted to *help* you. If I were annoyed I wouldn't have replied to so many messages. This has nothing to do with annoyance but with proper use of the tools to *help* Debian and not me. I may very well assume that there was a typo in the changelog and the uploader didn't notice it. But rather than assuming it I would confirm it *before* I file a bug report. Does this annoy me? Not at all. Would it be more effective? I think so. Assuming there is a will to reach a consensus in order of effectiveness I would mention direct phone call, live chat, personal email, small mailing list, and large mailing list. Increasing the number of bug reports does not improve Debian per se. I sincerely find obnoxious wasting so many resources in a wishlist bug. > All this said, the policy you seem to use so literally is not clear about > when a package should be native. I encourage you to open a thread about > this > in -devel and/or -policy and help to make it clearer. > If you want my personal opinion: we should kill the concenpt of native > package. 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. Nonetheless if anybody else raises this issue I'd try to contribute my opinion. > > Hope this helps, > > Ana > > (*) quoting text in bug report, how the bts is used and the alike. This is > not about > technical competence at all, it is about experience in Debian. >
