<div dir="ltr"><div dir="ltr">On Wed, Apr 17, 2019 at 2:40 AM Smith, Barry F. via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Apr 17, 2019, at 1:35 AM, Balay, Satish <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> <br>
> On Wed, 17 Apr 2019, Smith, Barry F. via petsc-users wrote:<br>
> <br>
>>  This is fine for "hacking" on PETSc but worthless for any other package. Here is my concern, when someone <br>
>> realizes there is a problem with a package they are using through a package manager they think, crud I have to<br>
>> <br>
>> 1) find the git repository for this package<br>
>> 2) git clone the package <br>
>> 3) figure out how to build the package from source, is it ./configure, cmake, what are the needed arguments,... <br>
>> 4) wait for the entire thing to build <br>
>> <br>
>> then I can go in and investigate the problem and provide and test the fix via a pull request. Heck I'm not going to bother.<br>
>> <br>
>> Thus a lot of potential contributions of small fixes that everyone in the community would benefit from are lost. This is why, for <br>
>> me, an ideal HPC package manager provides a trivial process for providing fixes/improvements to other packages.<br>
>> <br>
>> For example Sajid could have easily figured out the VecView_MPI_HDF5() bug and provided a fix but just the hassle of <br>
>> logistics (not ability to solve the problem) prevented him from providing the bug fix to everyone rapidly. <br>
> <br>
<br>
   I never said that any current practices are better than using spack! It is just that perhaps <br>
with a few tweaks spack could provide a way to fundamentally improve our current practices (which are, as you acknowledge cumbersome).<br></blockquote><div><br></div><div>This sounds like a hopeless pipedream. But maybe.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
   Barry<br><br>
> Even without spack and multiple packages - this is not a easy thing to<br>
> do. For ex: most of our users install petsc from tarball.<br>
> <br>
> And if they find a bug - they have to go through similar complicated<br>
> process [create a bitbucket account, get a fork - learn the petsc PR<br>
> process - make a PR etc].<br>
> <br>
> With spack - I stick to the usual process - and don't get bogged down<br>
> by 'spack' support for this process.<br>
> <br>
> If I see a breakage - I do 'spack build-env package [this has its own<br>
> issues] - attempt a fix - get it first working with a spack build.<br>
> <br>
> [Alternative is to just edit the package file to get my fix - if its a patch I can find]<br>
> <br>
> <br>
> Once I have it working [the major issue is taken care off]. Then I<br>
> have a diff/patch and then worry about how to submit this diff/patch<br>
> to upstream.<br>
> <br>
> Sure its a multi step model - and has many trip points. But is not<br>
> that our current petsc only model doesn't have any.<br>
> <br>
> Satish<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>