[Dune-devel] Private write access for Andreas

[Steffen Müthing]

Am 07.05.2013 um 15:42 schrieb Markus Blatt:

> On Tue, May 07, 2013 at 02:34:30PM +0200, Steffen Müthing wrote:
>> 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:
>> 
>>> 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...
> 
> Sorry, but this is simply not true. I work on projects that use
> github. If you do not blindly trust your contributor, you have to do
> the same thing. Or if you want to test whether the fix of another
> contributor fixes your problem you have to the same, too:
> 
> 1. Add their repository as another upstream repository.
> 2. fetch their branch and origin (here you just save to fetch the 3rd
> party branch)
> 3. create a new branch from the master and merge the fix.
> 4. compile and test (BTW: This essential part is not automated by
> git).

Well, that assumes that everything that gets submitted looks perfect and any problems
won't turn up before you test the code. But in reality, there are lots of little problems which
you can notice just by looking at the code - and there's no point in investing all the time
to download and compile the patches for every iteration when you are not willing to merge
the change in its current state anyway. Ask yourself: Do you always download and apply
a patch posted in FlySpray before you tell the author to change something about the patch?

I think the latter happens quite often, and not having to reupload / redownload patches everytime
saves both the contributor as well as the reviewer a lot of time. Moreover, making it easy to see the
diff (or at least not harder as it is right now with FlySpray for small numbers of small patch files)
increases the probability of more people having a quick look - always a good thing, because while
tests are good to have and very important, they won't catch all bugs - especially our limited number
of tests. :-(

Steffen

> 
> 
>> 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…
>> 
> 
> Shame on me. I should do that for a couple of branches.
> 
>>> 
>>> ™[Snipping the rest]
>>> 
> 
> Cheers,
> 
> 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/71a2bf23/attachment.sig>