Hi,

On Sun, Mar 23, 2014 at 12:04 PM, Sam Gleske wrote:

Reference - https://github.com/jenkinsci

So recently I've been introduced to the way Jenkins CI does development and progression of the platform. I decided to write a plugin for Jenkins and so I hopped over to their IRC channel to discuss with them about it. First thing they did was make me a member of the org.

Basically they have two organizational teams: Owners (consists of core devs) and Everyone.

By making me a member of the Everyone group I got commit access to all 1000+ repositories associated with Jenkins plugins. I can freely contribute to any one of them. However, I don't have commit access to the core Jenkins repository which is the main application of the whole platform. I think this model is really cool. Because basically when you first commit a pull request the jenkinsadmin bot will tell you how the pull requests work.

Here is a pull request as an example [1]. The Jenkins admin posted a comment stating that the pull requester should read the link on pull requests [2]. I think this is cool. It's basically a policy that if any plugin goes unnoticed pipe up and become a contributor with commit access to the organizations.

Right now, GIMP has a place for users to dwonload plugins... but there is no place where the source code of all of the plugins live and be maintained.

We have the core plugins (the ones released together with GIMP) versionned already and their source lives in the main source tree, with GIMP itself.
Now maybe you are speaking about the user-contributed plugins, that anyone can upload on registry.gimp.org. The current status on this is that apart from providing a subdomain for conveniency, we have basically no control and no verification whatsoever over whatever users upload.

Note that providing a whole infrastructure to check plugins, source versioning to third-party plugin devs, and such things would be great. I actually wish to kickstart such a project some day, hopefully (see for instance the project I was proposing if we had been accepted as mentoring org in this year gsoc:
http://wiki.gimp.org/index.php/User:Jehan/Hacking:GSoC/2014/Ideas#Create_a_plugin_management_framework ).

But the real current status is that these third-party plugins are just completely outside of our control. And we certainly don't have the man-force right now to do otherwise anyway. So the wish of us keeping their source code somewhere is irrelevant here.

I went looking for the GIMP repository on github (it's nice that there is one!) however it seems sadly buried in the GNOME project repositories.

Yes this is only a mirror of our main repository hosted on the GNOME servers.

I propose GIMP developer team take the initiative to create an organizational account at github and form teams similar to Jenkins. 1. Owners whom are the only ones with commit access to the GIMP core but can still accept pull requests from outsiders. And 2. an Everyone group in which anybody who asks gets commit access to all of the plugins in the organization area.

I personally completely downvote this proposition. I have already given my opinion about github a few times, and I'll give it again: this is just a service provided by a company like there had been dozens by the past and like there will be dozens more in the future. They just come and go (look at sourceforge, it used to be the big deal, now everyone flees the sinking stinky boat). Relying on this kind of service is not sustainable, unless we just can't afford hosting ourselves (like individuals, I may understand them using services for conveniency). But we can afford it (through GNOME), so why care?

Also basically that's not good for independence. These commercial services always have complicated and terrible contracts that nobody ever reads and that they just change whenever they feel like tightening the grip a little more. We can't forget they are companies whose goal is hence money. So I really prefer never having to rely on them. Using them as mirror (a big strength of git) for profiting of network effect? Fine. Using it as backup? Fine. But that's it.

Finally I used to use github when employed in a startup for a few years. Well I really couldn't see the big idea. It is nice but it has nothing else that we don't do otherwise as simply. Except that it does it all in a browser, which makes it very annoying in my opinion. Worse, projects there would likely limit themselves to whatever github proposes. Being on our own allows us to go much further and make our own adapted tools.

I think this would spice up and breath development life into the GIMP project. GIMP is much more than just gnome and I think the barrier to entry to developing on GIMP should be so low you can trip over it. Jenkins does that well and I feel like by immediately being made a committer to all of the plugins repositories it makes me want to jump up and start contributing everywhere in Jenkins.

I don't understand why anyone would say this. I've had access to the repository pretty quickly after my first patches. Of course that does not allow me to commit big patches without maintainer agreement (and I do hope that having write access on Jenkins repo does not mean either that they let you commit anything you wish). But that happened quite fast after I contributed a few patches through Bugzilla.

There's a few reasons for that... 1) I feel like I'm visiably part of the development process and have been acknowledged.

Provide a few patches to us, and if they are good and regular, I can certify you that you will be acknowledged very soon and be given commit rights there too. That's how it happened for me without even asking.
Have you contributed any patch yet? If you have any, do not hesitate! We welcome good patches. :-)

Though once again, if you are only interested in contributing to third-party plugins, we don't control them. They are different projects based on GIMP (see GIMP as a platform). Get directly in touch with these developers, not us.

2) I have a shiny cool Jenkins organization badge on my github user [3].

Well for this, no, you won't have. Do you really need "shiny" badges to feel better about your contributions? I don't want to judge, but isn't it a little silly? If you really need this, isn't some random social network better for this than Free Software?

3) I think it's great that my friends and coworkers can blatantly see that I have at some point or will continue to contribute to the Jenkins project because the organizational badge is displayed on my profile.

Again, what's the point? I really think that priorities might be slightly messed up there.

Yet as said before, you will be acknowledged. You will have commits with your name as committer in our repository, your name will be listed in release notes on gimp.org. You can link your friends there if you really want them to see a proof you contributed to GIMP.

GitHub makes coding and contributions fun. I would love to have a GIMP organizational badge in my profile. I'm learning C++ in hopes to contributing to GIMP [4] with more than just recommendations or the mailing list.

GIMP is coded in C, not in C++. :-)

Developers and contributors, tell me your thoughts. I hope you get as fired up about this as I feel.

All done above. :-)
Sorry for not being "fired up", but I strongly say *no*, and I feel other devs will as well.

Jehan

SAM

[1]: https://github.com/jenkinsci/findbugs-plugin/pull/5 [2]:
https://wiki.jenkins-ci.org/display/JENKINS/Pull+Request+to+Repositories [3]: https://github.com/sag47
[4]: https://github.com/sag47/cplusplus _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

Hi Sam,

thank you for your suggestion! It comes at just the right time, because speaking on how we can improve our development process to be more attracting to new contributors is one point on our LGM meeting agenda.

Indeed, the Jenkins project has some points we can learn from, such as what you wrote and secondly the release process. They manage it to release two products (the rolling release and an LTS release) regularly.

On 23.3.2014 at 12:04 AM Sam Gleske wrote:

Right now, GIMP has a place for users to dwonload plugins... but there is no place where the source code of all of the plugins live and be maintained.

... and the GIMP plug-in registry is only one place among others (forums, private sites, DeviantArt etc.) We're currently reconsidering possibilities to install plug-ins and assets from within the application easily. Having the source code at the same registry site next to binaries for various platforms (at least the most often used) would IMHO be a win.

I went looking for the GIMP repository on github (it's nice that there is one!) however it seems sadly buried in the GNOME project repositories.

Because it's a GNOME project ;-)
One trick: finding a particular project in GNOME's Git repository is as easy as at GitHub: The URL is always https://git.gnome.org/browse/${project name}

I propose GIMP developer team take the initiative to create an organizational account at github and form teams similar to Jenkins.

The GNOME project mirrors its repositories to Github. You can find the GIMP subpage here: https://github.com/GNOME/gimp However, to attract more contributors and benefit from more contributions, we should have an eye on the pull requests there.

Leaving the GNOME project and going our own way is IMHO not the right way as there are many points where we our both projects give and take to/from each other to our both benefit.

I'm learning C++ in hopes to contributing to GIMP [4] with more than just recommendations or the mailing list.

That's nice that you take this initiative. GIMP and GEGL are developed in C with the object orientation of [GObject]. Also the Babl library we rely on is in C.
If you like it tricky there are also the Autotools and their M4 language. We use them in our build processes but they are hard to understand and often full of mystery. Having an expert here who can either give a founded advice on better build tools (CMake, Maven, etc.?) or can help using the Autotools' potential better would IMHO be a big help.
For your first steps let me point you to our [developer wiki], especially the 'Developer information' section. And as always you find us at #gimp in IRC and here on the mailing list for asking :-)

Kind regards,

Sven

[GObject]: https://developer.gnome.org/gobject/stable/

[developer wiki]: http://wiki.gimp.org/index.php/Main_Page