Move ronn-ng to an organization about ronn-ng

[apjanke]

Don't take 50k overall downloads as "many people", it could be just a handful of users making all those downloads 😅.

Even if that's just 50k runs of some CI system by a few people, that's more users than most of my FLOSS projects have. ;)

[deivid-rodriguez]

Hello @apjanke!

Thanks for creating and maintaining this fork of Ronn! It has given the community a way forward for keeping original Ronn's functionality but with modern Ruby libraries like nokogiri ❤️.

Would you be willing to give commit and release access to other people? The RubyGems team is looking into migrating away from ronn for our documentation site, and we'd like to use ronn-ng. But there are several improvements that we'd like to make. Currently they are all pushed to a new repo, but we'd like to use the most popular fork of Ronn, rather than creating yet another fork. I think getting commit access here would help us and the community.

Let me know!

[apjanke]

Hi, @deivid-rodriguez! Glad you're interested in ronn-ng. It's great to see it getting used.

Yes: Having a single active fork of the Ronn project would be best for the whole community. (As an old coworker once said, "Unite the tribes!") But with a caveat: This would have to be a bit of a gradual process. I'd be willing to give commit access to master or release creation rights to other developers, but not right away, until I've spent some time working with them and know them. For a FLOSS library that's distributed to end users (ronn-ng is in Debian), that's a pretty sensitive position and I think we need to take the security responsibilities there seriously, and for me that means moving a little slowly. (On permissions/org structure, not on development/features.) But I like this idea and would definitely be willing to work with you in other ways immediately. And then if things work out, granting full commit & release rights, or even rearranging project ownership – the RubyGems team would probably be a better long-term steward of Ronn-NG than me, if that's something you'd be interested in.

I'm quite open to feature requests as long as they don't break compatibility with existing functionality, and especially if someone's willing to do some of the implementation work on them. I could make a commitment to turnaround time on bug reports, PRs, and release requests made by your group, (like, 1 business day), give you direct email/chat/etc access to me, and prioritize your bugs/requests/PRs. (A soft commitment, since this is still a volunteer project, and I do have a day job.) Depending on how big your improvement requests are and how the work is divided up, we could set up a roadmap and release schedule. And I think I could immediately grant direct commit access to development branches in the main ronn-ng repo to your team if that's easier for you than working with GitHub fork repos, if GitHub supports that permissioning. (I've never used that before, since fork repos have always worked fine for me; I even prefer to use them on my own projects. But surely that's supported.)

Or are there specific workflow things that you'd need master commit access on ronn-ng for, in order for this to work well?

Are all your improvements in n-ronn on the main branch and release history there? That commit history looks short enough that I could just read it all to see what we'd be talking about merging to ronn-ng in the short term.

What do you think? Are you up for having a discussion about your vision and desires for moving Ronn forward, to make sure our views there are compatible? I'll read through your n-ronn repo over this holiday weekend so I have some idea of what's involved.

[deivid-rodriguez]

We don't need any features right now, and we haven barely needed them in 10 years with old Ronn, so I think it's unlikely that this library gets a lot of movement. So totally cool if you don't want to grant access to others as as long as we can get some releases out and our changes attended :)

Just note, regarding building trust, that if I'm counting correctly, there's been 20 PRs merged to this fork, and I contributed 8 of them 😅. But again, no big deal.

Regarding nronn, @tnir made a bunch of PRs in nronn on top of latest ronn-ng, you can see them here: https://github.com/n-ronn/nronn/issues?q=is%3Aissue+is%3Aclosed. I think all of them are cool for ronn-ng, I believe they are mainly focused on maintainability, but not big features or even bug fixes.

Happy new year, and thanks for maintaining this fork!

[apjanke]

Cool beans. Let's stick with the current org & permission structure for now and see how that meets your needs.

Feel free to drop issues here for bugs, feature requests, or PRs, or to request a new release be shipped. I usually respond within a day or two, though when I'm busy at the day job etc my GitHub/FLOSS email does develop a backlog. Send me an email at my main personal address [email protected] if you need a quick response on something.

I plan on rolling out a 0.10.1 Ronn-NG release late this weekend; let me know if there specific things you'd like to see in it.

Just note, regarding building trust, that if I'm counting correctly, there's been 20 PRs merged to this fork, and I contributed 8 of them 😅. But again, no big deal.

I'm so sorry; I work on a bunch of projects and I'm terrible with names! :) Still, 8 PRs isn't quite "give you commit rights to a package that is exposed to millions of users and has my name on it" territory. ;)

Those PRs from tnir look like things I'd like in ronn-ng; I value maintainability stuff. @tnir, is it cool if I just pull in those commits directly to ronn-ng, preserving your author credit in the commit history?

Happy new year, you're welcome, and thanks for using Ronn-NG!

[deivid-rodriguez]

That sounds good, this is your choice after all :)

A release will be definitely great. The latest release is a prerelease from 2 years ago, and it accounts for almost half of the 50k overall downloads of ronn-ng. Considering that neither Bundler nor RubyGems install prereleases by default, that means the few users of this gem do seem to need stuff that's not been yet released in a final version.

[apjanke]

8 PRs does get you a credit in the AUTHORS file, if you'd like it, though, @deivid-rodriguez . :)

03b0665

[apjanke]

The latest release is a prerelease from 2 years ago, and it accounts for almost half of the 50k overall downloads of ronn-ng.

Ohmigosh, that is no good. Definitely time to cut a new release here. Sorry for dropping the ball here. Expect a real 0.10.1 to be out by Tuesday.

[deivid-rodriguez]

Thank you!

But please don't take my petition as a request for credit, I was just trying to make things easier for everyone, specially since I read that you stated twice at #80 that you lack Ruby expertise to make certain decisions regarding maintaining this gem.

By the way, if in the future you'd like to give permissions to someone else, I think it makes more sense to add @tnir over myself (if he wants, of course), since he's now the main maintainer of our documentation site, and the one who has cooked all the improvements in nronn :)

[deivid-rodriguez]

8 PRs does get you a credit in the AUTHORS file, if you'd like it, though, @deivid-rodriguez . :)

I thought you had already committed that to the main branch, but I understand now it's just "an offer". Please, don't bother, not necessary at all :)

[apjanke]

But please don't take my petition as a request for credit [...]

You're welcome, and I don't. I just like giving shout-outs to people who have helped me, in the spirit of Open Source.

Too late now: it'll be easier for me to just merge this whole dev-2022-12 branch to main (it's where I'm doing the work of pulling in tnir's work on nronn), so unless you specifically don't want to show up in the AUTHORS file, you're in there. :)

[...] I was just trying to make things easier for everyone, specially since I read that you stated twice at #80 that you lack Ruby expertise to make certain decisions regarding maintaining this gem.

Indeed you are, and I appreciate the help. (And kick in the pants to get this project moving again; I didn't realize how many people were stuck on the prerelease waiting for the new stuff!)

[deivid-rodriguez]

Great!

Don't take 50k overall downloads as "many people", it could be just a handful of users making all those downloads 😅. I do suspect they are a considerable percentage of all your users.

[apjanke]

Here's a more structured issue if you want to follow the progress of my pulling in the nronn enhancements and getting to a 0.10.1 release: #87

@tnir - Most of your commits didn't cleanly cherry-pick to my ronn-ng repo, so I just reproduced some of your work in my own commits. You can see it on the dev/dev-2022-12 branch. Let me know if you'd like me to do something else about author credit for you here.

[apjanke]

Okay, so, the Tuesday 0.10.1 release is not happening; this is a little more involved than I thought. But I think I'm on a good track here, and a decent 0.10.1 release will be out in a couple of days.

[apjanke]

Okay, I think I've got my act together a bit now. My Ruby/Gems/Bundler environment on my main Mac seems to be working, and I think I understand the whole Gemfile.lock and RubyGems release cycle a bit more.

I have committed some changes, mostly Gem dependency revisions, on branch WIP/https-ify, and published a new Ronn-NG 0.10.1pre2 release candidate on RubyGems.

@deivid-rodriguez - want to give this new prerelease a try? If it looks good to you, I'll roll this out as the "rela" Ronn-NG 0.10.1.

[deivid-rodriguez]

We're already using a recent version from git, so no need! Thanks.

[apjanke]

Closing this issue as WONTFIX because I don't think moving ronn-ng to an organization makes much sense at this point.

Please follow the other issues or the Releases news feed for further updates on the related issues here. And if y'all think a GitHub org for ronn-ng makes sense in the future, feel free to drop another comment here and re-open this issue.