Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Pirate Praveen wrote:
>
>
> On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George <natureshadow@debian.org> wrote:
> >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.
> >
> >If there are other issues to solve than the lifespan of the package
> >version, they must be solved in another way.
>
> I agree with you, it is the best outcome. But when people with power (-backports ftp masters) are not willing to consider it, we have to go with plan B, which is less than ideal, but can move things forward.
>
> >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.
> >
>
> If people argue both ways, how can we answer? Either it adds more work for -backports team or it does not. Some people say its not fair to add more load while ftp masters say its not about load.
>
> If it does not add extra load, then I don't see why it can be kept out of -backports when it qualifies except for being a dependency of -volatile. They say it does not match with their vision. So what option is left for us? We have to take their word for it and move forward without inconveniencing them. I don't think -backports ftp masters is going to accept this proposal (from the responses we already received), so I can live with all dependencies in -volatile.
Jftr, we never said anything about dependencies. If it qualifies for
backports, I don't see any reason for not having those deps in backports. We
never questioned that topic. If it qualifies: great. If not, please don't
upload it.
A package qualifies for backports if:
- it adds new features
- wasn't available before
- is in testing
- will receive support for the lifetime of the backports suite
so things like npm are perfectly fine for backports. And we never said
anything for libs, even if they are "standalone" (nothing in backports is
using those libs).
The main problem with gitlab was: from our perspective several hundred
packages only had one uploader (to backports, other suites don't count) and
we wanted to minimize the risk of being alone with hundreds of unmaintained
backports.
We solved that problem (by getting more people responsible for the backports)
and accepted it.
Alex
Reply to: