How about abandon maintaining different layers in spacemacs, a list of hyperlinks instead.

[kuangdash]

I find that some layers may not be keeping up with the trend, is it better off that different groups maintain different layers?

[synic]

👍 .... it does seem a little odd that all the layers are actually in the main repo, instead of their own.

[chrisbarrett]

I think there are some groups of contributors that informally take responsibility for particular layers anyway. :) Earlier in Spacemacs' history there were lots of submodules but development became much easier, and the user experience got much better, when you only had to clone one repo.

[synic]

Yeah, but responsibility of broken packages is often unknown to the end user. All they know is "spacemacs is broken". There are indeed some layers that are out of date, and it probably shouldn't reflect on spacemacs as a whole.

[chrisbarrett]

But how does moving layers out of this repo improve that? To use the broken package, the user has already explicitly included it in their config.

[synic]

If the layer is broken, the user can now report it at the github issues location for that specific layer, instead of crapping up the spacemacs issues list, which is a bit out of control.

It also gives third parties, who have no affiliation with spacemacs, an easy way to create a layer and have it usable by folks in an easier manner than "clone it into ~/.emacs.d/private"

[chrisbarrett]

I getchya. syl would have to weigh up whether the reporting side of things is worth the management overhead of having separate repos, which would all have to be kept in sync.

I personally don't feel it would be worth it at this stage, since @TheBB is now being paid megabucks to do ticket triaging , but worth considering.

[TheBB]

Help, I'm trapped in an issue-closing factory. No evidence of megabucks yet.

[syl20bnr]

I know the temptation to replicate a ELPA for layers is very appealing but it would be terrible for the project.
Spacemacs layer system is a proposition to fix the bazar induced by the new package ecosystem made possible by the generalization of the ELPA repository. Reproducing the same ecosystem is a mistake.

Layers are light, official layers must be centralized to be able to correctly fit with the whole configuration, enforcing conventions etc...

I'm not against adding a mechanism to support non official layers (actually I'm for it since the beginning) but this is not a priority because we are still in beta.

I won't open the pandora box by allowing official layers outside of Spacemacs repo.

[syl20bnr]

Help, I'm trapped in an issue-closing factory. No evidence of megabucks yet.

This is a matter of tooling. Let's fix this with appropriate tools instead of morphing the project into a monster to add quick convenience.

[TheBB]

It was a joke, if that wasn't clear.

[syl20bnr]

I don't want to replicate the fish shell organization which started to define a repo per themes etc... This is a nightmare to administrate and put the info all over the place.

[syl20bnr]

It was a joke, if that wasn't clear.

I quoted the wrong guy sorry ;-)
Will edit.

EDIT: actually not... :-D

[syl20bnr]

Well I believe in the power of tags, this is why there are more than one hundred of them. I'm sure that with correct tooling based on tags we'll get a very neat adminstration platform.

I prefer to attack this issue from this side instead of the git side.

[synic]

I feel like a lot of PRs get skipped, issues get ignored. It seems if someone doesn't respond before they are past the first page, they have a much smaller chance of getting looked at. Only when you go through and do a bug sweep do they get any attention.

This is just my perception, you may kick me if I'm wrong :)

[syl20bnr]

For the PR side I'm currently learning a web framework (phoenix to name it) in order to make the first tool to manage the project: being able to vote for PRs.
I have not much time reserved for this project but it will happen at some point :-)

[syl20bnr]

@synic LOL I swear I didn't read your reply when I posted the last message.

[synic]

Haha, a PR voting system would be awesome. I think that would sort it right out.

[syl20bnr]

To be honest with the community I don't add collaborators to voluntarily slow the project, I still need to control what is going inside, the pressure is higher and higher but I don't want the project to grow to quickly. Let's take our time to build the project into a sane one.

[synic]

I would vote the crap out of this one: #2057. Half the bugs are because upstream changes stuff all the time. I don't think the project can be a sane one without pinning.

[syl20bnr]

@synic You are right, this issue is one of the last building blocks to have a stable Spacemacs. Right now we have the rollback which is 50% of the work, the other 50% is to be able to install Spacemacs from a stable state (by stable I mean that it starts correctly and has no broken main mechanisms/feature).

I think about it from time to time, maybe having our own ELPA repo could do it. But I would like this to be an installation stable state not THE state people should use. I mean the following use case:

• user installs Spacemacs and fetch the last stable state.
• user restarts Emacs and Spacemacs will update everything
• if anything goes wrong (very bad error, a main feature is broken) then user can leverage the rollback feature to go back to stable state.

We can achieve this only by coupling a given release with a given set of pinned packages.

[kuangdash]

Abandon maintaining different layers -- that is bad.
Every layer should have its maintainers -- that is true.
When it encounters problem -- ask who?

Another topic:
org-babel-tangle-file may be useful in the README.org of a layer, and should be advocated.

Thank you for the great project with regards. @syl20bnr

[d12frosted]

I feel like a lot of PRs get skipped, issues get ignored. It seems if someone doesn't respond before they are past the first page, they have a much smaller chance of getting looked at. Only when you go through and do a bug sweep do they get any attention.

Yeah, indeed. Obviously, that's why we should help @TheBB and @syl20bnr and pay attention to PRs and issues that we can help with. Also, @StreakyCobra proposed to announce "Autumnal Cleanup 2015" - an even of cleaning old issues and PRs.

At one point I moved from oh-my-zsh to fish just because the first one become overgrown. It had so much open issues and PRs that no one paid attention to, that it frustrated me too much. At the time I stopped to use it, it's official repository had 500 open PRs and it was common to see several PRs for the same reason. So honestly, when I started to use Spacemacs I feared to see something similar - popular projects require lots of time to maintain. But @syl20bnr and @TheBB are doing great job to get issues solved, PRs advocated. So at this point, I have nothing to worry about.

Also, having all official layers in one repo means that all changes to them are going through @syl20bnr or @TheBB and they keep the quality of changes on the high level with respects to Spacemacs ecosystem. Which is really great.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!