UNSUBSCRIBE
Il giorno 12/ago/2011, alle ore 17:01, Campbell Barton <ideasma...@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.asyl...@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 <sphere1...@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 <ideasma...@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.cl...@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<m...@cs.umn.edu> wrote: >>>>>>>> In reply to Sergey I. Sharybin (g.ula...@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@blender.org >>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Bf-committers mailing list >>>>> Bf-committers@blender.org >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>> >>>> >>>> >>>> >>>> -- >>>> - Campbell >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> >>> >>> >>> -- >>> No essence. No permanence. No perfection. Only action. >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > - Campbell > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
