[petsc-dev] confusing download instructions

[Barry Smith]

  Satish,

    Ok then for now change the download instructions from 

    The latest stable version can also be downloaded using Git with the following command:
git clone -b maint https://bitbucket.org/petsc/petsc petsc

   to 

The patched release can also be downloaded using Git with the following command:
git clone -b maint https://bitbucket.org/petsc/petsc petsc


   We need to get rid of the term "latest stable version" which is unclear in this context what it means.

    Thanks

    Barry


On Jun 28, 2013, at 2:30 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> Yes - git usage has these extra requirements.
> 
> Perhaps its possible to make sowing more portable [I don't know]. But
> it still pushes these requirements to the user..
> 
> Satish
> 
> On Fri, 28 Jun 2013, Barry Smith wrote:
> 
>> 
>>   Satish,
>> 
>>    What about Windows issues with the git version? Doesn't sowing requiring gnu compilers which users who are using microsoft/intel compilers for PETSc won't have and hence cannot make fortran stubs? Can we make sowing more portable and build able by windows compilers?
>> 
>>   Barry
>> 
>> On Jun 28, 2013, at 12:58 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>> 
>>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>> 
>>>>   We should say
>>>> 
>>>> PETSc Release Version 3.4
>>>> 
>>>> 	• Prefered method: git clone -b maint https://bitbucket.org/petsc/petsc petsc (updates may be obtained via git pull && make)
>>>> 	• petsc-3.4.1.tar.gz - full distribution (including most current patches) with documentation
>>>> 	• petsc-lite-3.4.1.tar.gz - smaller version with no documentation (all documentation may be accessed on line)
>>>> 	
>>>> That is, by default we want people to get PETSc releases via git. 
>>> 
>>> Fine with me.
>>> 
>>>> One big issues is documentation? Is it possible to build on all
>>>> systems and how long does it take? Sometimes hours! 
>>> 
>>> Longer-term, we should make this faster and more portable.  In the past,
>>> we've talked about doing it with Python, which I think is a good idea,
>>> but changing languages is not the reason for the speed problem.  Do you
>>> know why sowing is so slow?  (I haven't profiled, but some things take
>>> forever.)
>>> 
>>>> So people who use git don't get documentation unless they do an extra
>>>> command, is that ok? Could we have the docs in another tar ball that
>>>> the user just brings in "on top of" the git repository (maybe even a
>>>> make command to get the tar ball and untar in the right place?)
>>> 
>>> That sounds reasonable.
>> 
>>