Project maintainer changing.

[Roman Kovtyukh]

As soon as current maintainer Stephen Boddy (@TheOddBodd) isn't responding, some people think that it's time to elect someone else and ideally -- several people with similar rights.

This become an issue not today but in early 2015 when few developers with maintainer tried to port project to GTK3 [1]. This issue lasted about two years before it was merged. Now project have some troubles with dependencies ([2], [3]) and the main issue [2] is with Python2 which will be dead till the dawn of 01.01.2020.

Stephen Boddy did a lot for project when he started to maintain this project after Chris. Now it seems like he can't continue his maintainer work (I hope he just have no time for this and in general everything is alright).

Here I suggest everyone interested in this project discuss our following actions.

For now we met this questions in Python3 thread[2]:
1. can we get rights without doing fork or we need to fork it?
2. if fork, GitLab or GitHub?
3. if fork, keep the same name with increasing major version or rename it?
4. what to do with it if we don't know the project or used technologies enough to maintain it? and what is enough?

[1] Port Terminator to GTK+ 3: https://bugs.launchpad.net/terminator/+bug/1030562
[2] Port Terminator to Python3: https://bugs.launchpad.net/terminator/+bug/1662544
[3] Deprecating rewrap on resize API: https://bugs.launchpad.net/terminator/+bug/1831944

[Roman Kovtyukh (hellodeargrandma)]

And now a little bit of my opinion.

About that questions:
1. I'd like to fork it just to move git. I think so more people is already familiar with git and it will not stop people from contributing to project as Bazaar can.
2. I don't care. It's important to keep the distributing process simple. On Launchpad it's very simple.
3. I prefer to keep the old name with changing the major version to 3 (2 is for port to GTK3).
4. I think we need to find up to five maintainers that will be able to review code and make important decisions carefully. In such a case the lack of knowledge can be smoothed by total experience of maintainers.

If we decide to do a fork, we need to do something with existing infrastructure:
* this repo;
* official site;
* etc.

[Roman Kovtyukh (hellodeargrandma)]

I just searched some people who can be interested in maintaining/contributing to project.

Prior maintainers:
* Chris (~datman)
* Stephen Boddy (~stephen-j-boddy)

Here they are (found them from some hot issues):
 - MattRose (~mattrose)
 - Egmont Koblinger (~egmont-gmail)
 - Dominic Hopf (~dmaphy)
 - Fuujuhi (~fuujuhi)
 - Robert Allred (~balinbob)
 - Mario Manno (~manno)
 - Dan Kilman (~dank-n)
 - Andrea Fagiani (~andfagiani)
 - Braden Kelley (~redbmk)
 - Simon Piette (~simon.piette)

Found them in this hot issues:
* Port Terminator to GTK+ 3 [https://bugs.launchpad.net/terminator/+bug/1030562]
 - MattRose (~mattrose)
 - Egmont Koblinger (~egmont-gmail)
 - Dominic Hopf (~dmaphy)
 - Fuujuhi (~fuujuhi)
 - Robert Allred (~balinbob)

* Port Terminator to Python3 [https://bugs.launchpad.net/terminator/+bug/1662544]
 - MattRose (~mattrose)
 - Egmont Koblinger (~egmont-gmail)

* Add support for tmux integration (like iTerm2) [https://bugs.launchpad.net/terminator
 - Mario Manno (~manno) (have his own fork with mentioned issue fixed)
 - Dan Kilman (~dank-n) (made the first working POC)
 - Andrea Fagiani (~andfagiani)

* transparency does not work in gtk3 [https://bugs.launchpad.net/terminator/+bug/1599453]
 - Braden Kelley (~redbmk)

* Regression: Opening a new terminal appears at back [https://bugs.launchpad.net/terminator/+bug/1646437]
 - Egmont Koblinger (~egmont-gmail)

* Repeated (rapid) middle clicks pastes multiple times [https://bugs.launchpad.net/terminator/+bug/1843399]
 - Egmont Koblinger (~egmont-gmail)

* Newer vte.feed_child takes only one argument [https://bugs.launchpad.net/terminator/+bug/1770759]
 - Simon Piette (~simon.piette)
 - Egmont Koblinger (~egmont-gmail)

I checked bugs and messages that are not earlier than 2016.

[Roman Kovtyukh (hellodeargrandma)]

* Port Terminator to Python3 [https://bugs.launchpad.net/terminator/+bug/1662544]
 - Emilio Pozuelo Monfort (~pochu)
 - Stanislav Laznicka (~stlaz)

[Egmont Koblinger (egmont-gmail)]

A bit of bikeshedding:

> I prefer to keep the old name

One reason for changing the name could be to avoid an existing name conflict: there is another terminal called Terminator (written in Java). Although that one hasn't seen a new release in 11 years (according to Wikipedia), and its latest source code commit is 4 years old, so even less active than our Terminator. Still, it's potentially confusing for those searching the web for answers, posting to forums etc.

One reason for not changing the name could be that so far everyone seems to be okay with this name, as opposed to Terminix (now Tilix) which had to change its name due to trademark infringement claims. It's hard to find a name that is new, unique, sounds good, and free of such problems.

Yet another approach is to call it terminator2 or terminator3, although that can look silly as the major version will further increase with time, see e.g. iTerm2 currently at version 3.3.6.

> hanging the major version to 3 (2 is for port to GTK3)

I'm not sure I'm following you here. I find it extremely unlikely that Stephen would appear and continue working on the Python 2 branch towards a Terminator 2.0. If he comes back, he'll sure join the ongoing Python 3 work. There shouldn't be a 2.0 release with old Python. Also it seems to me that the Python change is less risky, breaks fewer things, and is less user-visible than the GTK change was. So why not make a few pre-releases numbered from 1.92 or 1.95 or so, and eventually a Python 3 based stable 2.0?

But of course if you really want to call it version 3 then that's okay too, and reflects the GTK and Python version (I assume most of the users don't care about either of these), it's just an unnecessarily big jump IMHO.

---

Anyway, I don't intend to become a co-maintainer of this project (I'm happy to contribute occasionally, but that's all), so I'll let the future maintainers decide.

[MattRose (mattrose)]

1. I would dearly love to hear from either Chris (the original developer), or Stephen. IMO, without their explicit blessing, I would consider this a fork. I'm not sure launchpad would allow us to take over the repository and bugs without their OK, and even if they did, I wouldn't feel right doing it.

Having said that, I think, for the present, we should really look at GitHub for hosting rather than keeping it on Launchpad. We could move it to Gitlab, but I think that GH is familiar to most developers, and most developers have accounts on it, and it is really simple to do pull requests. I'm not familiar enough with Gitlab to be comfortable recommending it over Github.

2. Releases on github are equally simple, but the hard part would be convincing the various distributions to package the fork, and drop the original terminator. For Fedora (and consequently CentOS/RHEL) I (along with Dominic Hopf (~dmaphy) are the package maintainers, so this should be fairly simple, and as long as we can convince the debian maintainer, the change should filter through to all the debian derivatives. I have a bunch of experience releasing both prioprietary software and helping with releasing Open Source Software.

3. Personally on the naming thing, I would like to be able to keep the terminator name, with the blessing of the original maintainer, and if not, we should maybe think of using roboterm instead, tho as Shakespeare says; "A rose by any other name..." in the end I'm not too fussed however people decide on that one, should we have to change the name.

4. This is not as much of a concern for me. Learning new technologies is ... frustrating but interesting, and would be a key reason to actually take on a maintainership role. We can roll out the features that we're comfortable with, we fix bugs if we can. If we can't? Patches are welcome. It would be great if we were experts. This may sound a little egotistical, but I think if we spend a little time with the code we can be very competent maintainers.

I would be happy to take on a maintainership role. Ironically, even though I've used Linux for well over 25 years now, and have been using terminator for 10, I mainly use Mac these days, but I still like terminator and think it is a useful project, and I do use it when I'm using Linux, which I hope to be doing more of.

Anyway, that's my 2c

[Roman Kovtyukh (hellodeargrandma)]

Thank you, Egmont, I hadn't seen the naming question at such angle.

If talking about "RoboTerm", I found two companies with similar name via Google:
* one from Czech Republic: https://www.roboterm.com/
* another one from Poland: https://roboterm.pl/roboterm-kontakt/.

Well, IMO the naming question is very interesting, but not important enough for now. I would rather like to get in a contact with prior maintainers and other people who can take part in project life.

We need to contact prior maintainers to ask them for some kind of keys of this project or some suggestions.

We need to contact people who already played developers role in this project just to involve them into solving collected problems.

Talking about maintainership role, I like MattRose candidacy. I saw a lot of effort he put into the project.

At the same time I would like to see several maintainers on this project just because it's easy for single maintainer to become a bottle neck and speed down the progress of project.

[Roman Kovtyukh (hellodeargrandma)]

Just sent an invitations to Chris and Stephen Buddy.

[Robert Allred (balinbob)]

It would be nice to see this project progress, especially now to move fully to Python 3 and GTK+ 3.

I would like to encourage Chris and Stephen to put in at least some comment on the issue, if not
more input.

Encouraged to see Egmont and MattRose having some involvement.

To me, a lot of these issues depend on the former maintainers approving the go-ahead, else a
fork to Github, and possibly a change in name if we decide not to continue with a Release 2.0.
(My pref is a Terminator 2.0.)

I have an interest especially in the config system. The config system works well, But I do not
care for the current level of difficulty in modifying the config via the Preferences interface, and
wonder if this affects anyone else. Possibly just a few modifications to the Preferences interface
could achieve on-the-fly updates to the terminal, which most do use now.

Maybe another question would be whether the next release should be a simple port to Python 3
and Gtk+ 3, or a full go-ahead into these new areas? IMO, moving away from the dying
dependencies might be the main goal (not a complete rewrite into the new forms.)

[Stephen Boddy (stephen-j-boddy)]

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

[Egmont Koblinger (egmont-gmail)]

Hi Stephen,

Lovely to see that you're doing alright! :)

I think you should remain one of the formal maintainers (with repo rights and everything), even if inactive nowadays. Who knows when will you have time and motivation again!

> a personal blogger page

If blog posts remain reasonably rare (like, not announcing every single beta, only major stuff) then perhaps you could post them for the time being? (Does blogspot really not allow to transfer ownership of a blog?)

> Some prototyping work which demonstrated static image backgrounds

That prototype was awesome! :) VTE 0.52/0.54 added two new APIs: set_clear_background() and get_color_background_for_draw() which are somehow supposed to make background image drawing easier, although the details are unclear to me.

> [Robert] whether the next release should be a simple port to Python 3 and Gtk+ 3, or a full go-ahead into these new areas

In my opinion, the goal should be to release Terminator 2.0 with Python 3 + low-hanging bugfixes and trivial new features only. Bigger stuff could go to 2.1 or 2.2 or 3.0 or according to whatever versioning scheme the new active developer(s) will pick.

[Stephen Boddy (stephen-j-boddy)]

Hi Egmont,

Yeah, just life getting in the way. If my circumstances change I might be back. I don't mind staying on as a dormant co-maintainer / failsafe, unless there is some strong objections to the idea.

Well, I just checked blogger and I'm slightly shocked, but I can add other people as authors or admins, so that's good. In fact Bryce is still listed as an author. So that is also shareable too, provided the person has a google account.

On the prototype, yeah, before my time vanished I had big plans for that stuff. i.e. active backgrounds; such as a day/night gradient colour change linked to the clock, badges when it detects patterns in output (i.e. warning triangle when logging into a particular host), side-scrolling image like a 2D game, and other stuff. Probably overly-ambitious for both my time and my skills. I think you may have been the only person that ever saw the initial experimental prototype.

My opinion, for what it is worth, is to do as you suggested regarding the next release. Minimise the work and effort for the new maintainers to get Python 3 and GTK 3 out the door officially. Then people with itches to scratch have a solid base to do future work on top of. Even that will have some rabbit holes, as some of the bugs are real "it works for me <shrug>" types, and trying to fix those for *everyone* is a real pain. If on top of all that, someone starts adding new features, or redesigning big complex chunks, it will never get out the door.

[Egmont Koblinger (egmont-gmail)]

Hi guys,

Now that Stephen is back and stated his requirements for handing over the project, suddenly Grandma and MattRose disappeared? This does not look promising... (Or has there been some private discussion among you guys?)

Stephen, I'm wondering, as some "firefighting", could you maybe devote a few hours in the next couple of weeks to merge Grandma's work, fix a few really trivial ones (especially the extra parameter passed to feed_child), release an 1.92, and maybe an 1.93 in another few weeks if some notable regression pops up?

[Stephen Boddy (stephen-j-boddy)]

:-) Yeah... crickets. <chirp chirp>

It'll be a bit difficult to sort out some time right now. I'll be off around Christmas for a couple of weeks, so I'll look to try and do some stuff around then. I keep meaning to post a blog item seeking new maintainers, so I'll try to do that sooner rather than later as well.

[Dominic Hopf (dmaphy)]

Never fear, everyone's here and excited to see how Terminator will develop further. I have to admit my spare free time was a bit low the last few weeks (months? years?) as well, but I still love to use Terminator on Fedora and my heart would be bleeding if I had to drop it as a package maintainer because it isn't working with Python 3 anymore.

I'm glad to see some active people here discussing and doing actual work including Matt as a co-maintainer for the Fedora package while I wasn't able to.

So, I'd be in in maintaining this project with you guys together, even if my Python knowledge has serious room for improvements. What I know from other open source projects is, there is a lot of things to do beneath programming and I'll promise to always give my best. ;-)

My 2 cents for the initial questions in this issue:

1. No need to fork as Stephen is around, but probably move somewhere else which is not called Launchpad anymore, which leads us to 2..
2. You ask GitHub or GitLab, I say Codeberg https://codeberg.org/ (but of course I also will be fine with GitHub and Gitlab as well ;-) )
3. Let's probably just call this Terminator and increase version number to 3? :-)
4. I'll be glad learning Python and new stuff

[MattRose (mattrose)]

1. Yay! You're back!
2. Weird that I never got notified that you had responded in here.
3. I have read and understood your requirements for in comment #9, and I'd be honored if you would consider me as a co-maintainer.

One more thing: Fedora has a deadline of "Mid November" for either
a) removing the dependency on python2, or
b) applying for an exception for packaging in the next version of Fedora (which is why I suddenly became interested in this process again).

Is there a good chance we can release a python2-free version in the next couple of weeks? If not, dmaphy and I can probably sort out an extension. I know a few redhat developers use terminator regularly and wouldn't want it to disappear.

[MattRose (mattrose)]

Egmont, I didn't know Stephen had responded until now! :) dmaphy just sent me an email about it!

Also, wow, that happened at the worst possible time for me personally.

[MattRose (mattrose)]

Not saying I'm not interested in maintainership, obviously, but that was a particularly bad week.

[Egmont Koblinger (egmont-gmail)]

> One more thing: Fedora has a deadline of "Mid November" for either
> a) removing the dependency on python2, or

Does it have to be a tarball release, or is Fedora fine with a particular git version? And if so, is it okay if it's from a fork?

> I didn't know Stephen had responded until now! :)

Launchpad has this terrrrrrrrrrible misfeature that it doesn't auto-subscribe you to a bug when you comment.

[MattRose (mattrose)]

> Launchpad has this terrrrrrrrrrible misfeature that it doesn't auto-subscribe you to a bug when you comment.

And I thought bugzilla was terrible.

It doesn't *have* to be a tarball, but it would be much easier for the Fedora Maintainers (Oh wait, that's me and @dmaphy) if it were. However, I'd be perfectly fine with tarring up Grandma's branch and pushing that out if it's OK with everyone here.

Source URLs in RPMs are kind of a loosey-goosey thing.

[Egmont Koblinger (egmont-gmail)]

> And I thought bugzilla was terrible.

IMHO it's not terrible at all :) Way better than many others.

> tarring up Grandma's branch and pushing that out

You don't need to manually tar it up and host somewhere, bazaar.launchpad (as every decent VCS frontend) allows you to download a tarball at arbitrary revision. It's probably not guaranteed to always generate the exact same binary tarball though, not sure if that's a concern.

[Roman Kovtyukh (hellodeargrandma)]

Hi everyone. Nice to see all of you guys here.
It's me, Grandma. My real name is Roman.

Now I can't get a responsibility to be a (co-)maintainer of the project so I would like to take part in this project time-to-time getting responsibility for separate issues (probably not only coding issues).

Stephen, can we ask you to stay with us until we gain some experience?

As soon as Stephen is here, I think we don't need to move project somewhere before fixing some hot issues like Egmont (~egmont-gmail) sad in #10.

[MattRose (mattrose)]

noticing this has gone dead again...

[Anatoli Babenia (abitrolly)]

Forking is a better strategy than waiting. History shows that forks can be merged if found useful.

Bazaar is a nice technology to learn, but consediring that nowadays not that many people can get free time to do this, switching to git for the purpose of forking and merging could be beneficial.

[Markus Frosch (lazyfrosch)]

Is anyone still up to giving Terminator a new home?

As a user and the current maintainer of the package in Debian I have great interest in that, but I can't do it alone!

I've started the GitHub org: https://github.com/gnome-terminator

You can join in the conversation here: https://gitter.im/gnome-terminator/community

I know there a different platforms, everyone has their favorite, but we need to start somewhere!

[Markus Frosch (lazyfrosch)]

Please see the issue for a bit more explanation
https://github.com/gnome-terminator/terminator/issues/1