search

ch11ng / exwm

Emacs X Window Manager
2.86k stars 137 forks source link

Migrate project to https://github.com/emacs-exwm #942

Open medranocalvo opened 6 months ago

medranocalvo commented 6 months ago
tazjin commented 6 months ago

I believe doing a proper repository move (if you have admin rights here) will transfer the tickets, too (and establish a redirect at the old location).

Do you have the ability to do that kind of move, or do you intend to create a new repository and push there?

medranocalvo commented 6 months ago

I don't have admin rights here (I don't see the "Settings" tab) so sadly a fork is needed.

tazjin commented 6 months ago

Before you do that, I'd try contacting the Github support and see if they can help (and also maybe someone knows somebody at Github, that's usually a faster way to get support).

minad commented 6 months ago

Move repositories/wiki

If a transfer is not possible, all we can do is to add a link to the README here, pointing to the new fork.

Notify GNU ELPA admins about new maintainers

In principle one could add multiple names to the Maintainer: package header. Unfortunately the current version of package.el does not support this yet. I recently had this problem with the Compat package.

Update GNU ELPA externals URI

Let's notify Stefan @monnier. Stefan, please see this issue and #941. Thank you!

Tickets: what to do with the tickets? Is it possible to transplant the tickets. Could GitHub help us with that?

Maybe you can transfer tickets? Do you see a transfer issue button? But this would be a bit inconvenient anyway for the 200 issues here.

If not, I think it would be best to keep working on old tickets on this tracker (only I would be able to close them would be the downside) and point new ones to the new tracker on emacs-exwm. ...

Agree.

medranocalvo commented 6 months ago

I wrote the following:

@ch11ng, the maintainer of ch11ng/exwm and ch11ng/xelb is missing since spring 2020. I, someone who sporadically collaborated with him and had commit rights to the repository continued maintenance on his repository these years. Working in this way is hindering the project, as no one but me can commit, release or close tickets. We are looking into migrating the project to an org (https://github.com/emacs-exwm) and would like to know whether it would be possible for Github migrate the ch11ng/exwm and ch11ng/xelb projects into emacs-exwm/exwm and emacs-exwm/xelb. In case that were not possible, would it be possible migrating the issues over there?

Let's see what comes.

medranocalvo commented 6 months ago

Tickets: what to do with the tickets? Is it possible to transplant the tickets. Could GitHub help us with that?

Maybe you can transfer tickets? Do you see a transfer issue button? But this would be a bit inconvenient anyway for the 200 issues here.

I don't see the button. Maybe once we fork.

minad commented 6 months ago

Regarding the transfer button, see https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository:

Note: You can only transfer issues between repositories owned by the same user or organization account. A private repository issue cannot be transferred to a public repository.

monnier commented 6 months ago

Notify GNU ELPA admins about new maintainers In principle one could add multiple names to the Maintainer: package header. Unfortunately the current version of package.el does not support this yet. I recently had this problem with the Compat package.

AFAIK the code does support multiple maintainers (separated by commas). If you encounter a problem with that, please notify me.

Update GNU ELPA externals URI Let's notify Stefan @monnier. Stefan, please see this issue and #941. Thank you!

Just send me an email when GNU ELPA needs to pull from another upstream, yes. [ AFAICT, this is not yet the case. ]

    Stefan "wishing the move was to a system that has fewer ethical
            problems than Github, like Codeberg, SourceHut, Gitlab, ..."
minad commented 6 months ago

monnier @.***> writes:

Notify GNU ELPA admins about new maintainers In principle one could add multiple names to the Maintainer: package header. Unfortunately the current version of package.el does not support this yet. I recently had this problem with the Compat package.

AFAIK the code does support multiple maintainers (separated by commas). If you encounter a problem with that, please notify me.

I've got a report, where multiple maintainers in the header field prevented package installation. This has affected the Compat package in the past. See these links:

https://lists.sr.ht/~pkal/compat-devel/%3C87leb4doh3.fsf%40gmail.com%3E https://github.com/emacs-compat/compat/commit/6bed57b83afce3a352d5862b8444fd61ec9640e0

Update GNU ELPA externals URI Let's notify Stefan @monnier. Stefan, please see this issue and #941. Thank you!

Just send me an email when GNU ELPA needs to pull from another upstream, yes. [ AFAICT, this is not yet the case. ]

Thanks. Yes not yet. We will ping you again.

jaor commented 6 months ago

On Fri, Jan 05 2024, monnier wrote:

Stefan "wishing the move was to a system that has fewer ethical problems than Github, like Codeberg, SourceHut, Gitlab, ..."

For the tiny bit it's worth, I was wishing the same. I moved some of my projects to Gitlab and others to Codeberg, and in both cases I found I could import, automatically, issues in the new repo. But maybe that requires admin rights...

Sorry for the interjection, and many thanks to all of you for keeping exwm alive, it's been my window manager of choice for years now.

monnier commented 6 months ago

I've got a report, where multiple maintainers in the header field prevented package installation. This has affected the Compat package in the past. See these links:

https://lists.sr.ht/~pkal/compat-devel/%3C87leb4doh3.fsf%40gmail.com%3E https://github.com/emacs-compat/compat/commit/6bed57b83afce3a352d5862b8444fd61ec9640e0

Actually M-x package-install RET works, but indeed the package browser burps when trying to show the description. It should be easy to fix.

    Stefan
minad commented 6 months ago

monnier @.***> writes:

I've got a report, where multiple maintainers in the header field prevented package installation. This has affected the Compat package in the past. See these links:

Actually M-x package-install RET works, but indeed the package browser burps when trying to show the description. It should be easy to fix.

Yes, indeed. I've created to bug#68288 to keep track of the problem.

medranocalvo commented 6 months ago

I updated the copyright years but not the Maintainers field, due to the issue you point out, @minad. I worry that using multiple maintainers will still lead to errors on older Emacs. If that's the case, I propose we use "EXWM Maintainers" (as you @minad did for the Compat package). I wonder which e-mail address we should use. The maintainer e-mail receives notifications from ELPA (such as "pushed", "new release"); I never received an user-report to that address.

medranocalvo commented 6 months ago

On Fri, Jan 05 2024, monnier wrote: Stefan "wishing the move was to a system that has fewer ethical problems than Github, like Codeberg, SourceHut, Gitlab, ..."

For the tiny bit it's worth, I was wishing the same. I moved some of my projects to Gitlab and others to Codeberg, and in both cases I found I could import, automatically, issues in the new repo. But maybe that requires admin rights... Sorry for the interjection, and many thanks to all of you for keeping exwm alive, it's been my window manager of choice for years now.

I've successfully avoided this decision in the past years and am prepared to continue avoiding it. Motivation is lack of time, energy and fear that it would mean an obstacle or friction for community involvement. (This fear might be without substance.)

Now that you @Stebalien and @minad are at the rudder, I defer to you completely on this matter and am happy with whatever you decide.

minad commented 6 months ago

medranocalvo @.***> writes:

I updated the copyright years but not the Maintainers field, due to the issue you point out, @minad. I worry that using multiple maintainers will still lead to errors on older Emacs.

We can still use multiple maintainers for the field. It depends on how serious we consider the problem to be. I don't. The problem only happens for describe-package'. *Installation is not affected.* We also use multiple maintainers for themarginalia' package and iirc I never got bug reports about that and the problem surfaced on the Emacs bug tracker just now.

For the Compat package, the situation is different. Compat is pulled in by many packages as dependency. As a consequence, Compat is used by many unexperienced users who have a hard time investigating error messages. We try to be as defensive as possible for Compat.

minad commented 6 months ago

medranocalvo @.***> writes:

I've successfully avoided this decision in the past years and am prepared to continue avoiding it. Motivation is lack of time, energy and fear that it would mean an obstacle or friction for community involvement. (This fear might be without substance.)

I prefer to keep development here for now. I am certain that I don't want to move to GitLab or SourceHut. Codeberg is an alternative but there is significantly less activity there.

Let's please not spend too much time on such discussions, including the commit style discussion.

Stebalien commented 6 months ago

I've successfully avoided this decision in the past years and am prepared to continue avoiding it. Motivation is lack of time, energy and fear that it would mean an obstacle or friction for community involvement. (This fear might be without substance.)

One step at a time, IMO. I've considered moving my personal project, but that's because I don't really care about contributions. Here, the user already needs to manually assign copyright. I think that's barrier enough...

buhtz commented 6 months ago

I respect decision of repo maintainers of course but would like to add one information to the discussion.

Codeberg is an alternative but there is significantly less activity there.

What type of activity you are refering, too? Codeberg is much more active then Microsoft. They response to users and maintainers is very quick, they are involved in the Gitea-soft-fork into Forgjo, they actively participate in the development of the tools they use them self.

Number of repos or users IMHO irrelevant. This is not facebook. There is no friends-network. Popularity of projects and potential contributors are IMHO not influenced by the hoster they are using. The decision contributing to a project comes from their users. And the users are not users because they surf around on Microsoft GitHub repos especially in the Emacs universe.

drawkula commented 6 months ago

Needing an account on 99 different Giteas and its clones is annoying, but a de facto monopole of one big player is too. I'm not happy with both alternatives.

I'm hoping that adding federation features to Forgejo will be a game changer for this situiation and if this were my project, I'd wait with a move until those federated forges prove to be as useful as I now dream of.

monnier commented 6 months ago

What type of activity you are refering, too? Codeberg is much more active then Microsoft. They response to users and maintainers is very quick, they are involved in the Gitea-soft-fork into Forgjo, they actively participate in the development of the tools they use them self.

They're also apparently involved in the ForgeFed/F3 effort (which IIUC will allow for example to submit merge requests between forges). I mention this because I think forge federation is an important functionality to move away from that nasty centralization and it's not advertised nearly as much as it should.

buhtz commented 6 months ago

Needing an account on 99 different Giteas

Consider using a password manager. KeePassXC can also handle these "fancy new" TOTP from Microsoft GitHub & Co.

medranocalvo commented 6 months ago

The migration matter is settled this time: we will move to https://github.com/emacs-exwm.

For the last years EXWM has been stagnating: @ch11ng went missing and I have had little time to devote to it. An influx of new energy appears now with @Stebalien and @minad taking maintenance. The direction of this energy is on improving the software (which I think is most needed) and not on switching forges. I propose the following: let's wait a couple of years and evaluate the project situation and energy then. There's nothing preventing a migration then, provided there's will for it.

Thank you @buhtz, @drawkula and @monnier for your reasoning; I personally found it enlightening.

medranocalvo commented 6 months ago

medranocalvo @.**> writes: I updated the copyright years but not the Maintainers field, due to the issue you point out, @minad. I worry that using multiple maintainers will still lead to errors on older Emacs. We can still use multiple maintainers for the field. It depends on how serious we consider the problem to be. I don't. The problem only happens for `describe-package'. Installation is not affected.*

Ah, alright. I misunderstood the scope of the problem. Then we'll set multiple.

medranocalvo commented 6 months ago

I wrote the following [to GitHub support]: [...] Let's see what comes.

No answer in almost a week. Let's proceed without assistance.

I imported XELB and EXWM into emacs-exwm. The EXWM wiki must be manually imported. Please have a look.

I also edited the to-do list above, please reflect whether there are any additional step we should perform.

minad commented 6 months ago

@medranocalvo I've finished a few tasks from the list:

minad commented 6 months ago

The GNU ELPA external URL has been updated: https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=640b170e4fbe4ad7cce50fae0931e2545d490ead

medranocalvo commented 5 months ago

@minad, thank you. I updated the list above. I'll take care of the remaining tasks as soon as I can.

tarsius commented 5 months ago

Regarding the transfer:

To get around the original author not being able to transfer to the new organization:

  1. Temporarily make them an admin of the organization. Now they can.
  2. Make them transfer the repository to the personal account of one of the new maintainers instead. They can then transfer to the organization.

In both cases no fork of the original repository may already exist at the new location, nor a repository, which isn't a fork but has the same name as the transferred repository.

So I would recommend you start any new conversations in the original repository, to avoid losing these conversations once the original author agrees to transfer the original repository and you have to delete the temporary repository. There are already 3 issues and 7 pull-requests in the new repository, but better to lose those than the ~950 in the old repository.

minad commented 5 months ago

@tarsius Yes, transferring the repository would have been better. The problem is that @ch11ng is missing and there is nobody with administrator access here. See https://github.com/ch11ng/exwm/issues/853 for more background. Regarding the many issues here - we will sort through them over time and hopefully fix a good chunk of them. However @medranocalvo is the only one who can close an issue here.

medranocalvo commented 5 months ago

Thank you for your comment @tarsius. We have a difficult situation here: the original author, @ch11ng, does not respond since 2021. At all. Because I contributed to EXWM in early times, @ch11ng gave me some rights to this repository here: I can commit, manage tickets and release; but I can't manage the repository.

Without action by @ch11ng nor GitHub there's no way to transfer the repositories to the new organization.

Given the situation I imported the repositories to the new org (https://github.com/emacs-exwm) and we continue working there. We have to attend to both issue trackers, where only I can close issues on this one (as far as I know).

I made a mistake when importing the repositories there; I should have forked them so that people can better discover where they are... now there's no way back. I'll change the README and ISSUE_TEMPLATE here as soon as I can to redirect users to the new location.

tarsius commented 5 months ago

We have a difficult situation here: the original author, @ch11ng, does not respond since 2021. At all.

I missed that part (but figured it might be the case). I agree that in that case it's best to proceed as you already do.

I should have forked them so that people can better discover where they are... now there's no way back.

That's a bit unfortunate, but not all that bad.

medranocalvo commented 5 months ago

I should have forked them so that people can better discover where they are... now there's no way back.

That's a bit unfortunate, but not all that bad.

I mean, we could nuke the new repos at emacs-exwm and start anew. @Stebalien, @minad: is it worth it?

tarsius commented 5 months ago

I mean, we could nuke the new repos at emacs-exwm and start anew.

Honestly, I am not even sure it would have been better if you forked from the get-go. On the plus side it acknowledges the historic relationship. On the negative side, it forever has the potential to confuse users ("is it, or is it not, the new upstream? it says it is a fork").

I would say, stick with what you have now, and make sure to properly acknowledge the original author, and prominently link to the old repository "for historic issues and pull-requests".

minad commented 5 months ago

The plan was to push new commits to the exwm and xelb repositories, such that the READMEs point to the new repositories. I've already done that for the wiki: https://github.com/ch11ng/exwm/wiki. See also the checkbox in https://github.com/ch11ng/exwm/issues/942#issue-2067565829:

medranocalvo commented 5 months ago

The plan was to push new commits to the exwm and xelb repositories, such that the READMEs point to the new repositories. I've already done that for the wiki: https://github.com/ch11ng/exwm/wiki. See also the checkbox in #942 (comment):

* [ ]  Change the master branch to a README explaining the move and new location

I've been dragging my feet on this... Thank you for taking care of the wiki.

Please have a look at #947.

There's a blocker with XELB: I don't have commit rights over ch11ng/xelb. I think the only way forward over there would be to open a ticket explaining the move and asking anyone opening a further ticket to please close there and open again in emacs-exwm. There's never been much activity in XELB anyway.

minad commented 5 months ago

@medranocalvo Thanks, I will take a look. I don't think that XELB is a big problem, since it is not as exposed as EXWM as a library in the background.

medranocalvo commented 5 months ago

There's a blocker with XELB: I don't have commit rights over ch11ng/xelb. I think the only way forward over there would be to open a ticket explaining the move and asking anyone opening a further ticket to please close there and open again in emacs-exwm. There's never been much activity in XELB anyway.

I don't think that XELB is a big problem, since it is not as exposed as EXWM as a library in the background.

I agree. I opened https://github.com/ch11ng/xelb/issues/31.

monnier commented 5 months ago

I don't think that XELB is a big problem, since it is not as exposed as EXWM as a library in the background.

BTW, I recommend making a new release soon so that http://elpa.gnu.org/packages/(exwm|xelb).html start pointing to the new upstream rather than the old one.

    Stefan
minad commented 5 months ago

monnier @.***> writes:

I don't think that XELB is a big problem, since it is not as exposed as EXWM as a library in the background.

BTW, I recommend making a new release soon so that http://elpa.gnu.org/packages/(exwm|xelb).html start pointing to the new upstream rather than the old one.

Makes sense. We will do that as soon as things have settled a little bit around here. I think there haven't been risky changes so far, but I still don't want to rush a new release.

medranocalvo commented 5 months ago

Crossed:

And added new task: