195 replies to this topic

[plnick]

Yes I know git and working with git but not working with github and organisations, members and access rights. The main question for me is how to merge common files like configure.ac into main repository without having write access in main repository ?

[pieterg]

we might want to avoid DYNAMIC_PACKAGES alltogether, and give every plugin its own configure.ac?
bb files with dynamic packages are really terrible, especially when you want to tweak plugin dependencies, descriptions etc.

[plnick]

Ok, but at the moment there is one configure.ac at e2openplugins. so this will change in future ?

[pieterg]

that's just an example, we have to decide what we think is most convenient.

[plnick]

ok, I think this is a good idea with avoiding package dynamics

[WanWizard]

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

Why? What does it matter where your build script pulls it's source from?

It is the most clean solution, and avoids all the cherry pick and merge misery that most of us spend the majority of our precious development time on.

[bacicciosat]

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

Why? What does it matter where your build script pulls it's source from?

It is the most clean solution, and avoids all the cherry pick and merge misery that most of us spend the majority of our precious development time on.

I was joking.
You have to be a little patience with me and others that don't know github yet.
We need to take confidence to understand all the capabilities.

[WanWizard]

Ah, ok. /images/smiley/more_happy/21.gif

I use Github for serveral large projects.

One we've started late last year already has over 50 people contributing through pull requests. We also use the issue tracker heavily, both for bug reports (which you can classify), for work in progress and for roadmap/feature requests, including milestone definitions.

I'm very pleased with the way it works.

[bacicciosat]

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

Ok i have an account at github (lupomeo) and i created organization BlackHole to fork the main repo.
Right ?

[skaman]

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

Ok i have an account at github (lupomeo) and i created organization BlackHole to fork the main repo.
Right ?

I did the same thing. I've a user called "skaman" and an organization called "SIFTeam" for the fork.

[plnick]

I also created an organisation openvti.

My user account is plnick

[bacicciosat]

I'm very pleased with the way it works.

I just took a glance and i start to understand your enthusiasm. It seems that github offers really interesting features.

@Sjaaki: i think we are ready. When you will create the main repo we will fork and start to commit.

[Sjaaky]

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.

[bacicciosat]

Ok.
Maybe we need a kind of basically rules for ppl that want to join.
Something like:
- license type (Gpl only)
- no binaries files
- no illegal stuffs

I don't like to spend time in these details but they are often needed to prevent future problems.

[Sjaaky]

Good point. Those rules may seem obvious now, but may save some trouble later on.

[littlesat]

I want to add another rule... no tmpd challanges....

[bacicciosat]

Because i have seen horrible plugins that use to run in background or to put config files everywhere maybe we can adopt a little coding best practice too.
Like for example:

- Plugins have to live and die in their own context.
- Autostart functions and background running files are allowed only when it is strictly necessary
- All plugins files have to stay in plugin tree
- It is highly recommended to use standard subdirs names as follow:
-- "cfg" for all configuration files
-- "pskin" for all plugins skin and graphics files

[ozkaradag]

Excellent idea.

Wowww.

Regards...

[bacicciosat]

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.

I understand your point of view and your connection with git Pli but i think we are in a different context.
I think our plan (but have we a plan ?) is not to share our images sources or our image dependent plugins.
I think our plan is to build a Gpl plugins repository available for all sat community. Free to use for all machines and without any limitation like license restrictions, tpm checks and so on. In this perspective i don't think is such important to have separate and "team labeled" gits.

In this perspective to reach so ambitious objective i think that our work have to be as common as possible.
just my two cents.

[Mamba0815]

All,

this definitively is a move into the right direction. Thumbs up! /images/smiley/more_happy/21.gif

I'd suggest to be rather quick with a first set of rules -or let's better say guidelines- in order to avoid later discussions when they get implemented too late. Often ideas like this one stumble because of minor things in the guideline definition.

Other than that: off the teams go!

Mamba