Web lists-archives.com

Re: Proposal: Repository for fast-paced package backports




On 12/26/18 5:45 PM, Dominik George wrote:
> On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote:
>> 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.

You probably want to read the definition of the Debian Bikesheds as per
the proposal of Ganneff. They are *NOT* the same as PPA, and they *DO*
include "rules, policies and QA as any other package in Debian".

> [...] 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.

This is *NOT* what the Debian Bikeshed proposal is about. They would
*not* be managed "by some person alone". Please do your homework, and
read the proposal, especially this one:

https://lists.debian.org/debian-devel/2013/05/msg00131.html

> 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.

To my experience working on the OpenStack packages, upstream lifespan is
not a reason good enough. You can still do the work the regular way.
Though Debian Bikesheds would be much nicer to deal with the upstream
fast pace, because you could have multiple backport repositories. If I
had it available, I would create one per upstream release (every 6
months in my case...). Your proposal doesn't address this, which is a
major concern for upgrades.

> 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 ☺.

I don't think using this kind of wording will be of any help. Contrary
to what you may think, this shows your lack of understanding of Alex's
point of view, or your will to consider it, rather than him being stubborn.

So, I'll ask for him again, as he must be both busy and (understandably)
annoyed by your reply. Why don't *you* consider what Alex told you: have
a try with your proposal outside of debian.org (for example on a .net),
and see how this works. That's how backports started, and that's
probably how your idea should too.

> 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".

Let's have a try, no?

> 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 still have the impression you aren't considering Alex's proposal that
you do an attempt external to Debian first, then we see how it goes...
How about "fastlane.debian.net" or something? Use that on your own
server, and we see what happens, no?

> Thus,
> please let us discuss this in a well-founded, argumentative manner
> instead of just ruling it out from the start.

Last time I write it: Alex has *not* ruled it out.

Cheers,

Thomas Goirand (zigo)