Re: Request to fast track gitlab dependencies
Hey,
* Pirate Praveen <praveen@onenetbeyond.org> [2018-12-17 11:06:27 CET]:
> On 12/17/18 3:06 PM, Rhonda D'Vine wrote:
> > I think you misunderstand the purpose of backports. It is to offer
> > newer features from an upcoming release onto a current stable release.
>
> As I have already shared earlier, I'm trying to find a way to keep
> gitlab as an official package in debian. It does require changing the
> rules or finding a new place for gitlab that does not affect any
> existing place. I'm open to all suggestions.
backports though doesn't exist disconnected from the next stable
release. It's the core point of its existence. Please understand that.
> > 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 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.
> > Writing
> > bugreport entries like this clearly shows you don't understand the
> > rules of backports:
> >
> > | Would it be okay to close this bug after buster release? That would
> > | make it possible to provide newer versions via buster-backports. For
> > | buster+1, we can remove it from testing again, close to freeze.
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915050#65
> >
> > That sounds clearly that you want to hack the rules and don't want to
> > respect them. That's not the best basis to hold a discussion about
> > something you want us to do.
>
> Are you saying these rules are so holy we can't even discuss changes to
> them? Is rules made for the people or are people supposed to follow
> rules blindly?
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.
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.
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.
> I get paid to work on gitlab packaging, so I can spend as much time
> required to keep these packages in shape. The real challenge is when I
> cannot fix some issues, I usually get good support from both ruby team
> and gitlab upstream in case of issues.
That's relieving to hear. Thanks for that information.
Enjoy,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |
Reply to: