[Dune-devel] Private write access for Andreas

[Steffen Müthing]

Hi,

I just gave Andreas contributor access to the core modules (i.e. access
to the p/andreasbuhr/* branch namespace).

While Andreas already addressed some of your concerns in his mail,
I have some additional remarks:

Am 07.05.2013 um 13:04 schrieb Markus Blatt:

> Hi,
> 
> On Tue, May 07, 2013 at 12:19:17PM +0200, Christian Engwer wrote:
>> With the new git repositories we have the nice situation that we can
>> allow more flexibility in the branches. Our PHD student Andreas Buhr
>> has already a set of patches waiting, in order to easy merging with, I
>> will allow him to create private branches in the core modules under
>> p/andreasbuhr/. This is also some kind of test balloon for new
>> workflows.
> 
> Given this new workflow, I was probably to fast rejecting the github mirrors:
> 
> (Disclaimer: I am relatively new to git. Therefore some of my comments
> might be wrong because I lack insight to git)
> 
> I am really wondering whether this approach is such a good idea. You
> are saying that it eases merging. What you save is adding another
> upstream repository (the one where Andreas has write access) to your
> local repository. Having it added one can merge easily between the remote
> repositories. Actually, I am unsure if one even needs this. Can't
> Andreas sends you or flyspray a git-diff or something like that.

Well, wrangling those patch files is really inconvenient compared to just requesting
a merge, especially if it happens frequently… ;-)
But that is exactly why I wrote the other, rather long mail to the list: We have to
think about how we want to handle patches in the future, and I think the best
way to figure that out is by just trying viable approaches...

> 
> If we choose your suggested route, we will have  a lot of private
> branches eventually (one for every contributor). If each commit in these
> repositories triggers a commit email, it will be hard to follow the
> DUNE development of the main branches. Additionally, the repositories
> might blow up in size, maybe putting an extra burden of work (or even
> cost, if they are in the backup) on the institutions currently hosting
> the servers.

In fact, you can get a whole zoo of per-developer branches - you can have as many
of those as you want. But as Andreas pointed out, those commits only trigger mails
once they become part of master or of a feature branch.
The size of those branches is not likely to be a concern - the new repositories are tiny
compared to the old SVN repositories.

But while personal branches don't mess up the commit mailing list, they do pollute the
branch namespace, so it is important to delete them once they are not needed anymore
(e.g. because they have been merged). Otherwise, the list of branches in the repository
browser could get very long…

> 
> If Andreas works on some features that are/might be of a general
> interest, shouldn't we create a feature branch with a speaking name
> for it? Then people/developers at least know the context the commits
> belong to. This would at least allow for meaningfully filtering the commit
> messages. (Filtering on a person's name seems rather inadequate to me).
> 

That is a valid alternative approach, which I also suggested to Christian and Andreas, but they
want to start with the personal branch strategy for now. I think it really depends on what kind
of work you intend to do in the branch - if Andreas just wants a way to make small bugfixes available
that Christian can then decide to merge, having a personal branch for that is quite okay IMHO.

Private branches are also a little bit more of a playground - in contrast to regular branches, you
can also do forced updates.

> Additionally, your approach seems to implement another caste to our
> developer system. Before we had: normal people/contributors,
> developers with write access, and core developers. Now there is
> another one (contributors with private write access) in between the
> first two. Thus DUNE might even more be perceived like an elite clube and
> further keep others from contributing. Do we really want this? 
> 
> To me our already implemented system seems strict enough already and I hoped
> that by moving to git, we would lower the barrier for contributors. (That is
> also why I was reluctant to apply such strict pre-commit hooks in the
> first place).

That's politics - I stay out of that! ;-) That said, I would also like to give external contributors an
easier way to submit changes, but see my other mail about the issue.


Steffen


> 
> Having said this, I am be no means against giving Andreas write access
> to the repository according to our already established guidelines.
> 
> Regards,
> 
> Markus
> -- 
> Do you need more support with DUNE or HPC in general? 
> 
> Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
> Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany
> Tel.: +49 (0) 160 97590858  Fax: +49 (0)322 1108991658 
> 
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel

Steffen Müthing
Universität Stuttgart
Institut für Parallele und Verteilte Systeme
Universitätsstr. 38
70569 Stuttgart
Tel: +49 711 685 88429
Fax: +49 711 685 88340
Email: steffen.muething at ipvs.uni-stuttgart.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20130507/ed486df1/attachment.sig>