Re: Proposal: Repository for fast-paced package backports
On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George <email@example.com> wrote:
>No. The dpendencies of gitlab not being accepted into backports right
>now is an entirely different issue. I am repeating myself: This
>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.
>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
>> our vision of what backports is. Therefore we don't want it within
>> 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.
Sent from my Android device with K-9 Mail. Please excuse my brevity.