Adopting org-bullets

[integral-dw]

I believe to be ready to adopt @sabof's org-bullets from the emacsorphanage, if all parties involved are okay with this. However, I am still rather new to GitHub (and admittedly, git in general), and my last attempt to contact sabof via mail has not been particularly fruitful. With that in mind I am looking forward to your opinion on the matter.

[lmintmate]

As a happy user of org-superstar (thanks again for making it!) I have to ask: What will your adopting org-bullets entail for org-superstar? Will you simply rename org-superstar to org-bullets, and try to replace the org-bullets entry on MELPA with your package? Will you maintain both packages at the same time (which would be redundant, since they serve the same purpose)?
I'd imagine the first, since it would greatly help with adoption, given that org-bullets is magnitudes more recognisable than org-superstar, but then you'd have to make the transition is as smooth as possible for new users (possibly giving some variables the exact same name as org-bullets e.g. org-superstar-headline-bullets-list -> org-bullets-bullet-list) and also consider any possible compatibility problems, as org-superstar requires emacs 26.2 and org 9.1.9, while org-bullets has no special requirements, so someone with an emacs and org version below these (e.g. using the emacs-provided org instead of the latest from the org repository) won't be able to use org-superstar. If the second (that is, maintaining both packages) is the case instead, you'd make a lot of duplicate effort and perhaps some things would be impossible to implement in a way as to be compatible with emacs versions below 26.2.
Ideally, I would like for an announcement or something to be made (not necessarily by you, but ceetainly somewhere where lots of emacs users will see it - maybe on the subreddit? ) telling everyone that org-bullets is deprecated, and they should switch to org-superstar instead, but again the fact it requires such a (comparatively) new emacs version might be a show stopper for this.

P.S. In regards to my note about the popularity of org-bullets, it's also weird how many people turn to the sabof version or any of its forks as a point of reference for org-bullets (doom emacs even uses Kaligule's fork as source for the package!) instead of the emacsorphanage one, given that's the version served by MELPA. Maybe you should speak to the maintainer of that one, @tarsius, in regards to the adopting,since he watches over the emacsorphanage version, instead of sabof, who has basically abandoned org-bullets.

[integral-dw]

To answer bit by bit:

What will your adopting org-bullets entail for org-superstar? Will you simply rename org-superstar to org-bullets, and try to replace the org-bullets entry on MELPA with your package? Will you maintain both packages at the same time (which would be redundant, since they serve the same purpose)?

I would preserve org-bullets. AFAIK, too many other packages/builds depend on it, like spacemacs. For that reason alone I would not be willing to break backwards compatibility.

If the second (that is, maintaining both packages) is the case instead, you'd make a lot of duplicate effort and perhaps some things would be impossible to implement in a way as to be compatible with emacs versions below 26.2.

I would duplicate some effort, granted, but I consider the scope of org-bullets to be a narrower one than that of org-superstar. I would generally hesitate to add a significant number of features to it, and instead focus on fixing potential issues in existing features. Since superstar is (essentially) a superset of bullets, I would generally recommend people to migrate to superstar if they expect feature additions.

Ideally, I would like for an announcement or something to be made (not necessarily by you, but ceetainly somewhere where lots of emacs users will see it - maybe on the subreddit? ) telling everyone that org-bullets is deprecated, and they should switch to org-superstar instead, but again the fact it requires such a (comparatively) new emacs version might be a show stopper for this.

For now, I would not do something as drastic as deprecating org-bullets outright (for the aforementioned reasons). Instead, I would much prefer to have an organic development in that direction (should it even happen). As for the steep version requirements, I do not plan to increase them unless the need arises, meaning that this issue will resolve itself soon enough. The reasons for them to be there in the first place are that (iirc) package-lint asked me to provide certain minimum versions for both, and those just happened to be the ones I had available for testing.

Given the popularity of bullets, I consider the end user's convenience to be paramount.

Maybe you should speak to the maintainer of that one, @tarsius, in regards to the adopting,since he watches over the emacsorphanage version, instead of sabof, who has basically abandoned org-bullets.

I strongly believe @tarsius will chime in eventually :)

[tarsius]

I would be happy to handover the package to @integral-dw. Normally I would suggest doing that under the umbrella of the emacsorphanage but here it would probably make more sense to place it next to the superstar repository. What do you think?

[tarsius]

Also I think its great that you want to maintain this. Thanks!

[alphapapa]

I would duplicate some effort, granted, but I consider the scope of org-bullets to be a narrower one than that of org-superstar. I would generally hesitate to add a significant number of features to it, and instead focus on fixing potential issues in existing features. Since superstar is (essentially) a superset of bullets, I would generally recommend people to migrate to superstar if they expect feature additions.

Yes, if you adopt org-bullets, I think it would be fair to place it into "maintenance mode," and direct new users to org-superstar by default (in the documentation, at least, if not in a deprecation warning eventually).

Given the popularity of bullets, I consider the end user's convenience to be paramount.

This is the kind of exemplary attitude that will make the Emacs package ecosystem better! Thank you!

[lmintmate]

Thanks again @integral-dw for your answers.

For now, I would not do something as drastic as deprecating org-bullets outright (for the aforementioned reasons). Instead, I would much prefer to have an organic development in that direction (should it even happen). As for the steep version requirements, I do not plan to increase them unless the need arises, meaning that this issue will resolve itself soon enough. The reasons for them to be there in the first place are that (iirc) package-lint asked me to provide certain minimum versions for both, and those just happened to be the ones I had available for testing.

In regards to the version requirements, maybe you should try and test the package then in different emacs and org versions, to see if the requirements can be lowered, because if the package can indeed be used by lower emacs versions this would help greatly with adoption.

Yes, if you adopt org-bullets, I think it would be fair to place it into "maintenance mode," and direct new users to org-superstar by default (in the documentation, at least, if not in a deprecation warning eventually).

Agreed. Also ideally the maintainers of spacemacs and doom emacs should be persuaded to eventually switch to org-superstar as well (since their new users mostly use the bundled packages instead of seeking out packages by themselves, and thus might not even look at something like org-superstar), but this also ties in with lowering the emacs version requirements of the package (see above).

[integral-dw]

I would be happy to handover the package to @integral-dw. Normally I would suggest doing that under the umbrella of the emacsorphanage but here it would probably make more sense to place it next to the superstar repository. What do you think?

I agree @tarsius. I have already set up a fork in advance for this particular purpose.

Also I think its great that you want to maintain this. Thanks!

I'm happy to! The amount of time and effort you guys put into maintaining such a significant part of Emacs' ecosystem is absolutely invaluable. I am happy to make what minor contributions I can to something that monumental.

Yes, if you adopt org-bullets, I think it would be fair to place it into "maintenance mode," and direct new users to org-superstar by default (in the documentation, at least, if not in a deprecation warning eventually).

That sounds like a good idea @alphapapa. I think that I will (for now) only add references to org-superstar to the documentation (README, comment header, maybe a docstring or two). Deprecation warnings can wait a few months. I would not like to be rushed as a user, so I'll take that part slowly.

[integral-dw]

In regards to the version requirements, maybe you should try and test the package then in different emacs and org versions, to see if the requirements can be lowered, because if the package can indeed be used by lower emacs versions this would help greatly with adoption.

I think I would be more comfortable to reach out to the community for that. However, I am willing to lower the version requirements close to the minimum all sanity checks will let me, and deal with the aftermath manually.

Agreed. Also ideally the maintainers of spacemacs and doom emacs should be persuaded to eventually switch to org-superstar as well (since their new users mostly use the bundled packages instead of seeking out packages by themselves, and thus might not even look at something like org-superstar), but this also ties in with lowering the emacs version requirements of the package (see above).

Currently I would most likely lay low for a little while and see how superstar performs "in the field". Once the dust has settled I see no problem in contacting a few notable projects myself if I have to.

[alphapapa]

I think I would be more comfortable to reach out to the community for that. However, I am willing to lower the version requirements close to the minimum all sanity checks will let me, and deal with the aftermath manually.

Since you're going to be maintaining org-bullets anyway, I'd encourage you to not add compatibility for older versions in org-superstar. Instead, support only current and later Org versions, so you can avoid the burden of carrying compatibility workarounds, and so you can take advantage of newer features that make the code easier to maintain. Let the older Org versions continue using org-bullets until they upgrade.

Backwards compatibility is important, but it's also a burden. Making a new package is an opportunity to make a fresh start without dealing with obsolete code, and without causing breakage for users of older Emacs/Org versions. org-bullets works well and can continue being used in those cases.

[lmintmate]

I think I would be more comfortable to reach out to the community for that. However, I am willing to lower the version requirements close to the minimum all sanity checks will let me, and deal with the aftermath manually.

Yeah, it's probably hard to test for different emacs versions, as you'd have to have all the different versions installed in different 'machines', be it physical or VMs, unless there is a way to easily run multiple emacs versions on a single machine - the only way I can think of would be to download the windows zip file releases and run each executable separately with a minimal config file only loading org-superstar. Now that I think about it (hadn't thought about this approach before writing this post), it might just work; if I have time, I think I'll try myself and let you know about the results.

Currently I would most likely lay low for a little while and see how superstar performs "in the field". Once the dust has settled I see no problem in contacting a few notable projects myself if I have to.

I understand your approach on this. If I appeared a bit too eager to push for the deprecation of org-bullets in favor of org-superstar, that's because I feel it's better than org-bullets in many ways; being actively maintained is a large plus, and it also has extra features, one of which I really wanted. But it being a new package means it has reduced visibility in comparison to org-bullets, which has been around for much longer, and thus benefits from a sort of name brand recognisability, not to mention that that one is in the package lists of the major emacs distributions (namely Spacemacs and Doom Emacs). Given that, adoption might be slow until it gets some traction somehow (maybe by 'word of mouth' through the community? haven't been an emacs user long enough to see how org-bullets itself was established in the first place).

Since you're going to be maintaining org-bullets anyway, I'd encourage you to not add compatibility for older versions in org-superstar. Instead, support only current and later Org versions, so you can avoid the burden of carrying compatibility workarounds, and so you can take advantage of newer features that make the code easier to maintain. Let the older Org versions continue using org-bullets until they upgrade.
Backwards compatibility is important, but it's also a burden. Making a new package is an opportunity to make a fresh start without dealing with obsolete code, and without causing breakage for users of older Emacs/Org versions. org-bullets works well and can continue being used in those cases.

Just saw this answer, just after posting mine. As I stated earlier, I think it would help greatly with adoption if the package was compatible with lower emacs and/or org versions. If this can be done up to a point without any workarounds in the code (that is with the code as is), why not do it? As I stated above, I might be able to test the package with previous emacs versions (and their accompanying org versions) on Windows zip file releases (unless there are better ways of checking with previous emacs versions, but I can't think of any myself).

[lmintmate]

Update: Took the liberty to create a new thread on the testing of org-superstar on older emacs and org versions on its repo, here.
Update 2: Just posted my conclusions there. The tl;dr is that the org mode version requirement has to remain the same, but the emacs version can be lowered at least to 26.1 - it could be lowered even more to 25.1, as 25.1 and 25.2 work fine with the latest org mode version, but 25.3 acts up on the visual level (see the thread for more info on that).

[tarsius]

@integral-dw Please delete your fork so that I can transfer https://github.com/emacsorphanage/org-bullets to you.

[integral-dw]

@tarsius done!

[integral-dw]

Thanks a lot, @lmintmate! I'll gladly set the version requirement to 26.1, then. Although I would say that that is fully sufficient. Given the fact that Ubuntu, Debian Stable, Arch and Fedora all support emacs 26.1+, I would say 26.1 is as close to a de facto minimal standard as it gets at the moment.

[tarsius]

@integral-dw I have initiated the transfer. I had to transfer from emacsorphanage to tarsius first, and from there you now have to explicitly accept it. (If you don't see it in the Github interface, then maybe you got an email at least.)

[integral-dw]

@tarsius I got the mail and accepted the transfer. Thank you very much!

[integral-dw]

I will be sure to update the README and everything around tomorrow. I'll try my best not to disappoint! 😅

[tarsius]

I have just updated Melpa and the Emacsmirror.

I'll try my best not to disappoint!

I have a good feeling about this. 😺

[alphapapa]

I have a good feeling about this.

Indeed, rarely have I seen anyone who develops so carefully. I'm glad @integral-dw has chosen to join the Emacs/Org community!