[Qgis-psc] access for Alex Bruy

Sat Jul 24 09:02:43 PDT 2010

Hi Tim

> 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.

Sounds like the Linux kernel development model. It would be interesting to 
look at other large projects to see what their development model is (e.g. Qt, 
glibc, xserver) and discuss e.g. at the hackfest if there is something we can 
use from it in QGIS development (I could prepare a little presentation about 
development models of other projects if it is of interest).

> 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?

Having a more structured development model (vs. an unstructured one) does not 
make QGIS easier for new developers. The benefit is a stronger review process 
(and thus better quality control). So afaik in the case of the Linux kernel, 
each patch is review by Linus himself and most of them additionally by a 
subsystem maintainer.
Don't know if some sort of review system would also be good for QGIS (or if it 
would be only additional bureaucracy).

Personally, I often create patches for changes to be reviewed by the 
responsible code maintainer to limit the risk of potential side effects.

Regards,
Marco

Am Freitag, 23. Juli 2010, um 23.07:52 schrieb Tim Sutton:
> 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

-- 
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Webereistr. 66, CH-8134 Adliswil, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee