Excerpts from Thomas Goirand's message of 2017-03-04 04:37:16 +0100: > 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). >
I don't join it because it has not reached critical mass. I do love that you have built up a really nice set of automation, but I don't like that it's mostly just you. Maybe now that we have more eyes on it, we can change that, but meanwhile we can move more generic packages into DPMT and get an instant critical mass of people who will be responsive to general packaging needs that keep the release rolling forward. So even if we keep the OpenStack specific stuff in that workflow, I'd prefer that generic things be maintained by a larger team. > 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). > It's very troubling to me because despite all the work you've done, it's still mostly just you. I know, DPMT doesn't seem as awesome as the things you and a few others have made. But we _are_ a team, and we _will_ maintain the things that need maintaining. > 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. > That's for _OpenStack_. We're talking about libraries here. Nobody is suggesting that DPMT take on Keystone or Horizon. > 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). > I care. Allison cares. Barry cares. You care. DPMT cares too. What we need is trust in each other. > 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. > One great thing about teams is they have many faces. Talk to me. Talk to Allison. Talk to others. We're here to make sure things flow smoothly for OpenStack and Debian, and if you have disagreements and don't want to fight, I get that. Maybe we can reach consensus through other channels. > 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. > It would be great if we could separate libraries from applications. I know you feel that the whole stack of libraries is the real challenge, but I'm more interested in making sure Debian users can talk to OpenStack clouds first, and then if we can achieve it, run OpenStack too. The release cadence and speed of OpenStack does call into question the wisdom of this though. So, let's keep working together. You have people who are ready to listen and want to help. Take advantage. > 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... I appreciate your candor.
