I'm getting lost in this stuff.. 

oh well..

satish

On Mon, 16 Jun 2014, Barry Smith wrote:

> 
> On Jun 16, 2014, at 5:43 PM, Jed Brown <[email protected]> wrote:
> 
> > Barry Smith <[email protected]> writes:
> >>> The commit hash, which is exactly what we have now.
> >> 
> >>  1) It is a manual beasty that someone has to edit moab.py and change
> >>  on a regular basis? This doesn’t work as proved by the current
> >>  fiasco.
> > 
> > One instance of misunderstanding the model is not an indictment that the
> > model is broken.
> > 
> >>  2) It does not give me access to the branch so that I can make
> >>  changes. Say I am working on feature-dmmoab in PETSc and see a
> >>  little bug in the moab branch that (indirectly only since I am at
> >>  some stupid headless commit-hash instead on a branch) I am pointing
> >>  to, that if I quickly fix I can push and make life easier for my
> >>  entire team of eight developers. I need to manual figure out what
> >>  branch corresponds to the commit-hash thing I had checked out,
> >>  change to that branch in moab, fix the branch in moab, push it and
> >>  then comeback and edit moab.py in PETSc to point to the new
> >>  commit-hash beasty of the moab branch.
> > 
> > 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. 
> > 
> >>    So somehow I would like the moab.py to “know” about the associated
> >>    moab branch (if there is one) as well as a commit-hash. Now when I
> >>    checkout the PETSc feature-dmmoab I want the branch checked out
> >>    (at a particular commit-hash? Is that possible?) Now if I update
> >>    the moab branch with a new commit then when I commit my
> >>    feature-dmmoab I want it to automatically update the “commit-hash”
> >>    in the moab.py
> > 
> > --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.
> 
> 
> > 
> > 
> > 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? 
> 
>    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). 
> 
>   Barry
> 
> 
> 
> 
> 

Reply via email to