Comment 9 for bug 1849375

Hi.

I'm happy (and still alive and well) to hand the one ring, my preciousssss, to the intrepid hero prepared to slog through the Dead Marshes toward Mount Maintainership. So consider this explicit permission for a willing person to take over all project assets in Launchpad. First, an explanation...

I used to have more free time, but I now have too many demands on that. On top of that, I used to use Terminator at work, so I could justify some efforts on Terminator as it increased my productivity. In changing jobs, I now work somewhere where I don't get the option of using Terminator, much as I would dearly like to, and the IT is *very* locked down. I've kept meaning to come back to Terminator, but then didn't, and didn't, and still didn't. So apologies for being a crap maintainer.

Responding to Grandma's original questions:

1. can we get rights without doing fork or we need to fork it?

No need to fork. Someone will be given full rights, and can then grant those to others as desired. They are then free to manage everything as they wish/agree.

2 & 3. Are not relevant to me, or I don't particularly care. I would point out that you could change Terminator in Launchpad to use git as the VCS if bazaar is a major turn-off for most.

4. what to do with it if we don't know the project or used technologies enough to maintain it? and what is enough?

The maintainer(s) will either have to learn, rely on others, or Terminator dies. As to what you need to know? How long is a piece of string? One of the advantages of Launchpad was almost everything is integrated. i.e. VCS, bugs, tracker, continuous integration/packaging/delivery, translations. If moving away from Launchpad you would need whatever replaces all those. On top of that knowledge: Python, the distutil python tool for packaging/installing, debian packaging, rpm packaging, a number of auxilary files (i.e.desktop, .appdata) are used. It would be beneficial if someone can find their way around the hacky css gtk theming files, although that stuff is an unending nightmare because, as the gnome devs put it: gtk is *not* supposed to be themeable, so they change stuff *constantly* causing all the UI errors between gtk versions. The Sphinx documentation software for generating the manuals that get built and pushed to readthedocs. Last thing I can think of is that I was using a personal blogger page and my own twitter account to announce things. I can't give those over, so some other option would need to be decided.

A couple of requirements I have:

1) No conscripts, only volunteers. The person (or persons) must respond here *themselves* saying that they are prepared to take over. No Grandma, you can't just vote Matt as the new maintainer. He/they have to want to do it, because it is not trivial.

2) The person must use a real name, and link off to something that makes them identifiable. They can message me at my gmail address if they are reluctant to share their on-line presence with everyone. No you are definitely not *my* Grandma, so I don't know who you really are. I would advise that *anyone* given maintainer rights be someone you can get some confidence as to who they are, preferably with some sort of online history. It'd probably be easy to spot malicious code going into Terminator, but better not to risk it. Terminator sending input/output to a malicious entity would be the death of any trust. If Matt was interested, I think I would be comfortable with him, but it is entirely up to him if he wants to take it on.

3) The licensing must remain as is. This should be obvious to everyone anyway, but just putting it here in black and white. See https://terminator-gtk3.readthedocs.io/en/latest/licensing.html

If and when someone steps forward, I will add them here in Launchpad as a maintainer, and they can take it from there. Unfortunately I'm unlikely to be able to guide them through everything, so they are going to have quite a bit to get to grips with. On top of that I have some work that never got committed, which I would like to hand over to someone so that it might still see the light of day. These will require pretty good Python to complete, so maybe the maintainer won't feel they have have the skills to continue it. So in that case I'll post them up as personal repos, and someone with skills, time, and motivation can pick them up. The two bits of work are:

A) A much improved logging/debugging/tracing facility with indentation for entering/exiting functions/methods with durations. i.e. instrumentation. This was *very* helpful figuring out issues, as the nature of Terminator made the debug bloody hard to follow. This was pretty gnarly code-wise, but it was functionally working - it just needed a bit of cleanup, and the enablement needed improving, i.e. the dbus and cmd line options.

B) Some prototyping work which demonstrated static image backgrounds, image badges, and moving image badges underneath a vte terminal using cairo and lots of half understood voodoo. This was *very* ambitious, and not for the faint of heart.

There might be some other bits and pieces, but I'd have to check. (Another reason I never got back to working on Terminator was because I discovered a coin miner on my system some time back, so I archived everything, fully reinstalled, and never got round to restoring my work folder. So I'll have to go digging for the stuff.)

One other dream I had (but wasn't ready before I stopped working on Terminator) was to replace the limited 2-pane splitters and all the complicated recursive nesting code. There was a new multi-pane splitter by Christian Hergert as a component in the libdazzle library. This would have been another dependancy, but a godsend cleaning up Terminators internals.

So if anyone wants to pick it up, please add a comment below, confirming you have read and understood the requirements I stated above.