Hi all,
For the tl;dr crowd: https://github.com/geany
And now for the long version :)
I've setup Geany as an organization on Github.com[1]. I've also setup an empty repository[2] for when the SVN conversion is ready to push.
I will try and explain how this works because it's a little bit complicated at first glance.
To create an Organization, you first need to create a personal account. The personal account can't have the same name as the Organization. After the personal account is created, you convert it into an Organization which is almost a separate entity but is in some ways tied to the personal account.
The personal account I created to do this is called 'geanyadmin' (to avoid clashing with the Organization name).
Once the organization is created, you can add "Owners" to it. Owners have the exact same access as the 'geanyadmin' user, for example, an owner could theoretically sign up the Geany organization to a pay account, the Owners have wide-open access to everything. Basically there's no real reason to ever use the 'geanyadmin' account as far as I can see, once Owners are added to the Organization.
Just to start, because I had their Github usernames, I've added Enrico and Colomban as owners, as well as myself since I need access to set the stuff up. Whoever else should be an Owner (Frank, Nick, etc.) just let me (or other Owners) know. Read below as for why not too many people really need to be "Owners".
Now with an Organization, and some Owners who are able to administer the Organization, we come to Teams. Teams are groups of users who all have the same permissions on one or more repository. Teams can be setup to have Pull Only, Pull and Push, and Pull, Push and Administer access.
Just to give an example, we'll take the 'geany' repository which will be the main Geany core repository. We could add a team for "Core Developers", this group of users could be the existing people with commit access to SVN. In fact I've already created this team, with all 3 permissions mentioned above, and since I had their Github usernames, I've added Colomban and Enrico to this group.
Now, what we could do, for example, is to create another Team called "Contributors" or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the "Contributors" Team, since I contribute a fair bit, but I don't have commit access.
Another Team could be called "Translators", and have one of the three levels of access control mentioned above, and it could be for all the Geany repositories, since translators likely work on both Geany and Geany-Plugins. Another Team could be "Newsletter Writers" or something and they could have perhaps Push and Pull access on the "newletters" repository only.
For starting, I suggest the following Teams:
- Core Developers (Pull/Push/Admin) - Core Contributors (Pull) - Plugin Developers (Pull/Push) - Plugin Contributors (Pull) - Translators (Pull/Push? or does it go through Frank?) - on both geany and plugins repositories? - Newsletter Editors (Pull/Push on newsletters repo)
Keep in mind that any Github user can be in as many of the above Teams as needed, and we can create any? amount of teams, these are just some suggestions.
So anyway, I hope that makes things a bit clear. Just to sum up some key points:
* Colomban and Enrico currently have complete access to the geany organization and can do anything at all, including adding other Owners or Teams or Team members, etc.
* The geanyadmin user is mostly useless, except maybe for setting up some service hooks and things like that.
* I will give Colomban the password for the geanyadmin account. I can still help with setting up on Github since my own personal account is setup as an Owner (thought not with commit access on the geany repository).
* On Github, the icon for the geany Organization, as well as the geanyadmin can only be show if their email addresses are attached with a Gravatar account. To avoid forcing anyone else to sign up for this service, and since I already had an account, I've setup the emails under my Gravatar account. All it does is link team@geany.org to the Geany logo I uploaded. The geanyadmin icon is coming from my Gravatar account, attached with matt@geany.org (just for the Gravatar, not for the accounts actual email address).
* We need everyone's Github usernames so we can add them as appropriate (this won't be my call). I suggest the existing SVN committers get same access as before, and for now, all others go into a Pull Only Team. Anyone besides the core devs/committers should also give their Github usernames so they can be added, with Pull Only permissions, as Team members and be "associated" with the organization (at least this is my understanding).
And now I have a question; now that Geany and Geany Plugins are grouped together under the same organization, should we drop the geany- prefix on the plugins repository?
This would give us the following repositories to start:
- geany - plugins - newsletter - talks (?)
Comments, questions, and slander are welcome. And don't forget to give me your Github usernames!
Cheers, Matthew Brush
[1] https://github.com/geany [2] https://github.com/geany/geany
On 07/10/2011 16:28, Matthew Brush wrote:
Just to start, because I had their Github usernames, I've added Enrico and Colomban as owners, as well as myself since I need access to set the stuff up. Whoever else should be an Owner (Frank, Nick, etc.) just let me (or other Owners) know. Read below as for why not too many people really need to be "Owners".
I've now created an account, ntrel.
And now I have a question; now that Geany and Geany Plugins are grouped together under the same organization, should we drop the geany- prefix on the plugins repository?
I would keep geany-plugins to show it's the g-p release, e.g. not core plugins.
On Fri, 07 Oct 2011 16:40:46 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
And now I have a question; now that Geany and Geany Plugins are grouped together under the same organization, should we drop the geany- prefix on the plugins repository?
I would keep geany-plugins to show it's the g-p release, e.g. not core plugins.
I agree for the same reasons.
Cheers, Frank
On Fri, 7 Oct 2011 19:25:42 +0200, Frank wrote:
On Fri, 07 Oct 2011 16:40:46 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
And now I have a question; now that Geany and Geany Plugins are grouped together under the same organization, should we drop the geany- prefix on the plugins repository?
I would keep geany-plugins to show it's the g-p release, e.g. not core plugins.
I agree for the same reasons.
Same here.
Regards, Enrico
Am 07.10.2011 17:28, schrieb Matthew Brush:
Hi all,
For the tl;dr crowd: https://github.com/geany
Really awesome work! I can't wait for the git switch!
Now, what we could do, for example, is to create another Team called "Contributors" or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the "Contributors" Team, since I contribute a fair bit, but I don't have commit access.
Man, give this man commit access already!
You've done so much invaluable work for this project, you well deserved it.
Another Team could be called "Translators", and have one of the three levels of access control mentioned above, and it could be for all the Geany repositories, since translators likely work on both Geany and Geany-Plugins. Another Team could be "Newsletter Writers" or something and they could have perhaps Push and Pull access on the "newletters" repository only.
Translators could have push access only to the directory where the translation files are in. But I dont think github can do this?
Comments, questions, and slander are welcome. And don't forget to give me your Github usernames!
I don't think it's relevant, but you asked for it: kugel- :)
Best regards.
On 07/10/2011 17:55, Thomas Martitz wrote:
Now, what we could do, for example, is to create another Team called "Contributors" or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the "Contributors" Team, since I contribute a fair bit, but I don't have commit access.
Man, give this man commit access already!
You've done so much invaluable work for this project, you well deserved it.
I agree, I support Matthew joining the core team.
On 8 October 2011 04:00, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/10/2011 17:55, Thomas Martitz wrote:
Now, what we could do, for example, is to create another Team called "Contributors" or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the "Contributors" Team, since I contribute a fair bit, but I don't have commit access.
Man, give this man commit access already!
You've done so much invaluable work for this project, you well deserved it.
I agree, I support Matthew joining the core team.
+1
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Sorry for spam, forgot to say github account is the usual elextr
Cheers Lex
Le 07/10/2011 19:00, Nick Treleaven a écrit :
On 07/10/2011 17:55, Thomas Martitz wrote:
Now, what we could do, for example, is to create another Team called "Contributors" or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the "Contributors" Team, since I contribute a fair bit, but I don't have commit access.
Man, give this man commit access already!
You've done so much invaluable work for this project, you well deserved it.
I agree, I support Matthew joining the core team.
I second this if he wants to :) So Matthew, do you want to become core developer ?
Cheers, Colomban
On 11-10-10 11:52 AM, Colomban Wendling wrote:
Le 07/10/2011 19:00, Nick Treleaven a écrit :
On 07/10/2011 17:55, Thomas Martitz wrote:
Now, what we could do, for example, is to create another Team called "Contributors" or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the "Contributors" Team, since I contribute a fair bit, but I don't have commit access.
Man, give this man commit access already!
You've done so much invaluable work for this project, you well deserved it.
I agree, I support Matthew joining the core team.
I second this if he wants to :) So Matthew, do you want to become core developer ?
Sure! That would be great!
Thanks guys, Matthew Brush
On Fri, 07 Oct 2011 08:28:04 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Just to start, because I had their Github usernames, I've added Enrico and Colomban as owners, as well as myself since I need access to set the stuff up. Whoever else should be an Owner (Frank, Nick, etc.) just let me (or other Owners) know. Read below as for why not too many people really need to be "Owners".
Mine is frlan
On Fri, 07 Oct 2011 08:28:04 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Another Team could be called "Translators", and have one of the three levels of access control mentioned above, and it could be for all the Geany repositories, since translators likely work on both Geany and Geany-Plugins. Another Team could be "Newsletter Writers" or something and they could have perhaps Push and Pull access on the "newletters" repository only.
For starting, I suggest the following Teams:
- Core Developers (Pull/Push/Admin)
- Core Contributors (Pull)
- Plugin Developers (Pull/Push)
- Plugin Contributors (Pull)
Please leave the geany-plugins out for the moment. As mentioned before I'm thinking of using a different system due to bigger number of continious contributors and 'subsystems' as we have defined the plugins in past.
Cheers, Frank
On Fri, 07 Oct 2011 08:28:04 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
- Translators (Pull/Push? or does it go through Frank?)
- on both geany and plugins repositories?
Its hard to say as the experience of translations providers differs much. Some of them never did use poedit or something before, others are real experinced experts on git/mercurial/svn etc. Personal I'd say for the start we should do it via pull requests from personal repos and see how it works.
Cheers, Frank
On Fri, 7 Oct 2011 19:23:32 +0200, Frank wrote:
On Fri, 07 Oct 2011 08:28:04 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
- Translators (Pull/Push? or does it go through Frank?)
- on both geany and plugins repositories?
Its hard to say as the experience of translations providers differs much. Some of them never did use poedit or something before, others are real experinced experts on git/mercurial/svn etc. Personal I'd say for the start we should do it via pull requests from personal repos and see how it works.
Maybe this is the point to throw Transifex[1] into the discussion. AFAIK it's a web-based translation platform which enables users with less technical experience to easily translate software. Transifex can commit changes to .po files back into GIT and so makes it even more easy.
Xfce uses it since some time successfully now.
It would probably require some initial efforts but I could imagine it's worth in the long-term by making the whole translation process faster, easier and maybe even more continous.
[1] https://www.transifex.net/start/
Regards, Enrico
On Sat, 8 Oct 2011 00:32:54 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 7 Oct 2011 19:23:32 +0200, Frank wrote:
On Fri, 07 Oct 2011 08:28:04 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
- Translators (Pull/Push? or does it go through Frank?)
- on both geany and plugins repositories?
Its hard to say as the experience of translations providers differs much. Some of them never did use poedit or something before, others are real experinced experts on git/mercurial/svn etc. Personal I'd say for the start we should do it via pull requests from personal repos and see how it works.
Maybe this is the point to throw Transifex[1] into the discussion. AFAIK it's a web-based translation platform which enables users with less technical experience to easily translate software. Transifex can commit changes to .po files back into GIT and so makes it even more easy.
Xfce uses it since some time successfully now.
It would probably require some initial efforts but I could imagine it's worth in the long-term by making the whole translation process faster, easier and maybe even more continous.
Looks nice. And I got this (changing something on system for translations) for >1 year on my todo list. Another suggestion for collab tools? (launchpad is not an option ;) )
Cheers, Frank
Hi,
Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff?
IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this?
Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly?
Cheers, Matthew Brush
Le 16/10/2011 12:07, Matthew Brush a écrit :
Hi,
Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff?
IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this?
Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly?
AFAIK, currently translated strings should be OK as far as we set the correct gettext domain to GtkBuilder (using gtk_builder_set_translation_domain()).
The key point is to extract the translatable strings and merge them, and I think recent versions of intltool works with GtkBuilder files (not sure which). No guarantee from me though :-'
Cheers, Colomban
On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote:
Le 16/10/2011 12:07, Matthew Brush a écrit :
Hi,
Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff?
IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this?
Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly?
AFAIK, currently translated strings should be OK as far as we set the
Well, I just checked po/POTFILES.in and there is src/interface.c listed, so this one is used for picking the translatable strings. And in po/POTFILES.skip geany.glade is explicitly listed to not be used for translatable strings with a comment that intltool would use it otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will work fine for intltool as well.
Regards, Enrico
On 11-10-18 10:43 AM, Enrico Tröger wrote:
On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote:
Le 16/10/2011 12:07, Matthew Brush a écrit :
Hi,
Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff?
IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this?
Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly?
AFAIK, currently translated strings should be OK as far as we set the
Well, I just checked po/POTFILES.in and there is src/interface.c listed, so this one is used for picking the translatable strings. And in po/POTFILES.skip geany.glade is explicitly listed to not be used for translatable strings with a comment that intltool would use it otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will work fine for intltool as well.
Cool!
Apparently by default gtk_builder_set_translation_domain() uses gettext(), so are we all set then or do we need to set this to something else?
Cheers, Matthew Brush
On Tue, 18 Oct 2011 13:51:03 -0700, Matthew wrote:
On 11-10-18 10:43 AM, Enrico Tröger wrote:
On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote:
Le 16/10/2011 12:07, Matthew Brush a écrit :
Hi,
Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff?
IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this?
Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly?
AFAIK, currently translated strings should be OK as far as we set the
Well, I just checked po/POTFILES.in and there is src/interface.c listed, so this one is used for picking the translatable strings. And in po/POTFILES.skip geany.glade is explicitly listed to not be used for translatable strings with a comment that intltool would use it otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will work fine for intltool as well.
Cool!
Apparently by default gtk_builder_set_translation_domain() uses gettext(), so are we all set then or do we need to set this to something else?
I don't think we need something else. Just needs to be tested.
Regards, Enrico
Le 18/10/2011 22:51, Matthew Brush a écrit :
On 11-10-18 10:43 AM, Enrico Tröger wrote:
On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote:
Le 16/10/2011 12:07, Matthew Brush a écrit :
Hi,
Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff?
IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this?
Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly?
AFAIK, currently translated strings should be OK as far as we set the
Well, I just checked po/POTFILES.in and there is src/interface.c listed, so this one is used for picking the translatable strings. And in po/POTFILES.skip geany.glade is explicitly listed to not be used for translatable strings with a comment that intltool would use it otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will work fine for intltool as well.
Cool!
Apparently by default gtk_builder_set_translation_domain() uses gettext(), so are we all set then or do we need to set this to something else?
Yep, it's enough for using the translated strings. We just need to make sure the strings are properly extracted from the .ui file (by intltool) so they new ones can be translated.
On Tue, 18 Oct 2011 23:01:02 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 18/10/2011 22:51, Matthew Brush a écrit :
On 11-10-18 10:43 AM, Enrico Tröger wrote:
On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote:
Le 16/10/2011 12:07, Matthew Brush a écrit :
Hi,
Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff?
IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this?
Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly?
AFAIK, currently translated strings should be OK as far as we set the
Well, I just checked po/POTFILES.in and there is src/interface.c listed, so this one is used for picking the translatable strings. And in po/POTFILES.skip geany.glade is explicitly listed to not be used for translatable strings with a comment that intltool would use it otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will work fine for intltool as well.
Cool!
Apparently by default gtk_builder_set_translation_domain() uses gettext(), so are we all set then or do we need to set this to something else?
Yep, it's enough for using the translated strings. We just need to make sure the strings are properly extracted from the .ui file (by intltool) so they new ones can be translated.
In general this should work. I suggest to start the glade3 thing and after we can adjust the i18n stuff. I don't expect that at this point a complete rework will be needed.
Cheers, Frank
On Friday 07 October 2011 06:32:54 pm Enrico Tröger wrote:
Maybe this is the point to throw Transifex[1] into the discussion. AFAIK it's a web-based translation platform which enables users with less technical experience to easily translate software. Transifex can commit changes to .po files back into GIT and so makes it even more easy.
In the last few months, abiword has started to use Pootle for its translations. I know nothing about it (nor about Transifex), but if you are going to consider going to something new, you might want to consider several alternatives.
Randy Kramer
On Fri, Oct 7, 2011 at 17:28, Matthew Brush mbrush@codebrainz.ca wrote:
Hi all,
For the tl;dr crowd: https://github.com/geany
And now for the long version :)
I've setup Geany as an organization on Github.com[1]. I've also setup an empty repository[2] for when the SVN conversion is ready to push.
I will try and explain how this works because it's a little bit complicated at first glance.
To create an Organization, you first need to create a personal account. The personal account can't have the same name as the Organization. After the personal account is created, you convert it into an Organization which is almost a separate entity but is in some ways tied to the personal account.
The personal account I created to do this is called 'geanyadmin' (to avoid clashing with the Organization name).
Once the organization is created, you can add "Owners" to it. Owners have the exact same access as the 'geanyadmin' user, for example, an owner could theoretically sign up the Geany organization to a pay account, the Owners have wide-open access to everything. Basically there's no real reason to ever use the 'geanyadmin' account as far as I can see, once Owners are added to the Organization.
Just to start, because I had their Github usernames, I've added Enrico and Colomban as owners, as well as myself since I need access to set the stuff up. Whoever else should be an Owner (Frank, Nick, etc.) just let me (or other Owners) know. Read below as for why not too many people really need to be "Owners".
Now with an Organization, and some Owners who are able to administer the Organization, we come to Teams. Teams are groups of users who all have the same permissions on one or more repository. Teams can be setup to have Pull Only, Pull and Push, and Pull, Push and Administer access.
Just to give an example, we'll take the 'geany' repository which will be the main Geany core repository. We could add a team for "Core Developers", this group of users could be the existing people with commit access to SVN. In fact I've already created this team, with all 3 permissions mentioned above, and since I had their Github usernames, I've added Colomban and Enrico to this group.
Now, what we could do, for example, is to create another Team called "Contributors" or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the "Contributors" Team, since I contribute a fair bit, but I don't have commit access.
Another Team could be called "Translators", and have one of the three levels of access control mentioned above, and it could be for all the Geany repositories, since translators likely work on both Geany and Geany-Plugins. Another Team could be "Newsletter Writers" or something and they could have perhaps Push and Pull access on the "newletters" repository only.
For starting, I suggest the following Teams:
- Core Developers (Pull/Push/Admin) - Core Contributors (Pull) - Plugin Developers (Pull/Push) - Plugin Contributors (Pull) - Translators (Pull/Push? or does it go through Frank?) - on both geany and plugins repositories? - Newsletter Editors (Pull/Push on newsletters repo)
Is there any reason for creating teams with pull rights only (core contributors, plugin contributors, ...)? The whole world should have pull rights so making a team for them seems unnecessary to me unless there's some other advantage.
Cheers, Jiri
On 11-10-08 03:38 AM, Jiří Techet wrote:
Is there any reason for creating teams with pull rights only (core contributors, plugin contributors, ...)? The whole world should have pull rights so making a team for them seems unnecessary to me unless there's some other advantage.
There maybe some additional notifications and stuff (ex. watching a Team) but I'm not too sure. For the most part, I just thought it would be nice to have all the people that work on Geany listed on the project page rather than just the committers.
That being said, I don't think "Plugin Contributors" would really be needed.
It's just an idea. If everyone's against it, we don't need to do it.
Cheers, Matthew Brush
On Fri, 07 Oct 2011 08:28:04 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
And don't forget to give me your Github usernames!
zhekov