Should this really be developed in its own repo and also be part of the Org-Mode repo?

[tarsius]

Why is org-bullets.el developed in this repository but also tracked in the contrib directory of Org-Mode's repository. I think this is problematic because it means that at least for users who install the org-plus-contrib package from the Org-Mode Elpa as well as org-bullets from Melpa it is undefined which version will be used (depends on the order of load-path).

So I would recommend that you either remove org-bullets.el from Org-Mode's contrib directory or remove org-bullets from Melpa. If you choose to do the latter, then you might even want to consider to remove this repository and develop directly in the Org-Mode repository instead.

/cc @purcell

[tarsius]

Please also see Bastien's comment on a very similar issue: larstvei/ox-gfm#14 (comment).

[tarsius]

Here's a friendly ping for @sabof.

@bzg: I just looked at @sabof's profile... he hasn't made any commit in any repository on github this year, seems to be inactive for the moment. So I don't really know whether doing the same as for larstvei/ox-gfm#14 (comment) would be appropriate here.

[bzg]

Thanks for the heads up @tarsius.

If org-bullets is inactive in @sabof repository, I'm not sure leaving it in org-mode's contrib/ directory will help that much.

The best thing would be for someone to take over org-bullets maintainance by forking it.

So I'm still for removing it from contrib. @sabof what do you think?

[tarsius]

We could maintain a "while maintainer is away"-fork in https://github.com/emacsorphanage.

[tarsius]

I've send Evgkeni an email, asking him to comment here.

[bzg]

Thanks, let me know when I can safely remove org-bullets.el from Org's contrib/ directory.

[tarsius]

@if he doesn't respond, do you think forking to the orphanage is a good option? I perform some minimal maintenance for the packages there, i.e. if someone opens a pr I deal with it, but I don't proactively look into improving those packages or even just keeping them compatible with new releases of Emacs and in this case Org.

[bzg]

Yes, I think it's a good idea to fork unmaintained Emacs packages in https://github.com/emacsorphanage - I didn't know about this repository and think it would be useful to advertize it more widely (but more exposure may mean more work!)

[tarsius]

I didn't know about this repository and think it would be useful to advertize it more widely

I intend to do that eventually, but I am not quite there yet.

(but more exposure may mean more work!)

Indeed.

Also I have abused this organisation a bit for the benefit of the Emacsmirror, meaning that some of the packages in the orphanage actually still have an upstream. As a first step toward making the orphanage more widely known, I have therefore compiled this list, which for each package states why it is in the orphanage.

[bzg]

I've now deleted org-bullets.el from the contrib/ directory in Org master branch.

[tarsius]

Thanks Bastien. I have not yet added this package to the orphanage (but added a todo entry). I'll wait some more time and then probably eventually add it to the orphanage and also update the Melpa recipe.

/cc @purcell

[tarsius]

I have completed the move to the orphanage.

[bzg]

Thanks for that.

[wkmanire]

I see that this has been acted upon and that org-bullets has been removed from /contrib. This broke my setup and I suspect it may break many others. Fortunately, it was easy to fix by installing org-bullets from MELPA. You might want to add a placeholder package to contrib called org-bullets.el that writes a message to inform the user of the decision to remove it, as well as instructions for your intended method of reinstallation of org-bullets.

Otherwise, their experience will be the same as mine which was that suddenly emacs can't find org-bullets.el and fails to finish loading my init script.

[bzg]

You are right that we should advertize this more clearly.

Out of curiosity, can you tell/show a bit more of your setup?

[purcell]

You might want to add a placeholder package to contrib called org-bullets.el that writes a message to inform the user of the decision to remove it, as well as instructions for your intended method of reinstallation of org-bullets.

But then it would potentially shadow the "real" standalone org-bullets on load-path. There's no substitute for following the org mailing list, I guess, when using a bleeding-edge version of org-plus-contrib.

[wkmanire]

In my setup I keep a site-lisp directory in ~/.emacs.d. I clone org-mode into site-lisp then add contrib/lisp and org-mode/lisp to load-path.

It's living on the bleeding edge I suppose, but there is a feature in org-mode 9+ that doesn't exist in what ships with emacs. There is some kind of bug in babel that affects code source blocks where you don't get syntax highlighting and you can't properly commit changes back to the source buffer when you org-edit-source-code.

[alphapapa]

@tarsius I'm willing to adopt org-bullets. I have used it for years and I intend to keep doing so.

@bzg However, wouldn't it be best to merge it back into Org and then remove it from MELPA? I have CA on-file with FSF, so I could help maintain it in Org. It seems like an essential package to me, so it seems like it ought to be built-in, or at least in contrib.

According to the original PR melpa/melpa#371, it was added to MELPA so people could use it before the next Org release came out, but I guess he forgot to remove it from MELPA afterward.

[bzg]

@alphapapa that's very kind of you, thanks for adopting org-bullets.

When your CA is signed and sent back by the FSF, why not adding org-bullets to GNU ELPA (instead of MELPA)?

I don't think it should be in Org's core, we are trying to be more strict with what should be in core. But ELPA is very straightforward for users, I'm in favor of this approach.

[wkmanire]

@alphapapa I see there are a couple of open pull requests. One is from February, the other one is from 2015. These aren't my pull requests, but It'd be great to see the org-bullets project being responsive to contributors. Is this something you'll be interested in reviewing?

[alphapapa]

@bzg Sorry, by on-file I meant that it's complete.

I was hoping it could be put in core so that the project (through maintainers like myself, at least) would make a kind of commitment to it, because I can hardly imagine using Org without it. :) I guess I'm thinking of it like a Linux kernel driver being out-of-tree.

I'd like to see it integrated so that users could activate it with a simple customization option. If you'd be willing to consider that, I'd be willing to work on it. But if you still prefer it in ELPA, that's okay. I haven't done an ELPA package before (several in MELPA), so I'd have to look into that.

@wkmanire Sure, once I officially (as officially as possible, anyway) start maintaining it, I'd be glad to.

[bzg]

@alphapapa I'm not 100% sure org-bullets.el should not be in core. But whether it should or not is not really up to me: we should ask the community. Before asking the community, we should (and that is up to me) set up an environment with a focus on contributed modules, whether they end up on GNU ELPA or elsewhere.

[wkmanire]

@bzg Contributed modules for org-bullets? What do you have in mind?

[bzg]

@wkmanire No, I meant "contributed modules for Org".

org-bullets was in Org's contribs/ directory, I removed it because it should not live in two places.

Many modules are left in contribs/ but would rather live elsewhere, on github for example.

My goal is to set up something like https://gogs.io on orgmode.org to promote some modules, and to delete contribs/ entirely, so that Org's git repository only contains Org's core, the code that is merged into Emacs repo.

[wkmanire]

@bzg Pardon my intrusion into your conversation. I hope you folks don't mind me sharing my opinions.

Your goal makes sense to me. If something is so essential to org-mode that it gets shipped with emacs, then probably it should be absorbed into org-mode instead of being a contributed module. Likewise, anything that doesn't meet that bar should probably be a standalone project like you've stated.

As far as gogs.io, would this just be for hosting the source for the contributed modules? Would we still be able to install all of the contrib stuff through package-install? Also, why gogs.io instead of github?

Personally, I use org-bullets everywhere I use org-mode. I'd love to see org-bullets be a built-in display feature for org-mode. At ~120 lines of elisp it doesn't seem like much of a burden...

[bzg]

@wkmanire No problem for chiming in.

gogs.io would be used to host Org's core repo and contributed modules, each one as a separate repo.

If someone wants to build and maintain a repo with a collection of contributed modules, the gogs instance on orgmode.org could host it as well, no problem.

github is not an option for Org's core repo, and I'd rather not suggest it for contributed module neither (see https://www.gnu.org/software/repo-criteria-evaluation.en.html for details).

[alphapapa]

FWIW, I agree with keeping Org stuff off of GitHub. I use it myself because it is convenient, especially having a single account and single place to get notifications across projects, etc. But were GitHub to go south, I'd quickly migrate to another service. I'm sure we won't be here forever.

I'm not really a fan of Savannah, though. It's better than nothing, but it's not very pleasant to use. So if org-bullets doesn't get into Org itself in some way, and I do end up adopting it, I will probably host it here and publish it in MELPA.

A gogs instance is an interesting idea, but if I'm maintaining the package by myself, I'd rather do it in the same place as all my other packages, which for now is here on GitHub. It's just more efficient to have things in one place (and since git allows us to do so safely...). I'd be happy to mirror it to the gogs instance, though.

Anyway, let me know how you want to proceed. For the moment, org-bullets is mostly working fine, so I guess it's not urgent to do something about it.

[bzg]

A gogs instance is an interesting idea, but if I'm maintaining the package by myself, I'd rather do it in the same place as all my other packages, which for now is here on GitHub.

Sure.

It's just more efficient to have things in one place (and since git allows us to do so safely...). I'd be happy to mirror it to the gogs instance, though.

Yes, that’s a nice possibility.

Anyway, let me know how you want to proceed. For the moment, org-bullets is mostly working fine, so I guess it's not urgent to do something about it.

Indeed :-)