Hi all, 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.
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. 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 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. I consider Debian open enough to support such concepts outside the official archive first. Kind regards, Micha
