Migrate project to https://github.com/emacs-exwm #942
Comments
|
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? |
|
I don't have admin rights here (I don't see the "Settings" tab) so sadly a fork is needed. |
|
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). |
If a transfer is not possible, all we can do is to add a link to the README here, pointing to the new fork.
In principle one could add multiple names to the
Let's notify Stefan @monnier. Stefan, please see this issue and #941. Thank you!
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.
Agree. |
|
I wrote the following:
Let's see what comes. |
I don't see the button. Maybe once we fork. |
|
Regarding the transfer button, see https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository:
|
|
> 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, ..."
|
|
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
emacs-compat/compat@6bed57b
>> 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.
|
|
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 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
emacs-compat/compat@6bed57b
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
|
|
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.
|
|
I updated the copyright years but not the |
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. |
|
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 the `marginalia' 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.
|
|
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.
|
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... |
|
I respect decision of repo maintainers of course but would like to add one information to the discussion.
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. |
|
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. |
|
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.
|
Consider using a password manager. KeePassXC can also handle these "fancy new" TOTP from Microsoft GitHub & Co. |
|
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. |
Ah, alright. I misunderstood the scope of the problem. Then we'll set multiple. |
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. |
|
@medranocalvo I've finished a few tasks from the list:
|
|
The GNU ELPA external URL has been updated: https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=640b170e4fbe4ad7cce50fae0931e2545d490ead |
|
@minad, thank you. I updated the list above. I'll take care of the remaining tasks as soon as I can. |
|
Regarding the transfer: To get around the original author not being able to transfer to the new 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. |
|
@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 #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. |
|
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. |
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.
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? |
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". |
|
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):
|
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. |
|
@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. |
I agree. I opened ch11ng/xelb#31. |
|
> 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
|
|
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.
|
|
Crossed:
And added new task:
|
See ch11ng/exwm#942 for the background regarding the move.
The text was updated successfully, but these errors were encountered: