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...