[petsc-users] Release canditate?

[Eric Chamberland]

Le 2015-12-13 22:12, Satish Balay a écrit :
> On Sat, 12 Dec 2015, Eric Chamberland wrote:
>
>> Le 2015-12-11 23:43, Satish Balay a écrit :
>>> We do autmoatically generate tarballs everynight - its avaliable at:
>>> http://ftp.mcs.anl.gov/pub/petsc/petsc-master.tar.gz [but we don't
>>> maintain snapshots - i.e old tarballs for this]
>> interesting!  I didn't knew that...  Then maybe creating a tarball for the
>> "maint" branch and naming it with the date (or the sha), and then making it
>> available on the "Download" page would be a more easy thing to do?
>
> Not sure I understand. Why snapshots of 'maint' branch?
>
> But if its refering 'master' [which petsc-master.tar.gz is from] -
> archive all the snapshots - but its not clear if its worth it..
> [maintain snapshots for 1 month? 1year? forever?] - esp when git is
> more convinent to bisect and to go back in history to find the buggy
> commit..
>
>>
>> How "far" or different is the master branch from the maint branch right now?
>> I see 3f7bb31
>> <https://bitbucket.org/petsc/petsc/commits/3f7bb316d2abd318f1cc7393382d1a7d22094d25?at=maint>
>> in maint but it is not clear (in bitbucket) if it is in master...?
>
> The commit of interest is 7b37fee - and its already in master - but
> then - there were additional chagnes to mkl_pardiso in master [so this
> part of code is reorganized]
>
> But wrt your question - all commits in maint will be merged into
> master [immediately - or after sometime]. Ideally - fixes to 'maint'
> get tested first in 'next', then in 'master' - and then merged to
> 'maint'.
>
>>> However adding in 'release' strings is a manual process - so we do
>>> this at the release time. [so we would have to do this stuff for rc]
>>>
>>> Here is a counter argument against this proposal. For folks interested
>>> in RC - could consider [for eg] 3.6.0 as RC - and test it out - and
>>> have all the issues discovered by 3.6.1. But this usually doesn't
>>> hapeen [and we have 3.6.1, 3.6.2, 3.6.3, 3.6.4 etc..]
>>>
>>> Also testing against master would catch issues early on - and not wait
>>> until the rc/release..
>> Yep, but isn't Petsc master far away from maint?
>
> Just to be clear:
>
> maint - maintainance release branch (primarily for patches to current
> release) i.e for 3.6.1, 3.6.2, 3.6.3 etc..
>
> master - current stable development for future release 3.7 [i.e if
> interested in RC - you would be looking at master branch]
>
> Assuming you are thinking off 3.7.rc1, 3.7.rc2, 3.7.0, 3.7.1 etc as
> the versions [not 3.6.4.rc]

I see.  In fact, I was thinking of 3.6.4.rc1, 3.6.4.rc2, then 3.6.4, 
followed by 3.6.5.rc1, 3.6.5.rc2, then 3.6.5, etc...

But I am also interested into testing the "3.7.rc_nightly" which is 
somewhat the petsc-master.tar.gz available right now...

But it is noted as follow: "This usage is for experts only." 
(http://www.mcs.anl.gov/petsc/download/), and I am not an expert... so I 
thought 3.6.4.rc1 would be something not reserved for experts but only 
friendly end-users like me... ;)

Anyway, I'll just try the petsc-master.tar.gz right now just to see... 
but would be somewhat interested into 3.6.4.rc1...

Maybe some chosen revisions of petsc-master.tar.gz might be pointed as 
"feature closed" and to be released so it is time to test them...?

I think I might script something here to wget the tarball, compile it 
and run tests automatically with the petsc-master.tar.gz...  so as soon 
as some problem appears with our usage or the forthcoming petsc, we will 
be able to give feedback...  maybe I could wget it only if your nightly 
tests are ok?  Hmmm, maybe your nightly tests could update a symlink or 
something "friendly" to wget only if all tests are ok?  For example, if 
all tests are sufficiently ok, maybe you could update something like a 
"latest-good-petsc-master.tar.gz" which I could wget unconditionally? 
Just an idea...

Thanks!

Eric