Hi, On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote: > (Can we keep this on one mailing list, please? /me restricts this to > -devel) No. This has the potential of keeping people who are directly impacted by this proposal out of the loop. > And besides that, I think the more universal answer is > bikesheds/PPAs/you-name-it instead of yet-another-suite. Absolutely not. It might be an answer, but to an entirely different question. This proposal is about providing packages under the same rules, policies and QA as any other package in Debian, built in the same trustworthy manner. This is something a PPA does not do. To stay with the gitlab example: I would very much like to see some people (including the company I work at, two organisations I am otherwise involved with,…) use packages from Debian. This is mostly about trust - it is a very useful policy to limit the entities to trust for software distribution if you run production systems, especially when they handle third-party data. Debian is such an entity - while there are many people working in it, it is a body with defined procedures and standards that can be relied upon. Debian telling users to add a PPA to their trusted entities that is managed by some person alone, be they a DD or not, defeats this entirely. On Wed, Dec 26, 2018 at 08:29:17PM +0530, Pirate Praveen wrote: > The -backports team does not want the dependencies of gitlab to be in > -backports even though it meets the criteria for backports. So we will > end up adding it to volatile. Now if some one else wants the same in > -backports, they will have to repeat the process. > > Take nodejs or npm for example, which I backported now. In buster the > -backports team does not want it in backports if I'm doing it for > gitlab, even though they satisfy the requirement for -backports. So we > will end up uploading these to volatile, if someone else wants it in > -backports, they will have to do it again. > > It is one way (volatile can use -backports, but -backports can't use > volatile). I'm fine with that if people don't want our work for volatile > not added to -backports. > > Dominik, > > I think we can go ahead with volatile as separate suite and take > packages from -backports if exist but add all new dependencies to -volatile. > > This, > > "Dependencies on other packages in volatile should be avoided if > possible. Especially, dependencies of the package that also need > backporting must not be added to volatile just because they are > dependencies — every dependency that is needed to be backported to > support the volatile package must be considered on its own and in all > but unprobable edge cases be maintained as a formal backport. Obviously, > the unprobable edge case occurs when the package depends on another > package that also fully qualifies for volatile, as described above." > > should be changed to, > > "Dependencies of the package that also need backporting must be added to > volatile." No. The dpendencies of gitlab not being accepted into backports right now is an entirely different issue. I am repeating myself: This proposal is not intended to ease the life of maintainers whose packages qulify for -backports. The only difference between -backports and -volatile in this draft proposal is that -volatile can take packages that are not in testing due to the exact one reason that hey have a shorter lifespan. No single other thing qualifies a package for -volatile if it is not qualified for -backports. If there are other issues to solve than the lifespan of the package version, they must be solved in another way. On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: > As I said, gitlab was not about manpower. This new repo is completly against > our vision of what backports is. Therefore we don't want it within the > backports suite. Alexander, please don't get me wrong, but have you read the full proposal by now and considered it, independent of the gitlab story? I am pretty certain you did not did that yesterday before starting to object it - not because of your argumentation, but because reading, understanding, considering and challenging it and then writing your reply is simply not physically possible within the 4½ minutes it took you to object to it ☺. Therefore, I ask you to bring up the points you think are against your vision of backports. In fact, the proposal is laid out in a way that explicitly does *not* contradict it, and I am wondering what makes you think it does, let alone "completely". I still got the impression you are also confusing me with Praveen, to the views of whom I do bject as well to some extent (see above). So, this proposal is about extending -backports, but without getting in its way, and following all its ideas except for the source suite. Thus, please let us discuss this in a well-founded, argumentative manner instead of just ruling it out from the start. Thanks, Nik
Attachment:
signature.asc
Description: PGP signature