Re: Request to fast track gitlab dependencies
On ചൊ, മാർ 5, 2019 at 4:11 വൈകു, Rhonda D'Vine
<rhonda@deb.at> wrote:
Hi.
On 3/4/19 1:04 PM, Pirate Praveen wrote:
On 2019, മാർച്ച് 4 3:01:17 PM IST, Thorsten Glaser
<t.glaser@tarent.de> wrote:
On Mon, 4 Mar 2019, Pirate Praveen wrote:
The bug that caused removal from testing was a meta bug to keep
gitlab
out of buster. If that can be considered a valid excuse to keep
gitlab
in stretch-backports, please do. The package in backports-new
fixes
Please read again the backports rules.
I get it now, religiously following rules is valued more than
solving a real problem for Free Software and our users. For many,
keeping gitlab out of stretch-backports is a better solution even
though its in a perfectly fine shape. For them, it does not matter
the reason for removal from testing.
It would had been nice if you could keep it on a constructive level.
Agreed. I lost a bit of a cool when it seemd like I'm pushed from all
sides. I will be frank and write what I feel (some of it may still be
part of the frustration). I hope speaking my heart out may bring back
the lost cool.
Seemingly it isn't in a perfectly fine shape, otherwise the security
team concerns wouldn't be there. And if you have an issue with the
security team's opinion you should probably engage in discussion with
them instead of claiming it to be unfair on an unrelated list. It's
I just repeated what I posted on that same bug, so they are in the loop.
been months since, did you try to discuss it with the security team,
and
either understand their concerns or help them to lift it?
Yes, we discussed about setting up a separate suite [1]. I tried to get
it running as well, but Dominik got offended (rightly) when I tried to
take it forward without consulting with him first. I miscalculated
about the consensus. I wanted something by the time of buster, even if
not the final shape we wanted, but Dominik wanted more discussions and
finalize details before we start implementing. I think he still have
more optimism about getting more support whereas I don't really have
much left. So I left it for him to take it forward. Hope he can share
an update (cced).
Nothing is happening on it and blocked from doing it myself as well
contributed to frustration. Especially when I have the time and
interest to do it.
On hindsight, I could have done the following with disregard for
other team concerns and still be within rules.
1. Close that bug as bogus as it was not a real bug.
With that reasoning you disregard the stable release team on top,
too.
It was triggered by Alexander's mail about removing it from backports.
I felt everyone cares only about rules so I also wanted security team
to follow the rules and remove gitlab only when there is a real unfixed
bug.
2. Not bother with rails 5 transition, which would have allowed
keeping gitlab in buster and stretch-backports.
Sometimes bigger transitions should get put into bigger perspective.
It was done in a quite close timeframe, and if it cause troubles and
there is no time left for it to weed out, please learn from that and
potentially avoid such situation in the future.
I will take this as a lesson and stop bothering with helping
anything I don't strictly need for gitlab.
I'm sorry that you feel that way, and while I've been in such
frustrated states myself, it doesn't leave much space to learn from
the
experience and move forward.
It is only possible when people value what you have done. When
something you have done against your own personal/direct interest is
actually used against you, that is not an easy position. I let go of
gitlab in buster because I respected release team wish, but then that
same respect is used to remove gitlab from stretch-backports as well.
It seemed to me everyone just want to be in their own walled gardens.
I uploaded rails 5 to unstable fully knowing it will break gitlab,
as I didn't want to keep rails in a bad shape in buster.
If you know that then the timeframe for fixing it was very badly
timed.
Sometimes things should get weighted against each other. And given
that the security team's concerns weren't addressed I believe it was
the
better choice to get rails in shape than gitlab, even though that's a
missing piece now. :/
and exactly that same action is now used to justify removing gitlab
from stretch-backports as well. I thought of a better solution for
debian even though getting rails in shape was secondary to getting
gitlab in shape. My interest in maintaining rails is only because it is
a dependency of gitlab.
If it's not in buster it naturally cannot be in stretch-backports.
By such strict interpretation, that bug was clearly bogus as well.
No, it wasn't. It is very much within the rights of the security
team
to raise such concerns. If you don't address them then please don't
call them bogus, given that the security team does hell of a job for
keeping stable in a secure and stable shape.
There is already cases where packages in stable don't get security
support nodejs is one example and I think the whole node eco system is
unsupported. It'd be fine to have an exception for gitlab as well. I
hope in bullseye we will be able to sort it out fully.
I'm a bit disappointed that you didn't seem to have learned from the
discussions we had a few months ago, and seemingly haven't done much
to
improve the situation. At least it doesn't look like it from over
here. :/
see [1]. Also now 3 people are funded to work on gitlab. It is unfair
to characterise the situation as nothing changed.
Sorry that we got into that messy state, but we were frankly clear on
it, and like it seems little has changed.
I did try to get the new repo up and working, but putting the blame
squarely on me is not fair. What big changes in debian happen so fast?
In the current situation, you are removing a package that is in a very
good shape just to follow the rules. As for it not being in buster,
that situation was clear when it was allowed in (we all knew it was
planning to be removed).
So long,
Rhonda
[1]https://lists.debian.org/debian-devel/2018/12/msg00297.html
Reply to: