Would it be possible to switch gem ownership?

Question

Would it be possible to switch gem ownership?

bkuhlmann opened this issue 6 years ago · comments

Overview

It doesn't look like this project is maintained anymore and was wondering if I could take ownership of the Ruby Gems namespace for deploying new versions of the XDG library? This project could remain as is but I'd end up publishing a new XDG project with the ability to publish newer versions of the XDG library to Ruby Gems. Would the maintainers of this project be willing to do that?

Details

I maintain the Runcom project which uses XDG under the covers as well as provides extended functionality for application developers. While the project currently doesn't support all of the XDG capabilities, I'm working on a feature branch which will provide support for all XDG environment variables. I plan to release this at the end of this year or first of the new year as soon as Ruby 2.6 is released. 🎉 My version of XDG does use a different API but the functionality that people need won't change.

Next Actions

If any of this sounds good, please comment here and we can figure out a path forward. Thanks!

Brooke Kuhlmann · Answer 1 · Wed Jan 02 2019 21:27:32 GMT+0800 (China Standard Time)

ℹ️ The feature branch, mentioned above, has been rebased onto master and is part of the Runcom distribution now. Still interested in separating that support into a distinct XDG gem, though.

Peter Hoeg · Answer 2 · Thu Apr 18 2019 09:57:22 GMT+0800 (China Standard Time)

@trans, any thoughts on passing the torch to an active maintainer?

7rans · Answer 3 · Fri Apr 19 2019 00:00:15 GMT+0800 (China Standard Time)

Sorry for not being more present. Life, Job ... blah blah blah...

But yes, transferring to a new maintainer is fine. My only worry is that I wouldn't want to see the gem just replaced with a totally redesigned API all of a sudden like. The code might be dusty but it's a simple library, and if any other projects out there are using it -- at this point I imagine in a largely "done and forgotten" manner -- I would hate to break their code and have them have to revisit and fix. That said, if a sufficient argument can be made for why the API should change, a well managed transition to a new API would of course be fine.

Brooke Kuhlmann · Answer 4 · Fri Apr 19 2019 02:34:12 GMT+0800 (China Standard Time)

@trans No worries, glad I could get a hold of you! 😉 ...and I definitely sympathize with a busy life.

One way we could tackle this transition is by doing something like the following:

Release a 2.2.4 version of your gem where the only change is an update to the project README and gemspec that includes a strong warning message upon gem install/upgrade where everyone is notified that in the 3.0.0 version, there will be breaking API changes.
Release a 3.0.0 version which then utilizes the API changes I have in the Runcom gem.

The nice thing about this approach is those who are using pessimistic locking in their Gemfile will have to manually choose to upgrade to 3.0.0. Those who don't will get a bit of a shock but should at least know something is up prior to this with the 2.2.4 release. Regardless, for those who don't want to move to 3.0.0, then they can simple lock their Gemfile at 2.2.4 until they wish to upgrade.

I can also help with the changes that would be needed in this project if you like. I can submit PRs with the changes suggested above. If that's too much, you could make me a co-owner of this project and I could work out the details that way too.

I'd still need to coordinate and/or be given access to RubyGems for this gem, ultimately. In order for me to publish new versions of the xdg gem, I'd need to have access to the RubyGems namespace. You could do that now by adding my email (brooke@alchemists.io) as an owner.

Would that be acceptable?

Brooke Kuhlmann · Answer 5 · Sun Apr 21 2019 20:30:59 GMT+0800 (China Standard Time)

@trans Wanted to check back in...any thoughts on the above? ↑ If you were to grant me temporary ownership of this project, I could help you move things forward via pull requests and/or direct changes based on how much time you have to review. I can also fork this project and issue pull requests the standard way too. Either way is fine by me but want to be sensitive to how much availability you have as I'm happy to do the heavy lifting. 😉

Brooke Kuhlmann · Answer 6 · Wed May 01 2019 09:32:09 GMT+0800 (China Standard Time)

@trans Wanted to check back in again. It's been a while and wanted to touch base. Any updates on this? Can I help in any way?

Brooke Kuhlmann · Answer 7 · Wed May 22 2019 02:42:23 GMT+0800 (China Standard Time)

In an effort to be transparent, I've been granted access to the RubyGems XDG namespace space and released 2.2.4 version which has the following post-install message:

‼️ Development of this project has been transfered here: https://github.com/bkuhlmann/xdg. This will be the last version supported within the 2.2.x series. Be aware major breaking changes will be introduced in the upcoming 3.0.0 release (2019-06-01).

This will help anyone still using the old 2.2.x series to prep for the upcoming 3.0.0 release. 🎉

Brooke Kuhlmann · Answer 8 · Wed May 22 2019 02:46:15 GMT+0800 (China Standard Time)

ℹ️ Closing this issue as I'll proceed with future updates via the new XDG project.

Ryan Taylor · Answer 9 · Wed May 22 2019 03:16:56 GMT+0800 (China Standard Time)

2.2.4 fails to install w/ a missing file.

For instance:
~/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/xdg-2.2.4/lib/xdg.rb:28:in require_relative': cannot load such file -- ~/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/xdg-2.2.4/lib/xdg/index (LoadError)`

FYI.

Brooke Kuhlmann · Answer 10 · Wed May 22 2019 03:23:04 GMT+0800 (China Standard Time)

@ryanmt What version of Ruby are you using? I'm using Ruby 2.6.3 and not seeing any issues. It might be possible this was a pre-existing issue? In case it helps, the only difference between the 2.2.3 and 2.2.4 release is an update to the version and post install message within the Index.yml. No other changes were applied.

Ryan Taylor · Answer 11 · Wed May 22 2019 03:53:02 GMT+0800 (China Standard Time)

I'm secondary to this, but the installer is reporting that 2.2.4 is causing issues. Let me confirm the behavior myself first. Thanks for the prompt response.

I can confirm that requiring xdg in irb, as well as any derivative gem installations are broken w/ 2.2.4.

Ryan Taylor · Answer 12 · Wed May 22 2019 03:55:35 GMT+0800 (China Standard Time)

I would suspect Add dynamic index metadata lookup via constants. is related.

diff-ing the install dirs gives me:

Files /home/<user>/.gem/gems/xdg-2.2.3/demo/01_base_dir.md and /home/<user>/.gem/gems/xdg-2.2.4/demo/01_base_dir.md are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/02_base_dir_extended.md and /home/<user>/.gem/gems/xdg-2.2.4/demo/02_base_dir_extended.md are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/03_base_dir_mixin.md and /home/<user>/.gem/gems/xdg-2.2.4/demo/03_base_dir_mixin.md are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/applique/ae.rb and /home/<user>/.gem/gems/xdg-2.2.4/demo/applique/ae.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/applique/fakeroot.rb and /home/<user>/.gem/gems/xdg-2.2.4/demo/applique/fakeroot.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/applique/xdg.rb and /home/<user>/.gem/gems/xdg-2.2.4/demo/applique/xdg.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/fixtures/fakeroot/.cache/DUMMY.txt and /home/<user>/.gem/gems/xdg-2.2.4/demo/fixtures/fakeroot/.cache/DUMMY.txt are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/fixtures/fakeroot/etc/xdg/bar.config and /home/<user>/.gem/gems/xdg-2.2.4/demo/fixtures/fakeroot/etc/xdg/bar.config are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/fixtures/fakeroot/home/.cache/foo.cache and /home/<user>/.gem/gems/xdg-2.2.4/demo/fixtures/fakeroot/home/.cache/foo.cache are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/fixtures/fakeroot/home/.config/foo.config and /home/<user>/.gem/gems/xdg-2.2.4/demo/fixtures/fakeroot/home/.config/foo.config are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/fixtures/fakeroot/home/joe/foo.txt and /home/<user>/.gem/gems/xdg-2.2.4/demo/fixtures/fakeroot/home/joe/foo.txt are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/fixtures/fakeroot/home/.local/share/foo.dat and /home/<user>/.gem/gems/xdg-2.2.4/demo/fixtures/fakeroot/home/.local/share/foo.dat are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/demo/fixtures/fakeroot/usr/share/bar.dat and /home/<user>/.gem/gems/xdg-2.2.4/demo/fixtures/fakeroot/usr/share/bar.dat are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/DEMO.md and /home/<user>/.gem/gems/xdg-2.2.4/DEMO.md are identical
diff -sr /home/<user>/.gem/gems/xdg-2.2.3/HISTORY.md /home/<user>/.gem/gems/xdg-2.2.4/HISTORY.md
2a3,10
> ## 2.2.4 / ?
> 
> 
> Changes:
> 
> * Add dynamic index metadata lookup via constants.
> 
> 
Files /home/<user>/.gem/gems/xdg-2.2.3/.index and /home/<user>/.gem/gems/xdg-2.2.4/.index are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/lib/xdg/base_dir/extended.rb and /home/<user>/.gem/gems/xdg-2.2.4/lib/xdg/base_dir/extended.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/lib/xdg/base_dir/global_variables.rb and /home/<user>/.gem/gems/xdg-2.2.4/lib/xdg/base_dir/global_variables.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/lib/xdg/base_dir/legacy.rb and /home/<user>/.gem/gems/xdg-2.2.4/lib/xdg/base_dir/legacy.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/lib/xdg/base_dir/mixin.rb and /home/<user>/.gem/gems/xdg-2.2.4/lib/xdg/base_dir/mixin.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/lib/xdg/base_dir.rb and /home/<user>/.gem/gems/xdg-2.2.4/lib/xdg/base_dir.rb are identical
Only in /home/<user>/.gem/gems/xdg-2.2.3/lib/xdg: version.rb
diff -sr /home/<user>/.gem/gems/xdg-2.2.3/lib/xdg.rb /home/<user>/.gem/gems/xdg-2.2.4/lib/xdg.rb
28c28
<     require_relative 'xdg/version'
---
>     require_relative 'xdg/index'
33c33
<     require 'xdg/version'
---
>     require 'xdg/index'
Files /home/<user>/.gem/gems/xdg-2.2.3/LICENSE.txt and /home/<user>/.gem/gems/xdg-2.2.4/LICENSE.txt are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/README.md and /home/<user>/.gem/gems/xdg-2.2.4/README.md are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/test/fakeroot/.cache/DUMMY.txt and /home/<user>/.gem/gems/xdg-2.2.4/test/fakeroot/.cache/DUMMY.txt are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/test/fakeroot/etc/xdg/bar.config and /home/<user>/.gem/gems/xdg-2.2.4/test/fakeroot/etc/xdg/bar.config are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/test/fakeroot/home/.cache/foo.cache and /home/<user>/.gem/gems/xdg-2.2.4/test/fakeroot/home/.cache/foo.cache are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/test/fakeroot/home/.config/foo.config and /home/<user>/.gem/gems/xdg-2.2.4/test/fakeroot/home/.config/foo.config are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/test/fakeroot/home/.local/share/foo.dat and /home/<user>/.gem/gems/xdg-2.2.4/test/fakeroot/home/.local/share/foo.dat are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/test/fakeroot/usr/share/bar.dat and /home/<user>/.gem/gems/xdg-2.2.4/test/fakeroot/usr/share/bar.dat are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/test/test_xdg_legacy.rb and /home/<user>/.gem/gems/xdg-2.2.4/test/test_xdg_legacy.rb are identical
Files /home/<user>/.gem/gems/xdg-2.2.3/.yardopts and /home/<user>/.gem/gems/xdg-2.2.4/.yardopts are identical

Ryan Taylor · Answer 13 · Wed May 22 2019 05:13:09 GMT+0800 (China Standard Time)

@bkuhlmann Sorry I missed this question earlier, but this is linux and ruby 2.6.2 right now.

Brooke Kuhlmann · Answer 14 · Wed May 22 2019 07:21:36 GMT+0800 (China Standard Time)

🙇 @ryanmt. I'm digging into this now. My guess is when I packaged the gem, I packaged it off of master assuming that was 2.2.3. I'm going to debug what you've posted above and what @chrisjohnson ran into as well.

If you don't mind, I would encourage you to follow the discussion here: bkuhlmann/xdg#1. I say this because I'm actively working to move everything over to that project.