195 replies to this topic

[bacicciosat]

@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?

Sjaaky, i think we can use github only if we make the team labeled git and a central general git (without labels).
The central git is the git that can be used as source in enigma2-plugins.bb and need to have at least these 2 rules:
1) Plugins have to be open source under Gpl
2) Plugins have to be generic and compatible with cvs images (and all team images)
I see in your git at github that there are too plugins image dependens and a Pli folder.

I think this structure is not good to use OpenPli as the central repository because it is team dependent.
And it should be not nice for many teams or develop to work under Pli label if they want to be and appear independent.
So finally i see this structure:

-E2-OpenPlugins
|--OpenPli/E2-OpenPlugins
|-- BlackHole/E2-OpenPlugins
|-- Vti/E2-OpenPlugins
|-- Sif/E2-OpenPlugins

and so on...
I think this is better because in this way each team is not under another label and can pull in the central git only the cvs plugins and not the plugin image-dependent
It is ok for me if you will admin the central git (E2-OpenPlugins)

[skaman]

@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?

Sjaaky, i think we can use github only if we make the team labeled git and a central general git (without labels).
The central git is the git that can be used as source in enigma2-plugins.bb and need to have at least these 2 rules:
1) Plugins have to be open source under Gpl
2) Plugins have to be generic and compatible with cvs images (and all team images)
I see in your git at github that there are too plugins image dependens and a Pli folder.

I think this structure is not good to use OpenPli as the central repository because it is team dependent.
And it should be not nice for many teams or develop to work under Pli label if they want to be and appear independent.
So finally i see this structure:

-E2-OpenPlugins
|--OpenPli/E2-OpenPlugins
|-- BlackHole/E2-OpenPlugins
|-- Vti/E2-OpenPlugins
|-- Sif/E2-OpenPlugins

and so on...
I think this is better because in this way each team is not under another label and can pull in the central git only the cvs plugins and not the plugin image-dependent
It is ok for me if you will admin the central git (E2-OpenPlugins)

Hi,
i think this is a great idea and i totally agree with bacicciosat. An "unlabeled" central repository with all plugins compatible with cvs images is really the ideal solution. After that every team could fork the repo and change it for his own image.
A project like that has several benefits:
- The teams could use freely a repo with many plugins "ready to use"
- The users have one place where get informations about plugins and report issues
- The "plugins developers" could publish own plugins in a place with an "high visibility"

I really hope this idea could be real

[bacicciosat]

I really hope this idea could be real

Hi skaman, nice to read you.

So we have 4 teams in this thread now.
This could be a good start.

[hemertje]

4 teams allready? wow nice!

can everyone introduce himself as i dont know everyone!

[bacicciosat]

4 teams allready? wow nice!

can everyone introduce himself as i dont know everyone!

I think we have in this thread
Pli (you)
Bh (me)
Sif (skaman)
Vti (plnick)

[skaman]

4 teams allready? wow nice!

can everyone introduce himself as i dont know everyone!

As bacicciosat said I work on sifteam image.

I don't know how and when we want proceed. But if we all agree i think we have only to do a small chat just to decide how do this work (project registration, users permissions, teams roles, and so on).

Let me know

[hemertje]

4 teams allready? wow nice!

can everyone introduce himself as i dont know everyone!

[bacicciosat]

4 teams allready? wow nice!

can everyone introduce himself as i dont know everyone!

I think we have in this thread
Pli (you)
Bh (me)
Sif (skaman)
Vti (plnick)

[skaman]

4 teams allready? wow nice!

can everyone introduce himself as i dont know everyone!

As bacicciosat said I work on sifteam image.

I don't know how and when we want proceed. But if we all agree i think we have only to do a small chat just to decide how do this work (project registration, users permissions, teams roles, and so on).

Let me know

[andyblac]

just my 2 pennies worth

i think the best idea would a web page of links to open repro's, that way everyone could pull from the git you want, (like pli do with our Magic git, and i do from them) this way all you have to do is maintain your own git and just merge what you want from the others at your own time. i do not want the latest and greatest from the main git as things break from time to time, i want to be in control when i pull/merge.

that is why in my opinion having one repro for all plugins will not work. and i will not use it for that reason.

a list of public gits is a far better solution, then everyone can just take a branch of the gits they want, and merge it into there own. and they then if they want part form your branch they can just cherry pick it back into there's, again like pli do with our git.

just my opinion.

Andy.

[andyblac]

another main concern is that everyone with write access to the git would have write access to everyone's plugin's wouldn't they ?

and not all images work the same, some have core fictions in E2 that others don't have, so you would have to take a branch and code arround the issue, so another reason having 1 plugin git does not make much sense.

surely it would be best to just have a website that has a list of open git's that everyone can pull and merge from.

i am all for open plugin's it just how best to maintain it.

andy.

[Sjaaky]

@andyblac: That is a very valid point.

But I guess there has to be some effort by plugin makers to create image independent plugins and put them in a central repository. The image specific stuff should be located in a team branch.
The central repo should make sure the plugins are image independent and usable for other images. So an update of the plugins should just be an effortless 'git pull' to a team specific repo most of the time.

Otherwise situations like these will probably be common. Team A introduces a new feature. Team B notices a bug and fixes it in their repo. If team A didn't notice the effort of team B they might also fix the bug in a different way somewhat later. Now every team has a merge conflict when pulling from A and B and needs to understand the issue before they can correctly solve them. It might be a simple solution but it will at least take some effort.

Imho it is better to centralize the effort into one central repo so sources will not diverge.

@bacicciosat: I renamed the PLi directory to Extensions so that shouldn't be a problem. There are some PLi strings in the autobackup and in PPanels though that I forgot to adjust.

[Sjaaky]

another main concern is that everyone with write access to the git would have write access to everyone's plugin's wouldn't they ?

I don't see that as a real concern. We're all professionals with good intentions. Someone has to earn write access. And if someone deliberately keeps pushing erroneous stuff, he/she should be denied write access.

A list of open source repositories would sure be of value right now.

[WanWizard]

In the proposed solution that is not true.

In a github organisation, every repository in that organisation has (or can have) it's own team structure, and access rights. It is nothing more than a central collection of everyone's personal repositories.

Instead of everyone using copies of everyone else's repository, or (even worse) merging everyone's repository into their own, I propose that only a single repository is used for any given plugin or application. Stages of development can be reflected in branches, different releases using tags. Or implement git-flow, which has a clear definition of all development stages.

Everyone here still has his mind fixed on "my repo" and "my code". It is my opinion that you should not fix things in your own repo, in your own copy of the code, you should send the developer of the plugin who runs the original repo a pull request. And when accepted, everyone immediately benefits from the fixed bug. Now all developers run into the same bugs, and all of them fix it independently of each other. In my opinion, that is a waste of time. One could have fixed it, the others could have spent their time making new features (or fixing other things).

This is how open source works, and this is how great open source projects become greater.

If everyone keeps working the way they are now, five years from now we're still stuck with the current enigma, only with some nuts and bolts stuck to it. Because everyone is constantly busy with re-inventing wheels, cherry picking, merging, fixing merge conflicts, fixing code that no longer works after all of they above, etc. When was the last time you could for some time work on a new killer feature, uninterrupted, without being distracted by those housekeeping duties that bring nothing new to the table?

[bacicciosat]

@bacicciosat: I renamed the PLi directory to Extensions so that shouldn't be a problem. There are some PLi strings in the autobackup and in PPanels though that I forgot to adjust.

Sjaaki i think that there is still a logical inversion.
Now i see that we have:
Main: OpenPli/E2OpenPlugins
fork: Sjaaky/E2OpenPlugins forked from OpenPli/E2OpenPlugins

But i think it should be:
Main: E2OpenPlugins
fork: OpenPli/E2OpenPlugins forked from E2OpenPlugins
fork: BlackHole/E2OpenPlugins forked from E2OpenPlugins
and so on...

This because I think we have not to ask to others to appear like an OpenPli fork.
We have here skaman that is coder of Sif but the author of known cross-epg plugin too.
And we should have other teams or single developers that will join in the future.
As i told i fully trust in you and pieterg so it is ok for me that you admin the main repo.
But is seems to me more logical and more appealing for others to switch to this solution.

[bacicciosat]

I propose that only a single repository is used for any given plugin or application.

Ehh ?? back to single repository ? a git for every plugin ? all is changed ?
WanWizard i think you want to drive me crazy /images/smiley/shock.gif

[Sjaaky]

But i think it should be:
Main: E2OpenPlugins
fork: OpenPli/E2OpenPlugins forked from E2OpenPlugins
fork: BlackHole/E2OpenPlugins forked from E2OpenPlugins
and so on...

That's a clear answer. I think this is the best structure. Everyone participating must push valuable, team independent stuff to the main repo regularly. Otherwise the central repo is of no added benefit compared to the current, decentralized situation.

I guess we should start a new github organization called e2openplugins and give everyone in this thread all access rights.

[bacicciosat]

But i think it should be:
Main: E2OpenPlugins
fork: OpenPli/E2OpenPlugins forked from E2OpenPlugins
fork: BlackHole/E2OpenPlugins forked from E2OpenPlugins
and so on...

That's a clear answer. I think this is the best structure. Everyone participating must push valuable, team independent stuff to the main repo regularly. Otherwise the central repo is of no added benefit compared to the current, decentralized situation.

I guess we should start a new github organization called e2openplugins and give everyone in this thread all access rights.

Ok for me, i agree.

[plnick]

Hi,

I'm not firm with GitHub and I do not know it, yet .

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.

/images/smiley/shock.gif ?

for the rest: fullack with @bacicciosat suggestions

[Sjaaky]

@plnick: You do know git, I suppose?