[CP2K:601] Re: cp2k release goals

[Teodoro Laino]

Hi Matt,

keeping a CVS branch is something quite time consuming. If we do that  
we will do when
we believe that we're quite close to a release (i.e. a release branch)..
Please, have a look at the previous messages we had on this  
argument.. What we need is just
hand-work.. I already started introducing the possibility of having  
keywords and sections supported or
non supported, and in my spare time Im slowly tagging the input (I'm  
just at the beginning..)...
So.. whoever wants to contribute there're so many things to do to  
move towards a release that I believe that
having a CVS branch (not a release one) at this stage would only  
complicate things.

Cheers,
Teo

On 17 Jan 2008, at 22:40, Matt W wrote:

>
> Just to keep this bubbling over...
>
> What about starting a second CVS branch...not really a release
> candidate, but just an unwritten rule to not commit to it until really
> rather happy with the code; maybe with a commitment to write up some
> reasonable documentation.  I suspect that in 6 months it would be
> interesting to see the divergence and, perhaps, more obvious which
> bits of the code are stable (either entirely unused, or releasable)
> and where the volatile stuff is.
>
> Matt
>
> On Jan 8, 12:03 am, Axel <akoh... at gmail.com> wrote:
>> On Jan 7, 11:35 am, Juerg Hutter <hut... at pci.uzh.ch> wrote:
>>
>>> Hi
>>
>>> there is of course the problem of keyword combinations.
>>> Option A may be fully tested within the framework of option B
>>> but not with option C. Still option C is a tested and useful
>>> option as long as used without Option A.
>>> Now how do you flag this?
>>
>> in general, given the way cp2k is built, one should
>> consider any "production" option that does not work
>> with all other "production" options a bug.
>>
>> in practice this is of course not achievable, particularly
>> during the bootstrapping of a release process. one has to
>> take a leap of faith at some point. to some degree the
>> regression test library is a zeroeth order defense of bugs
>> creeping in through unrelated changes and bad interactions
>> between combinations of options.
>>
>>> Redo this with combinations of 3, 4, etc options.
>>
>>> Therefore this flags can only be a guideline, not a definite
>>> to be trusted flag.
>>
>> absolutely. but at least it will work the other way
>> around. if somebody uses an option that is not cleared
>> for production use, it can be detected systematically.
>> this should already take care of a lot of problems.
>>
>> nobody can expect everything to run perfect out of the box. ;-)
>>
>> cheers,
>>    axel.
>>
>>
>>
>>> Juerg
>>
>>> ----------------------------------------------------------
>>> Juerg Hutter                   Phone : ++41 44 635 4491
>>> Physical Chemistry Institute   FAX   : ++41 44 635 6838
>>> University of Zurich           E-mail: hut... at pci.uzh.ch
>>> Winterthurerstrasse 190
>>> CH-8057 Zurich, Switzerland
>>> ----------------------------------------------------------
> >