[Bf-committers] UNSUBSCRIBE

Fri Aug 12 17:12:35 CEST 2011

UNSUBSCRIBE

Il giorno 12/ago/2011, alle ore 17:01, Campbell Barton <ideasman42 at gmail.com> ha scritto:

> Yep 39307
> 
> I'd prefer if this thread keeps on topic for devs & release
> maintainers and have discussion about general changes in policy,
> opinions on best practice etc in a different thread.
> 
> Theres some issues I'd like to bring up too but best do this after
> siggraph when more of the devs are reading the mailing list.
> 
> On Sat, Aug 13, 2011 at 12:28 AM, pete larabell <xgl.asyliax at gmail.com> wrote:
>> Just so I'm not confused as a platform builder... are the 39307 builds
>> ok, or are we building again? lol
>> 
>> On Fri, Aug 12, 2011 at 8:59 AM, Jim Williams <sphere1952 at gmail.com> wrote:
>>> As painful as this attitude seems, I'd have to agree with it.  The
>>> idea here is to modify expectations -- mostly on the developers part.
>>> 
>>> Um....given that the next number is to be 6.0 I wouldn't mind seeing
>>> that "200 bugs" turn into "0 bugs" in the near future rather than have
>>> to learn new UI.  It's really nice when round numbers mean pretty
>>> product.
>>> 
>>> On Fri, Aug 12, 2011 at 6:45 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>>>> This issue (IMHO) is not worth holding back the release for, we can
>>>> review Sergey's fix and have it ready for next release.
>>>> We now have 200 bugs in the tracker, so unless new bugs are found that
>>>> are regressions from previous releases we're better off sticking to a
>>>> more strict release cycle, 2.59 release we have now fixes ~140 bugs
>>>> since 2.58 so IMHO users are still better off with the update and not
>>>> waiting longer.
>>>> 
>>>> On Fri, Aug 12, 2011 at 8:22 PM, Jass <gaia.clary at machinimatrix.org> wrote:
>>>>> Why don't you just shift the release date (by one week for example),
>>>>> fix the issues as needed and keep trunk frozen for that period ?
>>>>> Wouldn't that help to get out an excellent release and avoid
>>>>> to push out 2.59b one week after 2.59 was released ?
>>>>> 
>>>>> Am 12.08.2011 07:52, schrieb Sergey I. Sharybin:
>>>>>> Hi,
>>>>>> 
>>>>>> I've got fix for grease pencil in mu branch [1], but it's really that
>>>>>> kind of changes which shouldn't be applied in last minute (at least
>>>>>> there are several possible issues i wanted to check), so let's limit GP
>>>>>> a bit for 2.59.
>>>>>> 
>>>>>> About reloading scripts and so. I've been working on UI in my branch
>>>>>> after merging ghash changes there and haven't found any bad sides of
>>>>>> this change.
>>>>>> 
>>>>>> About more clear release next time. I'm not sure why this release is so
>>>>>> "crazy". Is it our lag, lag of coordination or so..
>>>>>> 
>>>>>> [1]
>>>>>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=39313
>>>>>> 
>>>>>> P.S. linux 32/64 bit would be available soon.
>>>>>> 
>>>>>> Campbell Barton wrote:
>>>>>>> Hi, woke up to find a re-release from a revision that contains changes
>>>>>>> I made that were *not* intended to be in a stable release - switching
>>>>>>> operators and menus to hash lookups.
>>>>>>> We should have branched at r39259 stable and applied patches there
>>>>>>> before re-releasing.
>>>>>>> 
>>>>>>> 
>>>>>>> There is also the issue with grease pencil session - where the
>>>>>>> operator points to data that can be freed on 'Global Undo' (as opposed
>>>>>>> to the crasher with the modal operators own *fake* undo, fixed 39237
>>>>>>> and double undos fixed 39235).
>>>>>>> 
>>>>>>> Sergey's fix means you can't move the viewport while grease pencil
>>>>>>> session is enable so the option is now not at all working as it was
>>>>>>> meant.
>>>>>>> 
>>>>>>> *Sigh*
>>>>>>> Since there were 3 fairly bad bugs in this tool (2 crashers), my
>>>>>>> impression is that option isn't used all that much.
>>>>>>> A correct fix isn't some small edit, the operator must store data
>>>>>>> differently, this should have been picked up during normal
>>>>>>> development, IMHO we should not attempt to sort this out as a
>>>>>>> last-minute, show-stopper fix.
>>>>>>> 
>>>>>>> 
>>>>>>> There is the remaining issue:
>>>>>>> Do we use current bsd/linux/mac builds from r39304 (and wait on win
>>>>>>> build before announcing),
>>>>>>> Or re-branch from 39259 and apply a few fixes there and rebuild on all
>>>>>>> platforms.
>>>>>>> 
>>>>>>> By not re-branching we break our own guidelines - to unfreeze quick
>>>>>>> but use a branch for fixes and it feels very sloppy to me.
>>>>>>> On the other hand my change of moving operators/menu's into a hash
>>>>>>> isn't that big a deal and works with scripts reloading, freeing,
>>>>>>> re-registering operators etc - I would expect any bugs here would be
>>>>>>> obvious and break blender immediately, so I *think* they are safe.
>>>>>>> 
>>>>>>> Suggest to go ahead with r39304, but next release be more clear with
>>>>>>> release tag/branch, and the following unfreeze.
>>>>>>> 
>>>>>>> - Campbell
>>>>>>> 
>>>>>>> On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein<mein at cs.umn.edu>   wrote:
>>>>>>>> In reply to Sergey I. Sharybin (g.ulairi at gmail.com):
>>>>>>>> 
>>>>>>>>> Didn't know OSX still have got issues with non-trunk verison. I've just
>>>>>>>>> commited patch from Jens to solve this problems.
>>>>>>>>> 
>>>>>>>>> We prefer to keep revisions synced for all platforms, so please use
>>>>>>>>> 
>>>>>>>>> Trunk: r39307
>>>>>>>>> Extensions: r2241
>>>>>>>>> 
>>>>>>>> Updated tarball of the source and md5sum are in incoming on ftp.blender.org
>>>>>>>> 
>>>>>>>> Kent
>>>>>>>> _______________________________________________
>>>>>>>> Bf-committers mailing list
>>>>>>>> Bf-committers at blender.org
>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> - Campbell
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> No essence.  No permanence.  No perfection.  Only action.
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
> 
> 
> 
> -- 
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers