[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: Repository for fast-paced package backports



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. 

Attachment: signature.asc
Description: PGP signature


Reply to: