195 replies to this topic

[alpa]

All this enthusiasam is great.
It's good to see best teams unite for common good, and keeping the stuff open.
I wish you all good luck.

[MiLo]

-- "cfg" for all configuration files

Configuration files (if they are modified by the user's action) should be stored in /etc/enigma2/. They should be recognizable as belonging to a plugin though, so name them after your plugin.

The reason is that they automatically go into a settings backup. Don't want people to go hunting for all the things they need to backup in dozens of locations.

[bacicciosat]

-- "cfg" for all configuration files

Configuration files (if they are modified by the user's action) should be stored in /etc/enigma2/. They should be recognizable as belonging to a plugin though, so name them after your plugin.

The reason is that they automatically go into a settings backup. Don't want people to go hunting for all the things they need to backup in dozens of locations.

I don't agree. This is true for linux applications. But in my opinion plugins are only e2 additions that have to be independent to be easly installed or removed.
I don't like plugins that go out of their tree without reason.
But it is only an opinion. I understand that the post you quoted can cause misunderstanding, so forget it.

[bacicciosat]

I'm thinking about restructuring the plugins to individual bb files. That needs some work and some discussion.
Basicly the questions plnick came up with.

It seems to me that the plnick question was about to push in main repo.
But this seems to be not a problem if we will have write access to it.

About the idea to create individual .bb files and avoid DYNAMIC_PACKAGES i am not sure to have the skill to understand.
In my poor knowledge i was thinking that we can start using one .bb file only (enigma2-open-plugins.bb) and change later when/if we will have a better solution.
Or maybe there are other problems ?

[pieterg]

having a single repository with a single toplevel makefile makes it harder to:

-merge plugins from different repositories into the shared repository
-pick a selection of plugins to be used in a certain image (or feed)

By using lots of stand-alone subdirs, we can probably make life easier, for developers and users.
(especially if every plugin/subdir would contain its own example bb file for instance, so everybody knows how to 'build' the plugin)

Looking at elitedvb for instance, where all plugins are built from a single shared makefile, imagine you would want to:

-leave out a certain plugin, because you already provide the functionality in your base image
You would have to apply a patch to the central makefile, to realise that
-add a certain file (e.g. customized default config or icon) to a plugin
You would have to write some custom code in the dynamic package grabbing code

[bacicciosat]

Ok pieterg this is absolutely clear and logic.
I like too the idea to add the example bb file for every plugin.
And this should be extremely logic and easy to implement in my experience using a single git for each plugin.

But how to do using a single git repository with stand-alone subdirs for each plugin ?
In this case if we use the git url in the source of bb file we will have for each plugin the process of the entire repository and source tree.
And this is not good.
Or am i wrong ?

[pieterg]

Perhaps we could even decide to just use a seperate repository for each plugin...
Or does github have a limitation on the number of repositories per project?

[bacicciosat]

It seems to me that there is not limit (i am not sure, maybe WanWizard can confirm)
But i am afraid that if we will have a git for each plugin nobody will cooperate and everyone will work only on its code.

[jeffphil]

Hi all I have been following this discussion and I would like to encourage this endeavour as it can only produce better plugins. I gather there will be a need for testers for these combined plugins and I for one would like to contribute to this process. My programming skills at not at a level to do any usefull development but I am happy to test and pass on results / logs as necessary.

[pieterg]

another advantage for one-repos-per-plugin will be that we will get a nice incremental version per plugin.
Instead of one combined version for 100 plugins.

So when a new version is available, that actually means something has changed.

[bacicciosat]

another advantage for one-repos-per-plugin will be that we will get a nice incremental version per plugin.
Instead of one combined version for 100 plugins.

So when a new version is available, that actually means something has changed.

If you think this is the better solution it is ok for me.
Maybe we can setup a mailman mailing-list and use for each repo the "service hooks" email pointed to our ml to inform in real time all subscribers about all the commits.

[bacicciosat]

I have tested now @github and it seems to work.

[lupomeo/testplugins] 16b036: Update readme
From:
noreply@github.com
To:
xxx@gmail.com
Data:
Today 11:00:26

Branch: refs/heads/master
Home: https://github.com/lupomeo/testplugins

Commit: 16b036b3ff59f0bf5d11a7c7116161628bdff3bc
https://github.com/l...16161628bdff3bc
Author: meo <xxx@gmail.com>
Date: 2011-09-21 (Wed, 21 Sep 2011)

Changed paths:
M README

Log Message:
-----------
Update readme

[skaman]

I've no problem with "all plugins in one repo" or "one repo per plugin". For me it's the same. So as you prefer
I also agree with bacicciosat when he speak about define some "coding guidelines".
I've only one request. Some plugins (in my case i'm speaking about crossepg) already exist. Probabilly it doesn't follow the guidelines but change it now (when around internet there are many scripts/tools/guides) it may make many problems to the final user.
So, if possibile, i'm asking to do some exceptions about existings plugins. And apply the guidelines only with new plugins.

[skaman]

I have tested now @github and it seems to work.

[lupomeo/testplugins] 16b036: Update readme
From:
noreply@github.com
To:
xxx@gmail.com
Data:
Today 11:00:26

Branch: refs/heads/master
Home: https://github.com/lupomeo/testplugins

Commit: 16b036b3ff59f0bf5d11a7c7116161628bdff3bc
https://github.com/l...16161628bdff3bc
Author: meo <xxx@gmail.com>
Date: 2011-09-21 (Wed, 21 Sep 2011)

Changed paths:
M README

Log Message:
-----------
Update readme

This is really usefull. I like it

[bacicciosat]

I've only one request. Some plugins (in my case i'm speaking about crossepg) already exist. Probabilly it doesn't follow the guidelines but change it now (when around internet there are many scripts/tools/guides) it may make many problems to the final user.
So, if possibile, i'm asking to do some exceptions about existings plugins. And apply the guidelines only with new plugins.

Dear skaman i think my post about guidelines was a stupid idea because everyone have his own style and opinion, so it is better to forget it.
Off course i was not talking about crossepg or other important plugins that need special configurations or background functions.
I am sorry for misunderstanding about that post.


But it seems to me that this project is not started and is going to lose interest.

[Sjaaky]

I've been doing some work behind the scenes. It took some time to split our plugin repo to multiple repo's and create new bb's and setup.py's.
I've put 4 repo's online to get some feedback at https://github.com/Sjaaky

The idea is to start one repository for one plugin. For most plugins the easy to use distutils will be used. For more complicated plugins (which use extra standalone c binaries) autotools is used. There is 1 repository with all bitbake recipes. This can be used as an example and be copied into openembedded. Or be integrated into openembedded/recipes as a submodule.

[Sjaaky]

Of course, everything will be moved to the E2 OpenPlugins organization. And it is probably better to prefix every plugin with e2openplugin- as well. What do you think?

[bacicciosat]

Wow Sjaaki, i think all is very good.

[bacicciosat]

about mailing list do you agree Sjaaki ?
It seems to me that Github account don't provide ML creation.
Maybe we can use Source Forge for the ml that provide mailman service.

[skaman]

@sjaaky
It seem ok ... good work
When organization E2 openplugins will be created i'm ready to move crossepg (i hope to find some tool to convert actual svn repo to git without loose commits descriptions).
For any kind of help with startup.. simply ask.. i'm here!

@bacicciosat
For ML with crossepg i used google groups. I created a group for crossepg where every user can register/unregister his mail. And from google code (actual home of crossepg) i setted the main mail of the group as diff recipient.