search

AntiMicro / antimicro

[NOT maintained anymore] Graphical program used to map keyboard buttons and mouse controls to a gamepad. Useful for playing games with no gamepad support
1.79k stars 202 forks source link

Discussion about further naming and future of this project. #351

Closed pktiuk closed 1 year ago

pktiuk commented 3 years ago

Introduction

As described in https://github.com/AntiMicro/antimicro/issues/349 there are new maintainers of this repository It would be good to discuss what to do further in terms of development of both projects: AntiMicroX and AntiMicro

AntiMicroX was a fork of AntiMicro created in 2018, when AntiMicro already stopped development.
Later also legacy AntiMicroX was abandoned.
In that case I decided to start maintaining everything starting from the latest code.
Maybe it was not the best decision, maybe it was. I don't know. Now we are in this place we have legacy unmaintained app and the new one with a new name and branding.

What we can do now

There are two possible target approaches: 1. Focus on AntiMicroX - push code from AntiMicroX and overwrite app's name - it would be used for redirecting entire interest to the new repository with new code. Pushing these changes wouldn't happen at once, because after some time AntiMicroX stopped supporting Windows. We would just publish the latest release still supporting it and slowly continue our work at AntiMicroX with restoring its support. Finally, we would push here AntiMicroX release restoring Windows support, leave a note about moving this project and (potentially) archive it.

Pros :

Cons:

2. Focus on AntiMicro - Backport everything to AntiMicro, use AntiMicroX as base of bug fixes and new features and apply them on top of master (apply all of them and rename everything back to AntiMicro or apply them step by step without messing with old name). Finally, we would end up with a new and shiny AntiMicro release containing all of AntiMicroX features and fixes, we could archive AntiMicroX and continue development here.

Pros:

Cons:

3. Move entire development to AntiMicro and link it with publishing legacy releases (idea of @AriaMoradi) - we could rename current master branch master to master_legacy and force push the latest AntiMicroX master to new master here, and later rename it to AntiMicro. From this point we could continue development of our cutting-edge master branch until it will be ready to be used instead of master_legacy as a source of releases for Windows. Pros :

Cons:

What do you think about this? Let us know in the comments.

Update

AntiMicro will have one more (the last) release with included deprecation message, there will be also some cleanup in the issues on this repo and later it will be archived.

pktiuk commented 3 years ago

@AriaMoradi
Approach number 1 seems to be opposite to your question about renaming AntiMicroX back to AntiMicro, but in this case it would certainly redirect most of the traffic to AntiMicroX.

gombosg commented 3 years ago

As mentioned in the other issue, I vote for option 1 since our free time is a real bottleneck here. IMO it's not the repo that is popular, the software is. The repo just gets good SEO but people can be redirected and informed easily.

zzpxyx commented 3 years ago

It sounds like the workforce is such a limiting factor that Option 2 won't even be feasible. Maybe I'm not understanding Option 1 correctly, but the easiest solution would be to archive the antimicro repo and only maintain the antimicrox repo.

gombosg commented 3 years ago

That is option 1, yes. But archiving antimicro is only feasible if antimicrox has feature parity i.e. it's a feasible replacement for all OSes.

AriaMoradi commented 3 years ago

@AriaMoradi Approach number 1 seems to be opposite to your question about renaming AntiMicroX back to AntiMicro, but in this case it would certainly redirect most of the traffic to AntiMicroX.

I think my best case scenario is still the best choice out of the 3 here.

pktiuk commented 3 years ago

@zzpxyx

It sounds like the workforce is such a limiting factor that Option 2 won't even be feasible. Maybe I'm not understanding Option 1 correctly, but the easiest solution would be to archive the antimicro repo and only maintain the antimicrox repo.

But before archiving it we would push some AntiMicroX releases to ensure sites like this , this and this will get "our" version.

pktiuk commented 3 years ago

@AriaMoradi Let me paste here your best case scenario for others (from: https://github.com/AntiMicroX/antimicrox/issues/34#issuecomment-725905972):

@AriaMoradi In terms of renaming after statement of jsbackus we will have to rethink our project. Maybe we could really go upstream and use changes from AntiMicroX in legacy AntiMicro. We will have to think how to deal with this possibility, because It won't as simple as pushing changes on new repo, it will also require updating our packages for fedora, arch and flathub.

(since renaming the repo is related to promoting I'll write my thoughts here, if not open a new issue for it)

best case scenario

1- pull from the old project, put the current branches under legacy named ones(i.e. master -> master_legacy) 2- force push and overwrite Antimicro/antimicro with what we have got 3- maybe bump a major version? 4- distribute both versions(antimicro and antimicro-legacy) 5- remove the legacy version when we are sure antimicrox is a strict superset of the old antimicro in respect to features

less desirable scenario

1- restore windows functionality and other features if removed from legacy 2- make sure antimicrox is a strict superset of the old antimicro in respect to features 3- force push and overwrite Antimicro/antimicro with what we have got 4- package and distribute everywhere 5- maybe also distribute the old code as antimicro-legacy?

I have added your best case scenario as option number 3. (please correct me if I made a mistake in rewriting it)

scarystuff commented 2 years ago

Don't know if this is the correct place to write this.. I am having a problem with latest antimicro. I have 2 homemade button boxes using the same hardware and they show up in antimicro with the same hardware GUID. Normally it is not a problem, but when trying to use the Auto Profile feature and choosing a profile for each button box, it keep loading the same profile for both button boxes. Is there another way to differentiate between them or a way to change the hardware GUID on one of the boxes?

pktiuk commented 2 years ago

We did our first step. With release 3.2.0 we have a fully functional Windows version.

Now we should decide what to do next with legacy repo.

We could for example release final release of AntiMicro with information about recommended migration to AntiMicroX and archive/abandon this repository. This would be a good attempt to migrate users to new app, but it would mean abandoning popular repo. (@Ryochan7 @jsbackus )

We could also try to migrate newer code (pull all the changes from AntiMicroX and rename it back to AntiMicro). It would mean some mess in packaging for systems distributing antimicrox packages (Arch, Fedora, Solus... source ), but it would allow updating some long forgotten antimicro packages. I think it would be good to ask people working with packages (@frealgagu @mirabilos @gombosg @manokara ) what do they think.
There would be also some work with migrating issues, discussions etc. to old repository.

What do you think, guys? Which solution would be better? Do you have any other ideas?

mirabilos commented 2 years ago

Paweł Kotiuk dixit:

I think it would be good to ask people working with packages @.*** @mirabilos @gombosg @manokara ) what do they think.

Debian ships an “antimicro” package, but it contains “antimicrox” binaries. I would very much prefer to not change that, as it will cause user confusion if the binaries are renamed.

While the first package included “antimicro” binaries, back then, we changed it to “antimicrox” without changing the binary package name because that was not yet contained in a release and renaming packages is much harder. But now, people will have been using it, and it was released as part of Debian bullseye (*buntu in hirsute although they had the 2.23 antimicro in focal because of schedule differences for releases).

If we rename the binaries etc. I’ll keep compatibility symlinks for one release (which is effort, but only once or twice).

bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)

gombosg commented 2 years ago

Hey @pktiuk !

I'm very happy about the Windows binary!

I'm also against renaming. We've been using the AntimicroX name for a while - be proud of it, keep it and don't break stuff for the growing user base. :)

If somebody wants to migrate from antimicro (mostly Windows users), they can still do it, it's easy.

(I.e. I'd just put a notice in the antimicro repo to use AntimicroX and archive it. In my opinion, no need to do more.)

pktiuk commented 2 years ago

@gombosg

(I.e. I'd just put a notice in the antimicro repo to use AntimicroX and archive it. In my opinion, no need to do more.)

I am not sure about this. Most of "casual" users don't use GitHub as a source of apps. Most of them use sites like sourceforge,microsoft store (what comes higher in google/bing/...) obraz

obraz

manokara commented 2 years ago

Do we have control over the release at the Microsoft Store? I'm not entirely against reviving this repo, but I think most preople actively using antimicro that want to keep it up to date with the latest goodies and fixes are probably aware of antimicrox. I know some people don't really care for the latest release of software they use as long as it works for their use case. That said, the discoverability of the original antimicro is undisputed.

I asked in the Solus development channel and I think they wouldn't object to the rename if that's what's decided.

pktiuk commented 2 years ago

Do we have control over the release at the Microsoft Store?

No, but we know who controls it
https://github.com/mayrinck/FOSSonMicrosoftStore
@mayrinck

pktiuk commented 2 years ago

Hey @pktiuk !

I'm very happy about the Windows binary!

I'm also against renaming. We've been using the AntimicroX name for a while - be proud of it, keep it and don't break stuff for the growing user base. :)

If somebody wants to migrate from antimicro (mostly Windows users), they can still do it, it's easy.

(I.e. I'd just put a notice in the antimicro repo to use AntimicroX and archive it. In my opinion, no need to do more.)

@gombosg

Even if we decide to archive antimicro we should somehow redirect downloads of antimicro from sourceforge (13,761 This Week ) to antimicrox.
How to do it properly?

pktiuk commented 1 year ago

To properly tackle the issue of redirecting the remaining antimicro userbase, I will just release that last antimicro release with information about recommended migration to antimicrox.
I think that simply adding an additional button informing about this (similar to the one which informs about updates for Windows in AntiMicroX) and an entry in the info section. It will be enough to inform unaware people and let further usage for people willing to stay with the legacy app.

pktiuk commented 1 year ago

@jsbackus
Could you help me with building this last release?
I have problems witb building windows packages for it.

pktiuk commented 1 year ago

There will be only regular windows package in this release (I can't figure out how to build portable one :/ After changing PORTABLE_PACKAGE flag I still get regular one)

pktiuk commented 1 year ago

Done.
Now I will start closing old Issues (and maybe link some of them with existing ones in AntiMicroX). https://github.com/AntiMicro/antimicro/releases/tag/2.24-final