[petsc-dev] Updating MOAB version during download

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>> If you find a bug, you have to fix it within the workflow of THAT
>> project.  If they use a workflow similar to PETSc, then a good option
>> would be to start a new branch from that critical commit and ask for it
>> to be merged.
>
>    Sure. and If —download-moab had gotten me into the right branch I
>    would branch off my fix branch from that, test it with my PETSc
>    stuff and then make a pull request.

Branching from the bad commit is arguably better because it means people
can get *only* your fix without the other random crap in the branch.
That fix should be merged according to the workflow of that project.

>> --download-package is a feature for USING a third-party package, not a
>> framework for CONTRIBUTING to that project.
>
>    Sure it is! Why the fuck should I be manually download/installing
>    packages when a tool can do it for me? What are computers for if it
>    is not to remove the manual process that can be automated.
>
>    When I am inside a PETSc branch and I say —download-xxx I am saying
>    given me the appropriate beasty that I can work with inside this
>    branch AND "WORK WITH" MEANS DO AS MUCH AS I COULD HAVE IF I HAD
>    MANUALLY DOWNLOADED IT MYSELF. I don’t want —download-xxx to mean
>    download a crippled version of the stuff, I want it to mean give me
>    everything I would get if I downloaded it myself and manually set
>    the branch etc.

This is way more involved and error-prone.  Git submodule and hg subrepo
aren't really designed for this use case (they work better when the
package is developed separately and you occasionally update) and I don't
think it's something we should try to do.  Merging different
modifications of the remote repository is one major problem.  Also, so
long as the build systems are decoupled, it's even more error-prone.

>> For you, what is wrong with updating gitcommit when you change an
>> interface in MOAB?  If other people are also developing MOAB, they
>> should have their own clone and "git pull" each time, not use
>> --download-moab.
>
>   1) I will of course forget to update gitcommit
>
>   2) I don’t even want to freaking know where moab is hosted. If I
>   want to run some tests on a linux machine (because Apple sucks and
>   doesn’t have valgrind) you think I want to manually figure out where
>   moab is hosted, use some git clone command to download it, manually
>   checkout the correct branch and then tell PETSc where I downloaded
>   it when —download-moan can do that for me?  Why should I do all that
>   (which I won’t do) when —download-moab can take care of it for me?

If you want to contribute to moab, you damn well better know where they
are hosted and how they accept contributions.

>    You are very much hung up on —download-xxx is for users. As I said
>    before I wrote —download-xxx for developers (me) and want to
>    continue to extend it to help developers (including me).

For developers of PETSc, sure, but for developers of the upstream
package?  Now PETSc is in the business of managing contributions to
other projects?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140616/54e60377/attachment.sig>