On 29.07.2014 08:04, Vincent Cheng wrote: > On Sun, Jul 27, 2014 at 6:30 AM, Markus Koschany <apo@gambaru.de> wrote: [...] > Great, thanks for the patches! I'm sure you've realized by now that > the fastest way to get stuff done in Debian is to do it yourself. ;) This and that taking the initiative and doing the work gets punished. [...] >> Imagine the gnome-shell maintainers decided to put their package into >> non-free because they felt it is "safer". It would make all dependencies >> suddenly uninstallable. You simply can't make arbitrary decisions about >> the archive sections. Just because Red Eclipse is "just" a game makes >> the issue not smaller or less important. > > Yes, the gnome-shell maintainers can decide to put their packages into > non-free if they so wish; doing so is not a Policy violation, even if > it sounds ridiculous. And yes, it would make their dependencies > uninstallable, which would indeed lead to RC bugs being filed against > it and/or its dependencies (and would likely be followed by some > heated flamewars on certain mailing lists). It's completely > hypothetical, but the gnome-shell maintainers can move their package > to non-free at any time, and only the CTTE can override them. What's your point here since you agree that moving the package to non-free would ultimately lead to RC bugs being filed? >> There is no documented Policy about the term "safer" but the Policy is >> very precise about Debian's archive areas. [1] If your package is >> compliant with the DFSG it must be in main because this area "comprises >> the Debian distribution". Otherwise other software, like my "games-fps" >> metapackage from the Debian Games Pure Blend, is not allowed to depend >> or recommend Red Eclipse. Since Red Eclipse is DFSG-free it is a Policy >> violation. Thus the severity must be "serious". > > No, Policy §2.2 explicitly states that non DFSG compliant packages > must go in non-free, but nothing about DFSG compliant packages being > forced to be distributed in main. I have heard "the Debian Project is an association of individuals who have made common cause to create a free operating system" and not a system of free software that they maintain in a repository called "non-free" and which is not part of the official Debian distribution. It is common sense that a DFSG compliant package must go in main because it does not fit the description of the non-free and contrib repositories. This is a very simple deduction and makes perfectly sense if you know that "only [main] is considered part of the distribution." > 2.2.1 only says that "Every package > in main must comply with the DFSG (Debian Free Software Guidelines)", > i.e. package in main -> DFSG-compliant, _not_ the reverse. Policy > doesn't forbid placing DFSG packages in contrib or non-free, as silly > as it may sound, so this simply isn't a RC bug. Yes, it sounds silly and I disagree with your assumption. Even if this was true it would certainly violate the core and the spirit of the Policy. > Just to be clear, I don't object to placing DFSG-free packages in > main; what I'm arguing against is inflating bug severity to accomplish > your own personal release goals when the bug doesn't violate Policy. > It may be important to you, but if it doesn't meet the definition of a > RC bug, it's not a RC bug, and it's definitely not a release blocker. > Now, just imagine if every maintainer and user decided to inflate the > priority of their own pet bugs... By now you should know my work and being aware that I have fixed quite a lot of RC bugs in this team. I have never inflated the severity of bugs and I don't create new ones purely on a whim when I am not convinced that this is the right thing to do. Having Red Eclipse in non-free again for Jessie makes the package "unfit to release" in my opinion thus I have raised the severity. In other words it is time to act. I am not thrilled to continue this discussion since we both agree that #740565 is a bug and we have a patch already. I would like doing real work again instead of arguing why free software should be in main. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature