Re: Adopting OpenStack packages
On 03/03/2017 04:09 PM, Allison Randal wrote:
> On 03/03/2017 08:01 AM, Thomas Goirand wrote:
>> Could you please put this on hold? It's possible that I resume my work
>> on OpenStack packages (though I can't disclose anything on this yet).
>
> Hi Thomas,
>
> I appreciate your preferences, I really do. But the past few months have
> been a pretty harsh reminder that a bus factor of one is a dangerous
> place to be. OpenStack isn't the only project that depends on these
> Python modules, and it's bad for Debian if maintenance drops every time
> you're between jobs. You need to let go, and let us help you.
> Maintaining general Python dependencies is what DPMT is here for. I
> promise we will be mindful of OpenStack's needs.
>
> Allison
Allison,
I do appreciate and welcome help. But this would IMO not help. Here's why.
1/ The OpenStack team is as much open as the DPMT. Anyone can join. Even
better, you don't need to join, you can just send patches to Gerrit. And
any DD/DM can upload. The Gerrit CI/CD is far more advanced than the Git
on Alioth. Moving back to Alioth is a regression in may ways (safety of
data, access rights vs gerrit, workflow effectiveness, automated
testing, etc.). And I'm not even addressing yet the horrible git-dpm
troubles, how many more years the team is forcibly burying every
contributor into. Plus Alioth is a security nightmare, and it's loaded
so much that even a simple git push can take hours (real life experience).
2/ Stretch is frozen, and during the freeze, I continued maintaining and
closing RC bugs. I will continue to do so. I never wrote I would stop
caring for Debian packages or Debian in general.
I wrote I cannot continue maintaining OpenStack on my free time the way
I did when I was full time, and I did so after seeing that nobody worked
on the Ocata release. But there's no meaningful RC bugs open right now,
and there's never been any for more than a few days on all the OpenStack
packages (ie: Newton release). I don't think it is giving me justice to
say I stopped caring, and that it caused trouble to Debian, the DPMT, or
any Python module/app maintainer. It did not (at least so far).
3/ The history of critical OpenStack dependencies not maintained in the
team shows the exact opposite thing that you are promising.
SQLAlchemy and it's half finished transition during the e freeze (1.1.5
is in Sid and haven't migrated, forcing some not-needed potentially
hand-crafted dangerous SQLA-related patches in OpenStack Newton for
Stretch) is a very good example of the maintainer being completely
careless of both the freeze of Stretch and OpenStack. I raised the topic
in the release list, the maintainer didn't even care to give meaningful
answers to valid points of argumentation (unless I raised the issue to a
tech-ctte bug), nobody seemed to care enough, and I didn't find enough
energy to fight yet another battle with the maintainer. The only option
given by the maintainer (ie: fight it through the tech-comittee) would
have been a waste of time for a lot of people, and probably would have
drained a lot of my energy at a moment were I didn't had much to spare.
So I gave up.
Django maintainers haven't been very careful either, giving weeks
instead of the needed months for the transition, making Horizon for
Newton in Stretch very difficult to achieve. The last patch was made
after the final release, even if both upstream and myself produced
patches during more than 3 months to achieve the result.
Nothing makes me believe this will change and maintainers in Debian will
start caring for OpenStack.
Alembic is one piece of the puzzle that may be a source of trouble in
OpenStack. Having a package inside the umbrella of the OpenStack team
has the huge advantage to tell the world that package maintainers must
care. I'm not sure it will continue to be the case if you move packages
to the DPMT. At the same time, I'm not sure if it will bring you more
help maintaining these packages anyway (I hope to be proven wrong here).
4/ Finally, I feel very much unwelcome by the team "leaders" of the DPMT
(of which the "main" person happen to also be that SQLA maintainer which
I prefer not to name). I already have, and will continue to avoid -as
much as possible- any contribution in the team, since I do fear that any
consequent work that I do will lead to another ban from git write
access, another round of undeserved public shaming, and a loss of the
remaining motivation and energy I still have.
So, to sum-up, if you move packages to the DPMT, that will be one good
reason for me to stop contributing to these packages in the future.
As a conclusion, instead of putting efforts into moving packages from
one team to another, which will achieve no meaningful result, the
efforts should be made on the maintenance of packages itself (like
having the ocata and pike debian repo up and running on OpenStack
infra). That's IMO a way more productive approach, compared to the -from
my side of things- destructive way you're trying to push for.
All this being written, yes, I will let go if you decide to go through
this path. But IMO, it's not the best option.
Cheers,
Thomas Goirand (zigo)
P.S: For many reasons, I would have prefer not having to write some of
the above, as some of its content is socially sensitive. Unfortunately,
I don't think I have a choice, and it's my duty to write these words
publicly. Hopefully, no flame war will start on these sensitive
subjects, and this thread will stay on the same single topic...
Reply to: