wxcode-users

[wxCode-users] github 'poll' request

[Andrea <xvi...@gm...>]

Hi,
I would like to ask to you all wxCode component maintainers your 
opinion/suggestions about an idea I had in mind from a couple of time:

I would like to have a new wxCode home on github (so to use Git instead 
SVN as SCM system).

I think this way will improve wxCode project with a better organization, 
having:

- more than one maintainer for each component project
- create more components categories (e.g. pre and post wx 2.9, 
'wxSnippets' for dead/wxCode external projects etc.)
- use git hooks / custom scripts for easy websites/components maintainance
- more flexible repositories inside a unique wxCode 'github organization'
- more than one repository for each component project (like the usual 
trunk/tags/branches)
- get component fixes via github pull requests instead usual patch files

I've discussed about this with Ulrich Telle and we would like to see 
your point of view.

This will be something I would like to try to do as an experimental/demo 
project to let you see how it will works and also get possible 
suggestions time by time and, if successful, consider a future transition.

Regards

Andrea

Re: [wxCode-users] github 'poll' request

[Ulrich T. <ulr...@gm...>]

Hi Andrea,

> I would like to ask to you all wxCode component maintainers your
> opinion/suggestions about an idea I had in mind from a couple of time:
>
> I would like to have a new wxCode home on github (so to use Git instead
> SVN as SCM system).

As SourceForge put up several restrictions regarding project maintenance 
and administration which makes maintaining wxCode sometimes quite 
cumbersome and as a single SourceForge project is not very well suited 
for maintaining a big collection of only loosely coupled components I 
definitely support your experiment.

> I think this way will improve wxCode project with a better organization,
> having:
>
> - more than one maintainer for each component project

For the wxCode SourceForge project in effect every project member could 
work on *all* components. The SourceForge SVN doesn't support a 
fine-grained access control.

> - create more components categories (e.g. pre and post wx 2.9,
> 'wxSnippets' for dead/wxCode external projects etc.)

Introducing new component categories could be easily added on SF wxCode 
as well, but only an administrator could do it.

> - use git hooks / custom scripts for easy websites/components maintainance

This would be definitely much better than what have now.

> - more flexible repositories inside a unique wxCode 'github organization'

This would also be a big advantage.

> - more than one repository for each component project (like the usual
> trunk/tags/branches)

AFAIK on the SF wxCode SVN tags weren't used at all, probably because 
tagging would really mean to tag wxCode as a whole what just isn't the 
right thing for independent components.

> - get component fixes via github pull requests instead usual patch files

As I seldom received patch files for my own components over the last 7 
years I can't judge how important this feature might be for other wxCode 
maintainers.

> This will be something I would like to try to do as an experimental/demo
> project to let you see how it will works and also get possible
> suggestions time by time and, if successful, consider a future transition.

I think it's an interesting idea and I'm curious to hear about the first 
experiences of you. Maybe this could give wxCode a new impulse to get a 
better image and to get into a better shape.

Regards,

Ulrich

Re: [wxCode-users] github 'poll' request

[John L. <jla...@gm...>]

On Tue, Jun 19, 2012 at 10:14 AM, Ulrich Telle <ulr...@gm...> wrote:
> Hi Andrea,
>
>> I would like to have a new wxCode home on github (so to use Git instead
>> SVN as SCM system).

I don't know if I'm ready for Git yet, I'm just getting accustomed to
SVN after having dropped CVS, but see the bottom for a solution that
may perhaps work.

> As SourceForge put up several restrictions regarding project maintenance
> and administration which makes maintaining wxCode sometimes quite
> cumbersome and as a single SourceForge project is not very well suited
> for maintaining a big collection of only loosely coupled components I
> definitely support your experiment.

As perhaps the only active developer on it besides Ulrich, one of the
earliest adopters of wxCode, and an absentee administrator, I have to
say that it has not worked out as planned.

The real reason is not technical, but simply manpower and interest.
Projects need to be marked as working, updated to 2.9, documentation,
working builds, etc and nobody has the time or interest.

> For the wxCode SourceForge project in effect every project member could
> work on *all* components. The SourceForge SVN doesn't support a
> fine-grained access control.

This has never been a problem as far as I know.

>> This will be something I would like to try to do as an experimental/demo
>> project to let you see how it will works and also get possible
>> suggestions time by time and, if successful, consider a future transition.
>
> I think it's an interesting idea and I'm curious to hear about the first
> experiences of you. Maybe this could give wxCode a new impulse to get a
> better image and to get into a better shape.

There is a "live" SVN -> Git translator and wxWidgets uses it. Perhaps
this could work here as well?

https://github.com/wxWidgets/wxWidgets

Regards,
    John

Re: [wxCode-users] github 'poll' request

[Bryan P. <br...@ib...>]

On Sun, Jul 1, 2012 at 10:59 PM, John Labenski <jla...@gm...> wrote:
> There is a "live" SVN -> Git translator and wxWidgets uses it. Perhaps
> this could work here as well?
>
> https://github.com/wxWidgets/wxWidgets

This is only really useful for advanced Git developers, who still are
required to make commits using SVN with the original repository, not
the one on GitHub. See the git-svn manpage for details on how to set
this up if you're interested though, anyone with SVN read access can
do it.

But it might also be interesting to note that GitHub actually has also
provided SVN support directly into repositories hosted on GitHub. This
works not only for checkout, but also for commits:
https://github.com/blog/1178-collaborating-on-github-with-subversion

Regards,
Bryan Petty

Re: [wxCode-users] github 'poll' request

[PGridDev <pgr...@ya...>]

Hi Andrea & all

Here my 2 cents in reply to Andrea's proposal:

I just started using GIT a few months ago on another project, but it seems to me like the way to go: very flexible and designed just for massively distributed, open source software projects.

There is a 'but' of course: the learning curve is steeper than CVS/SVN, and the administration complexer. I think that we would need at least 2 admins who know GIT well enough and can help in case of merge conflicts and who can generally support the wxCode community (e.g. branch issues, corrupt repositories)

We might want to use gitolite (https://github.com/sitaramc/gitolite/) for the user/priviledge administration.

Regards -Ronan



On 19/06/2012 13:36, Andrea wrote:
> Hi,
> I would like to ask to you all wxCode component maintainers your
> opinion/suggestions about an idea I had in mind from a couple of time:
>
> I would like to have a new wxCode home on github (so to use Git instead
> SVN as SCM system).
>
> I think this way will improve wxCode project with a better organization,
> having:
>
> - more than one maintainer for each component project
> - create more components categories (e.g. pre and post wx 2.9,
> 'wxSnippets' for dead/wxCode external projects etc.)
> - use git hooks / custom scripts for easy websites/components maintainance
> - more flexible repositories inside a unique wxCode 'github organization'
> - more than one repository for each component project (like the usual
> trunk/tags/branches)
> - get component fixes via github pull requests instead usual patch files
>
> I've discussed about this with Ulrich Telle and we would like to see
> your point of view.
>
> This will be something I would like to try to do as an experimental/demo
> project to let you see how it will works and also get possible
> suggestions time by time and, if successful, consider a future transition.
>
> Regards
>
> Andrea