Re: Proposal: Repository for fast-paced package backports
Hi,
>having read the whole Gitlab discussion, I still don't get how/why the
>new repository depends or relates to backports. Instead it could be
>self-contained, except for stuff already available in stable. Couldn't
>you roll the new repository entirely independent of any backports? Even
>if you say there won't be any additional work for the backport policy
>owners, letting a new repo depend on backports will implicitly have an
>impact, which doesn't sound fully thought through yet.
This is answered in the proposal. The reason is to not have volatile abused to ease backporting, and to allow packages to easily move back to backports again.
>I consider especially copying parts of the version scheme fairly
>confusing. This gives your concept a bad touch of just trying to work
>around established rules (i.e. backports rules). Instead of defining
>such minor facets I would recommend you to work on clarity about what
>rules you want to establish in the new repo instead.
I am a bit disappointed that my efforts to emphasize good compatibility with established processes is interpreted that way.
As I already laid out several times during the last days, I am in fact disappointed that assuming bad or egoistic intentions seems to have become normal in Debian.
That said, the version numbering is a way to ensure work *with* established rules, not around.
>Also, as Alex suggested, I would prefer if such experiments could be
>started outside the official Debian archive, like backports once
>successfully did. Given how much efforts it took to get backports
>integrated officially, I don't consider adding a new repo a minor
>change. Did you discuss your idea with ftp masters, dak maintainers,
>and buildd admins before?
I did not discuss this proposal before discussing this proposal, no. That's why I am discussing this proposal :).
If you read it properly, you will find that does not add anything really new, but extends something existing - yet without interfering with it much.
>I acknowledge that Debian needs a solution to support fast moving
>projects like Gitlab better than now. Yet, without a *proof* of concept
>how this could work out in the long run (i.e. across more than one
>Debian release cycle), I don't think it is the right time to ask for
>such a big change now.
Again, the change is not new - it is an extension of backports, using the exact same concepts and rules, apart from the source distribution and the target directory. It is an extension designed to play very nicely with backports.
> I consider Debian open enough to support such
>concepts outside the official archive first.
I hope that e.g. official buildds will not grab code from my private machine and build it, for example.
-nik
Reply to: