Gluon: Add community package repository

[CodeFetch]

Many community packages exist that are not in a state for being merged into Gluon or are e.g. too specific.
What about creating a repository for such packages?
This would allow people to see what other communities are working on and prevent double work.
The packages there should not need to meet the high quality standards like ordinary Gluon packages.

[kaechele]

I think this is a nice idea but it raises the question of who then manages this repo and merges pull requests and gets to decide when something is actually too bad or harmful to go into the community repository?

[CodeFetch]

Everything that is not clearly "destructive" should get merged and a big warning should state that these packages are potentially buggy and dangerous.

[mweinelt]

This would work if site builders were able to evaluate packages themselves, but that is hardly true.

[kaechele]

Maybe as a clarification what I meant by destructive: I was referring to software that constantly writes to the flash for example and thus wears it out. Or packages that allow to run the radios at an illegal power level or such.

[T-X]

Maybe make it the default policy to allow any Freifunk community to add packages? That way we make the "who then manages this repo" non existent as anyone active in a community's firmware development could get read/write access.

For harmful packages we could just use labels and issue tickets? I'd be interested in doing this experiment, maybe for things like constant flash writes etc. communities will help each other out and such issues might get fixed quickly due to the increased exposure through this common, shared repository.

And then maybe one rule, that people should add their community's site-code in a package name, like prefixing with "gluon-ffhl-" etc. to avoid clashes and to have some responsibility / "authority". Any package not doing this is then "outlawed" meaning free for everyone else to edit ;-).

Does that make sense?

[rotanid]

we have this at the moment:
https://github.com/freifunk-gluon/gluon/wiki/Community-Packages

and i don't think it's wise to make it easier to install packages that aren't considered good enough for everyone.

[rubo77]

Maybe we should just allow packages, that are actually rolled out somewhere in their stable branch already.

This way it is unlikely, that "harmful" packages would end up here.

I like the idea to concentrate the global manpower in such a collection.

[kpanic23]

Well, most of our packages are pretty specific to our network and would need some changes to be usable for anyone else (if...). So if anyone would like to use one of our packages, he would need to fork them anyway.
I like the current way of managing packages. Look at other communities' packages, copy them, change them, get inspired by them, using maybe only some routines of them and assembling everything together in your own community's repo.
Think of it as "freedom" ;)

[CodeFetch]

I wouldn't add this package feed to Gluon by default, but expect the communities to add them in their modules file.

What about using sub-directories like "production" for packages that are being used in stable branches and "development" for those which are work in progress.

A very popular package that would fit well in the production directory is Freifunk Hochstift's ffho-autoupdater-wifi-fallback. Another example: I know someone who is working on a package for solar routers with support for sharing data like battery status and charging status using respondd. This will likely never make it into Gluon, but would fit well in the production directory, too.

@kpanic23 When they are too specific, your packages would fit well in the development directory and maybe interested people would alter it to make it a more generic package that maybe could even become a part of Gluon later.

EDIT: I've just looked at the Wiki for community packages and was interested what "wifi-config" is, but unfortunately the repository has been deleted. This couldn't happen with a Gluon community package repository.

[CodeFetch]

On the last Gluon developer meeting we decided against a community package repository. The main reasons are:

• it might lower the efforts to get a package merged into Gluon directly
• it increases the maintenance costs
• those packages would seem to be officially supported while there might be no maintainer

Furthermore it was made clear that even very specific packages like a solar monitoring package are free to be merged into Gluon.