On 12/17/18 4:11 PM, Rhonda D'Vine wrote: > Hey, > backports though doesn't exist disconnected from the next stable > release. It's the core point of its existence. Please understand that. As mentioned earlier, the idea was to see if that can be changed. The whole idea of backports itself was a new idea once. I will stop pushing for this change now. >>> Please don't volunteer for the team if you just want to do it for your >>> personal gain, and to circumvent the guidelines we have set up. >> >> I don't know if efforts to keep a package in official repos can be >> characterized as personal gain. > > The official repo you should try to keep it in is testing. Then we > have a basis to talk about. Backports is a supplement for stable. I was told, it cannot be in stable/testing, so my second best option was to try to have it in backports and now I learned that is also not possible. >> I offered to volunteer because I'm adding extra work to backport ftp >> team as there was no other reply from you before I asked explicitly on >> the status. >> >> Isn't it natural to volunteer for stuff you care about in debian? > > Sure, but volunteering doesn't mean changing everything along the way. > That doesn't build trust, and that's one of the core points of that > permissions, because it comes with responsibilities. As I said before, there was no communication on the reason for not accepting. The bug you mentioned to keep out of testing was filed after I requested to fast track gitlab. Also one reason pointed out in earlier discussions was "I have too many packages already". > Of course rules can be changed. This isn't though the first discussion > on changing the rules, and so far I haven't seen any argument whatsoever > why it should be changed. Please read back on the history of those > discussions, or come up with convincing arguments that don't sound like > "my package is more special than the others", because that's what it > always went down to unfortunately. And so far it doesn't sound > different for gitlab, frankly spoken. It is not a surprise that gitlab is not the first package to ask this, because the pace of development and release models have changed. So far the easy solution suggested seems to be keep those out of debian. > Expectations are that people can upgrade from oldstable with backports > to stable without backports. There is the sloppy pocket for upgrading > to stable with backports. But when you plan to never have the package > in any upcoming stable release and still want to push it into backports > you end up with packages in backports that aren't maintained outside of > backports anymore - and thus those packages aren't backports anymore but > become seperate maintenace branches. I was hoping this could be done, but I understand, it is not desired by backports team. > That's not what we want in backports, and that never worked out. We > always had to remove those packages in the end; and that leaves users in > an even worse state. So if we already are aware beforehand that the > packages won't ship with the next stable release we don't want to have > them in backports. Can you accept npm, which is useful outside of gitlab and there was already a request on this list for a backport? How about the dependencies of gitlab that are part of buster, can I maintain those in stretch-backports so only gitlab and gitaly need to be maintained in my personal repo?
Attachment:
signature.asc
Description: OpenPGP digital signature