> >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. Plan B in this case are PPAs. If you want to engage in that idea, please do separately from the -volatile idea. > >> 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. As Alex laid out, it's mostly just the -backports team handling the NEW queue. So all of this really is independent from -backports, if another NEW queue is added (which I do not think is the best idea, but still possible). But, I do not think it is possible to start -volatile completely independently. I am pretty certain there is enough man power to handle it as a new suite, but on the other hand I am also certain there is not enough manpower to operate a compelte set of seperate services for it. In any case, I propose we stop discussing the who and where questions for a while and concentrate on the what and how. I will collect the opinions on that, and in a week or two, incorporate them into the proposal, along with the different possibilities for implementation. -nik
Attachment:
signature.asc
Description: PGP signature