195 replies to this topic

[hemertje]

http://www.pli-images.org/forum/viewthread.php?forum_id=48&thread_id=19304&pid=215225#post_215225

I think it should be soon a necessity to have a common repository for system and major extensions plugins strictly open sources because of licenses that could limited all the official plugins to be used only on dmm hardware.
There are many teams that could contribute like Pli, Black Hole, Vti, Vix, Sif and so on.
All the teams could have a section in their boards about the project so the plugins should be tested by many users on all the boxes.
I think the man that have the skill and maturity to manage this kind of project are you: pieterg.

Here is a suggestion:

To start a Common Public E2 Plugin repository, the E2 OpenSource Community could start a GitHub account:

https://github.com/

for example with a name like: "E2 OpenPlugins"

Git is an extremely fast, efficient, distributed version control system ideal for the collaborative development of software.
GitHub is the best way to collaborate with others. Fork, send pull requests and manage all your public and private git repositories.
Free public repositories, collaborator management, issue tracking, wikis, downloads, code review, graphs and much more…

Have a look at an example here: https://github.com/Glimpse/Glimpse

Users can make there comments at the sourcode, also post bugs...
Or create a fork themselves, do a pullrequest if they have a functional patch instead of mailing them or posting it at a forum...

With the free public GitHub repositories you will also get an integrated issue tracker and also a wiki!
Also good to have: repository access over https, no issues anymore with firewalls in combination with ssh or git's own protocol...


How to use this together with several external E2 developers or E2 hobby teams?

Every developer has his own github repository for his development of his plugin(s) or so called package(s), where he uses the git flow system.

A good idea is to use a centrall plugin repository, in this repository a fork is located of the master branches of the different repositories.
When there is a new release (which is a merge from a release branch to master, including a tag) it will be set into this fork.

The centrall repository set contains always the latest release of all E2 plugins.


Who controlls these repositories?

The full controll is done by the individual repository developer.
Other developers will fork his repository, and send him a pull request for there updates.
When the main repository developer has a new release ready, he will do an update of his master.

Other external developers or hobby teams don't have more work using this method then to keep there masters in sync, which can be scripted.

[bacicciosat]

Very good hemertje,
This seems the best solution.

But it seems to me a little bit complicated.
Every team and every single developer have to create his own git and i am not sure that this can be a success.
Maybe many ppl have not time or skill to create a git and will not partecipate.
Also I am afraid that this will not help the common contribution but this will cause that every developer will work only to his plugin(s) code.
I prefer a centralized solution. A single (classic) git with a mailing list for developers for each commit notification and subscriptions requests.
I think we need rules (only Gpl and legal plugins are admitted) and a supervisor that check that the rules are respected and the kind of the code committed.
And i think that this supervisor should be pieterg or another Pli developer. This because Pli team have proved experiency, skill and maturity.
But this is only my opinion.
Maybe it should be nice to invite to partecipate to this discussion other team like Vti, Vix Sif and so on to let them opinion about this idea.

[hemertje]

Hello bacicciosat,

thanks for your compliment.

GitHub is a centralized solution, there are only more branches, a developer has his own seperated workbranche and releasebrache, see the example, it's easy to use.
From this releasebranche, plugins can be used as sources for E2 images.

We will and can not be a police officer from a central Plugin Repository, we don't have the free time for it.
It's every developer his own responsibility to create and deliver a proper sourcecode and check that rules are respected as it is allready in everybody's (closed) sourcecode.

Feel free to invite other E2 teams and developers to participate in this discussion.

[Jeroensky]

So when does this start?

Would be incredible nasty to inform all plugin authors with gpl licenses (or just open) plugins.
So not those fools who don't want their plugin on enigma2 from other manufactorer.

[hemertje]

OK, we started the wanted public E2-OpenPlugins repository

This is the link:

https://github.com/O.../E2-OpenPlugins (what's in a name...)

and guess: Everyone is invited!!!


We allready set our OpenPLi plugins into an "Extensions" subdirectory:

https://github.com/O...ster/Extensions

For our OpenPLI developers we created an "OpenPLi organisation".
The developer accounts are set as member of this "OpenPLi" github organisation and after this we add the correct rights (push/pull/admin) to these accounts.

This was all setup in a very limited amount of time, as said before, easy to use

Another option is to set a Twitter or Email notification, even also a wiki or issue tracker.


Please feel free to create a new team, create a new repository for a 'third party plugin' and add the specific developers to your team.
Now you can push your code to the specific repository.

A small howto:
In an organisation you can link repositories to teams.
Team A can have for example pull/push/admin rights, Team B can have pull/push rights, Team C can only pull, and Team D has no rights at all, unless it's a public repository, with a public repository you are allways allowed to pull.

For example it's possible to create the repository "enigma2-plugin-something", link a Team-something where the team members have push rights, same as the core team. The Team-something has no push rights to the other repositories.


It would be great if other E2 hobbyteams or external developers host and commit their GPL plugincode in a centrall repository, let's say a schwerkraft.elitedvb alternative!
So fork your code, commit on your own repositories which everyone can follow.
With some luck other developers and hobbyteams send us some pullrequest so we can follow your development.
We hope that other developers use minimal commits send with a clear message about the changes.


Our goal is to create an unique community of E2 hobbyteams and developers with this as the central place to host and share their E2 plugin code.
If you want us to add your patches into the OpenPLi plugins, just send us a pullrequest.

[bacicciosat]

I don't think this solution can work for the reasons i explained and others (the git is again under team label).
So good luck and my best wishes for your project.

[Jeroensky]

Is it possible that on the new public E2-OpenPlugins repository a button(link) is created to the pluginwiki ( http://www.pli-image...akka=pluginwiki )

So that viewers of that website can navigate to a page with a howto create plugins by themselve.
Just a idea.
p.s. i updated pluginwiki with link to openplugins repository.

[hemertje]

I don't think this solution can work for the reasons i explained and others (the git is again under team label).
So good luck and my best wishes for your project.

Hi bacicciosat,

the thing needs a name, so i made my comment "what's in a name"!!!

we wanted to let others see that it's very easy to setup
you told us above you respected us with our experiency, skill and maturity, so why can't the owner of the public E2 OpenPlugins name be "OpenPLi"???

github works as follows:

a user sets up a repository under his own name, for now it is the user "OpenPLi" that set up the repository "E2-OpenPlugins"
he can switch his name to to whatever he wants

do you want https://github.com/b.../E2-OpenPlugins

fee free to launch ideas of the ownername to invite others to join the E2 public plugin repository

[Sjaaky]

In an organisation you can link repositories to teams.
Team A can have for example pull/push/admin rights, Team B can have pull/push rights, Team C can only pull, and Team D has no rights at all, unless it's a public repository, with a public repository you are allways allowed to pull.

For example it's possible to create the repository "enigma2-plugin-something", link a Team-something where the team members have push rights, same as the core team. The Team-something has no push rights to the other repositories.

It was not my intention to create teams and organize stuff. It's better to let everybody organize themselves.
Github provides everything to do just that. Every team can fork our repo, and continue under their own label (with the touch of 1 button!). Due to github's features everybody's repo will be visible to each other, it will be very easy to follow progress in other repo's. And it will be very easy to send each other pull request if one solved a bug or implemented a new feature.

But opinions differ on the matter how to organize this stuff.

@bacicciosat: If one forks our repo there is a an indication like "bacicciosat/e2-plugins forked from openpli/e2-plugins", will that already be an obstacle?
If the openpli label is inhibiting to others, the only solution is to create a new label. But if we create the label it will still be our label and treated the same by other teams, or not? What are your thoughts about this?

[bacicciosat]

Sorry for my later reply but i was at Vu+ day in Amsterdam.
My friends i think there is a misunderstanding,
I have not problem with Pli name. The goal is not to have a name or label but to work togheter for an objective.
I though in my original suggestion to leave the "team labels" out of this project.
This because i am afraid that until ppl will continue to work under team labels there will be always a kind of clear or hidden competition. In my little and poor opinion the problem of e2 plugins cannot be solved in a team logical perspective because is a common work. Each team have its own plugins. Maybe in this way each team will continue to work only to plugins that he prefer and that are writing for its own image and compatible with own image. I am afraid that using team labels and working under team labels there will be never a real common work.
So i simply think that this way you have used cannot work for the objective to have a real common alternative to e2 plugins official repository.
But I will be happy if i am wrong and it will works and the other teams will join it.

[WanWizard]

This is the idea.

When working with Github, there are basically two models of operation, given the fact that you would like to have a single location for all repositories (to build an image, you want them in a fixed location).

- Have each developer setup his own set of repositories, then have a central repository fork them, and script the sync between the two
- Create a github organisation. For everyone who wants to have a plugin in the central repository, a repository will be created, and the person or persons will get full access to it

The second scenario pervents a complex scripting and synching mechanism, as the individual developers have direct access to a centrally located repository.

What might be a possibility to make it more generic is to rename the Github organisation (now OpenPLi) to something more generic (like E2Plugins).

[hemertje]

Hi bacicciosat,

thx for your reply.

so which universal label do you suggest so that all E2 developers ans hobbyteams are willing to join forces?

why dont you start to push your own and your team plugins into this E2 Plugin Repository to give the example for others!

[bacicciosat]

so which universal label do you suggest so that all E2 developers ans hobbyteams are willing to join forces?
why dont you start to push your own and your team plugins into this E2 Plugin Repository to give the example for others!

At the present i am really busy following many git repos.
All my gits are in a dedicated server and i have two devel groups connected to two mailing lists.
In this way i can follow all the work receiveing in my mailbox all the commits that have done daily.

For this reason too i suggested a single common classic git connected to a mailing list, because in this way should be easy to follow another project.
If we will have many git for each team and/or single developer it will be too much complicated to follow a common work.

About the label i suggest something like E2GPLplugins.

[WanWizard]

I have a feeling you don't completely understand what we are trying to propose here.

This issue with your approach is that there is no central repository.

Everyone does his own thing, and spends his life cherry picking from other projects by looking at diffs in an email. Any dev will tell you that is not 'easy', that is a f'ing nightmare. We have to get rid of the attitude that everyone sits on his own island with a copy of whatever is out there, making his own modifications (but absolutely not contributing these back into the original), and spending half his live with doing merge operations from the original into his own copy. I assume that you, like most devs, prefer to spend your time developing, and not doing repository administration and diff analysis. I certainly do.

And if you work with a single repository, you will have to give 'the world' commit rights, to maintain whatever he wants to put in there. I promise you, that is definately not going to work.

We therefore suggest to setup a central github organisation.

Everyone who wishes to work with this system gets a repository for his plugin under this organisation. The requester/owner will have full admin access to that repository, and no one else. It is the requesters own repository. Anyone who wishes to contribute to this repository (and that can include the owner himself) can fork the repository to his own github account, work with that, and send pull requests to the owner when he wants to contribute. As owner of a repository you get notices from Github of all interactions with the repository. As user of a forked repo, you get notices of all activities on the main repo, so there is a system in place which works a hell of a lot better then emails.

This is the way every organisation works with Github, it is very flexible, allows for maximum collaboration, and gives the repository owner all control over what he will accept in his code or not.

Maybe you should have a look at some of the larger Github organisations, and see how they operate. You will see that it works very efficient, every action is documented, you'll have integrated issue trackers, and full online history to get diffs and blames.

And don't forget, from a users point of view, there is one central place were he can find all E2 GPL'd plugins, which makes the build process easy.

[bacicciosat]

I have a feeling you don't completely understand what we are trying to propose here.

Maybe you are right.
I hope that others teams and developers will understand better than me and this proposal will have success.

[hemertje]

what does your two developerteams say about this?
are they willing to share their sources under GPL?

[bacicciosat]

what does your two developerteams say about this?
are they willing to share their sources under GPL?

I don't understand if this is an attack hemertje.
What do you mean ?
We are not developing e2 system plugins at this moment.
The latest plugins i wrote for e2 are here gpl : http://sourceforge.n...b/e2openplugins

But my original idea was not about extra plugins but about system plugins and official plugins that have to be rewrite because of license problems.

[plnick]

Hi,

I'm not firm with GitHub and I do not know it, yet /images/smiley/smile.gif .

So I have a few questions :

For the plugins there is one GitHub organisation with the "main" repository which can be used as source for the image build process. Under this organisation the developers are team members of the organisation with their own repository ? Is this correct ?

How does it work to merge the developer repositories into the "main" repository, especially for common files like configure.ac or makefiles ?


Like I said before, I do not know GitHub, so excuse me for the stupid question.

[hemertje]

i just thought you were investigating and talking to other teams and developers about joining forces about hosting and sharing E2 code (plugins) of any kind
so i was just curious of your end results of these discussions you had...

[bacicciosat]

i just thought you were investigating and talking to other teams and developers about joining forces about hosting and sharing E2 code (plugins) of any kind
so i was just curious of your end results of these discussions you had...

No hemertje, i am not in touch with other teams.
Maybe i can contact the admin of Sif that is already open source to know if they want to partecipate to your proposal.