On Wed, 26 Dec 2018, Dominik George wrote: > 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. And this is also solved. I emptied the NEW queue two or three days ago. If there are dependencies missing the backports wasn't tested, which sucks. > 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 ☺. Yes. Nothing changed til then. > 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). I don't. > > 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. You can discuss whatever you want. But I always saw backports as a suite with (well) tested packages from testing, so that users are able to get something / some features from the next release. I don't want backports to contain things are are not suited for a release. Alex P.S. I am a fast reader.
Description: PGP signature