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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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<[email protected]> wrote: >>>>>> In reply to Sergey I. Sharybin ([email protected]): >>>>>> >>>>>>> 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 >>>>>> [email protected] >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> >> -- >> - Campbell >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > No essence. No permanence. No perfection. Only action. > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
