[Qgis-psc] access for Alex Bruy

Tim Sutton tim at linfiniti.com
Fri Jul 23 14:07:52 PDT 2010


Hi Marco and others

I agree we need good clear guidelines on when a developer should be
granted svn access. I think that limiting svn access to code area
maintainers will get a little bit cumbersome. There is also the happy
side effect that some developers when given access go crazy and spend
all there spare time improving QGIS - just look at how fantastic a
contribution Jurgen has made since he was granted SVN access (with
apologies for singling out just one developer).

I have listened to quite a few podcasts about version control systems
and it seems like the valid point Marco raises is not an uncommon one
- and is one that is addressed by using a distributed code versioning
system like git or mercurial. The model in that case would be:

One or two god like figures control the canonical repository.
Core developers maintain their own repos which are synced periodically
to the canonical repo.
Casual developers submit patches to devs who incorporate changes into
their personal trees as they accept patches.

Personally I dont have a lot of experience with git and I dont know if
the above scenario will just make life more complicated that it is
already. Is moving to GIT or Mercurial in anyone else's thoughts and
if so would it move us along the road towards making QGIS easier for
new developers to arrive into the project?

Another idea I have is to have a bug squash team - developers who gain
commit access after having a certain number of patches accepted (say
10). They would then be given free reign to fix bugs and commit those
fixes as needed but would need to liase with code maintainers before
committing any new features to the code base.

Whichever route we take it certainly is important that we are seem to
be fair and impartial about the acceptance process for new developers
and that we encourage and support the addition of new people into the
project so that we can continue to grow.

Regards

Tim


2010/7/23 Marco Hugentobler <marco.hugentobler at sourcepole.ch>:
> Hi all
>
> My concern was not about Alex at all. My point was that, in the PSC, it would
> be good to have a clearer policy when to give svn write access (just to be
> fair to everyone). Especially for future requests from other developers.
>
> Maybe something to discuss at the next hackfest. Until then, +1 from me to svn
> access for Alex (I assume he coordinates his changes well with the maintainers
> of f-tools and GDAL tools).
>
> Regards,
> Marco
>
>
>
>
>
>
>
>
> Am Freitag, 23. Juli 2010, um 03.44:08 schrieb Maxim Dubinin:
>> I understand your concern, but given number of patches Alex has
>> submitted it simply gets a little inefficient to wait for the review
>> of each one of them (Searching trac for 'alexbruy patch' results in 50
>> hits). I can simply imagine that only merging most of our plugins with
>> fTools will further increase these metrics considerably.
>>
>> I also think that introducing 'assistant maintainer' status or alike would
>> help. However, I believe, that Alex's situation is somewhat unique
>> (I'd say unfortunately, yet), usually devs from outside stop at submitting
>> a couple of patches.
>>
>> It  should  also  be  taken  into consideration, that it is not simply
>> 'Alex being good developer' (which he undoubtedly is), there is strong
>> and  numerous  community behind Alex's back that helps him and at some
>> point wants quicker responses to submitted bugs, that he successfully
>> fixes.
>>
>> Maxim
>>
>> Вы писали 22 июля 2010 г., 6:59:41:
>>
>> MH> Hi all
>>
>> MH> I think this is a good opportunity to discuss our svn commit access
>> policy. MH> In the past, I blocked some requests for commit access telling
>> that svn MH> commits should be made by the code maintainers
>> MH> (http://www.qgis.org/wiki/Project_Organigram#Code_Maintainers) and
>> other code MH> contributors should send patches to the maintainers.
>>
>> MH> For Alexander, this would mean to send patches to the maintainers of
>> GDALTools MH> (Giuseppe) and fTools (Carson). Note: this would absolutely
>> not reduce the MH> merits of Alexander as a contributor.
>>
>> MH> But I think we didn't really discuss this on the psc-list.
>> MH> So question: is this 'maintainers only' commit policy something you
>> like or MH> should we handle commit access such that all active
>> contributors receive MH> commit access? (In that case, we would give
>> commit access also to Anne who MH> made a similar request recently).
>>
>> MH> I could also imagine in-between solutions such as co-maintainers (in
>> cases MH> where it is more convenient for a code maintainer to share
>> work).
>>
>> MH> What is your opinion?
>>
>>
>>
>> MH> Regards,
>> MH> Marco
>>
>> MH> Am Mittwoch, 21. Juli 2010, um 18.08:28 schrieb Maxim Dubinin:
>> >> Hi PCS,
>> >>
>> >> I'm not on PCS, but I've been told that I still can vouch for
>> >> Alexander Bruy to be given maintainer status (on basis
>> >> of support for GDALTools & fTools). You had multiple occasions to
>> >> review his code as patches and plugins and I hope more is coming.
>> >>
>> >> Maxim
>> >>
>> >> _______________________________________________
>> >> Qgis-psc mailing list
>> >> Qgis-psc at lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Webereistrasse 66, 8134 Adliswil, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>



-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Visit http://linfiniti.com to find out about:
 * QGIS programming services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
==============================================



More information about the Qgis-psc mailing list