[GRASS-dev] Re: Branching

Thu Aug 10 17:11:14 EDT 2006

me too. Helena

Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

On Aug 10, 2006, at 4:59 PM, Michael Barton wrote:

> I can live with it. No problem
>
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics and Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
>
>> From: Markus Neteler <neteler at itc.it>
>> Date: Thu, 10 Aug 2006 22:11:03 +0200
>> To: <grass-dev at grass.itc.it>
>> Subject: Re: [GRASS-dev] Re: Branching
>>
>> Hi,
>>
>> could people live with the existence of a 6.1.x branch (maintained
>> for critical fixes) and a new 6.2.x branch (maintained for the
>> next stable release)? Everything is ready for 6.1.0. Michael and
>> others are waiting for the 6.2.x branch to be created to move the
>> Python interface into CVS HEAD.
>>
>> I would really like to move on. But I dislike to not have sort
>> of consensus on it.
>>
>> thanks
>>  Markus
>>
>>
>> On Thu, Aug 10, 2006 at 08:55:35AM +0700, Yann Chemin wrote:
>>> Maybe the "technology preview" is actually a good tag name for 6.1,
>>> and it is well preparing people to receive 6.2. Maybe 6.2 can be
>>> announced as beta in the news the same day of 6.1 release to  
>>> reinforce
>>> that feeling, maybe even announcing a 30 days target for 6.2  
>>> release.
>>>
>>> In this way people that want to make a biggish use of GRASS will  
>>> take
>>> the beta and get going within a week or two with the RC releases of
>>> 6.2 instead of focusing on 6.1 itself.
>>>
>>> On 10/08/06, Markus Neteler <neteler at itc.it> wrote:
>>>> On Wed, Aug 09, 2006 at 09:03:29PM +0100, Glynn Clements wrote:
>>>>> Markus Neteler wrote:
>>>>>> On Wed, Aug 09, 2006 at 05:08:08AM +0100, Glynn Clements wrote:
>>>>>>> Markus Neteler wrote:
>>>>>>>
>>>>>>>>> But the 6.1 branch is less than a month old. How many fixes  
>>>>>>>>> can
>>>> there
>>>>>>>>> be which can't easily be merged into 6.1.x?
>>>>>>>>>
>>>>>>>>> I'm not sure that having two stable versions based upon HEAD
>>>> snapshots
>>>>>>>>> only a month apart makes sense.
>>>>>>>>
>>>>>>>> I don't see a big difference (result) between
>>>>>>>> (a) branching again
>>>>>>>> (b) merging many things back
>>>>>>>
>>>>>>> The difference is that (b) allows you to choose which changes to
>>>>>>> merge, i.e. include simple bug fixes but not more destabilising
>>>>>>> changes.
>>>>>>>
>>>>>>>> The latter is much more effort. I currently have no time to
>>>>>>>> do more backporting of changes. That's why I proposed (a).
>>>>>>>
>>>>>>> In that case, my inclination would have been to simply move  
>>>>>>> the 6.1
>>>>>>> branch tag to the point where 6.2 would have been created. There
>>>>>>> doesn't appear to be much point in having an isolated 6.1  
>>>>>>> release for
>>>>>>> which any bugs will never be fixed.
>>>>>>
>>>>>> Sounds absolutely reasonable to me. It wasn't clear to me that
>>>>>> this is possible (I only knew about tag shifting; since a  
>>>>>> branch is
>>>>>> more or less a tag it maybe works the same way?). Have to
>>>>>> get out my CVS book for that if noone else shifts the branch.
>>>>>
>>>>> Hmm. The cvs Info file says:
>>>>>
>>>>>   *WARNING: Moving branch tags is very dangerous!  If you think  
>>>>> you need
>>>>>   the `-B' option, think again and ask your CVS administrator  
>>>>> about it
>>>>>   (if that isn't you).  There is almost certainly another way to
>>>>>   accomplish what you want to accomplish.*
>>>>>
>>>>> So maybe that isn't such a good idea. It would be safer to just  
>>>>> add
>>>>> another tag and forget about the old one.
>>>>>
>>>>>>> For me, the main question is: what would be the reason for a  
>>>>>>> user to
>>>>>>> choose 6.1.0 over 6.2.0?
>>>>>>
>>>>>> No real reason despite the time lag (6.1.0 we can have today,
>>>>>> for 6.2.0 we would make a beta first). Again, I think that
>>>>>> there are some relevant changes which 6.2.0 do not want to miss
>>>>>> (means: no simple rename of 6.1.0 to 6.2.0) such as no more
>>>>>> low limit of open raster maps, MingW/Cygwin fixes and other  
>>>>>> recent
>>>>>> things. We should keep in mind that 6.2.x will be around for a  
>>>>>> while
>>>>>> and that e.g. QGIS builds on top of it. For distros like Debian,
>>>> Gentoo,
>>>>>> Mandriva where packages depend on each other this makes a  
>>>>>> difference.
>>>>>
>>>>> If 6.1.0 will never have any updates,
>>>>
>>>> ... apart from critical bugfixes which I and Hamish will take
>>>> care of...
>>>>
>>>>> it would probably be a bad idea
>>>>> to build on top of it or use it in an OS distribution. The first
>>>>> significant bug would necessitate switching to 6.2, so you may  
>>>>> as well
>>>>> just skip 6.1 altogether.
>>>>
>>>> Well, we have meanwhile advertised 6.1.0 quite a bit and people
>>>> are awaiting it more or less today (it's sitting already as tarball
>>>> on my PC). We have also the announcement ready to be published,
>>>> a job is currently creating a Mandriva RPM (other tomorrow) etc.
>>>> Of course I can stop that but I don't see any advantage in doing  
>>>> so.
>>>>
>>>> We could add "technology preview" as earlier suggested by Hamish to
>>>> mentally prepare people that 6.2.0 is very close. And, as offered,
>>>> I am willing to backport critical bugfixes to 6.1.0 branch.
>>>>
>>>> Markus
>>>>
>>>> --
>>>> Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
>>>> ITC-irst -  Centro per la Ricerca Scientifica e Tecnologica
>>>> MPBA - Predictive Models for Biol. & Environ. Data Analysis
>>>> Via Sommarive, 18        -       38050 Povo (Trento), Italy
>>
>>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev