(by the way... sorry to jump in just like that, if this was a dev only discussion. I felt artist feedback might help. I currently work in a mid-sized production house called Loica and we use blender more than a lot).
2015-03-06 10:57 GMT-03:00 David Fenner <[email protected]>: > Truth be told, release candidates aren't very well tested anyway. It's > when a true release comes when true testing begins. I say it as an artist > myself. > > My personal opinion on this matter is a little more unorthodox, I think > there simple shouldn't be a "Bcon" and releases every 3 months. I'm very > serious. This only makes blender development too sparse and out of focus on > the important things. Releases should come when the goals are met, period. > Just like Krita does. The big discussion should be about what will this > goals be, will it be despgraph refactor, hair sim, cloth speed, and some > other things. If these things are unfinished, then "in the middle" > releseases just get developers out of focus. Nobody wants a half made tool > that rushes into a release, or development time wasted in a release that > doesn't have the tool at all. What is the point of fixing so many bugs when > there are 20 half baked projects in the way that will come with a ton of > bugs very soon anyway? Why not make really important releases? We don't > care if we wait for eight months for a real release. Then I'd be truly > interested in testing release candidates, but honestly, if nobody tests > them right now, is for a reason, and this is "why should I test it if > another one will come in a very short time anyway? " We can talk about > community morals here, about being really active and not only ripping of > the benefits and bla bla bla but in truth, really effective things occur > when we see things like they really are, not based on ideals. > > The fact that this discussion even started shows that something needs to > be done here, and instead of making separate branches, that as sergey said, > most people will stick to the development one, I propose simple extending > the release cycle indefinetely, until clear, big and small goals are met, > with a cap of course, lets say nine months or a year. > > 2015-03-06 9:42 GMT-03:00 Julien Duroure <[email protected]>: > > Hello, >> >> What about a "ready to merge" phabricator project to identify patches >> that are ready, but not merged yet because of bcon4. >> This will solve lost patches into phabricator from occasional developers. >> But not solve core developer commits , that are not linked to phabricator >> tasks. >> >> Regards, >> >> >> > Le 6 mars 2015 à 13:26, Gaia <[email protected]> a écrit : >> > >> > Are these assumptions based on common sense or >> > are these approved observations? >> > >> > - Basically everyone will just stick to shiny >> > development branch >> > - release wouldn't even be well-tested by artists. >> > - Plus file compatibility issues will still exist. >> > >> > >> >> On 06.03.2015 12:03, Sergey Sharybin wrote: >> >> If you'll read conversation with Campbell a bit more accurate Gaia's >> >> proposal will cause the same issue as staging branch mentioned above. >> >> Basically everyone will just stick to shiny development branch and >> release >> >> one wouldn't even be well-tested by artists. Plus file compatibility >> issues >> >> will still exist. >> >> >> >>> On Fri, Mar 6, 2015 at 3:55 PM, Joshua Leung <[email protected]> >> wrote: >> >>> >> >>> Gaia's suggestion makes a lot of sense IMO. >> >>> >> >>> Basically, when we get to BCon4 time, we fork off a release branch >> for the >> >>> upcoming release. Development can continue in master, but fixes will >> be >> >>> backported to the release branch one by one. This acts as an extra >> level of >> >>> protection against accidental last-minute cleanups sneaking in. >> >>> >> >>> On Fri, Mar 6, 2015 at 11:38 PM, Gaia <[email protected]> >> >>> wrote: >> >>> >> >>>> I just was thinking about something similar, but possibly easier to >> >>>> maintain: >> >>>> >> >>>> - A development branch for committing ongoing work. >> >>>> - Release branch created as soon as "only patches allowed" applies. >> >>>> >> >>>> Then while the release branch is active any commit there could >> possibly >> >>> be >> >>>> automatically merged into the development branch. Of course whenever >> >>>> a conflict happens, then the "release developer" would have some >> extra >> >>>> work to resolve this. >> >>>> >> >>>> So, as soon as the release is done, the release branch contains the >> >>>> finished >> >>>> release (ready for delivery) and the development branch is still up >> to >> >>> date >> >>>> because all release fixes have been propagated to the development >> branch. >> >>>> >> >>>> Would something like this make sense? >> >>>> >> >>>> cheers, >> >>>> Gaia >> >>>> >> >>>>> On 06.03.2015 11:17, Eugene Minov wrote: >> >>>>> Hi! >> >>>>> I'm not a developer but just read the thread and have been thinking, >> >>> what >> >>>>> if instead of making branch per feature, try to make branches for >> each >> >>>> BCon >> >>>>> level or one branch for BCon in general and delete that branch after >> >>>>> release. >> >>>>> >> >>>>> Sorry if this is not acceptable way or you already discussed that. >> >>> Just a >> >>>>> thought.. >> >>>>> >> >>>>> Eugene >> >>>>> >> >>>>> On Fri, Mar 6, 2015 at 11:07 AM, Campbell Barton < >> [email protected] >> >>>>> wrote: >> >>>>> >> >>>>>> On Fri, Mar 6, 2015 at 8:05 PM, Sergey Sharybin < >> [email protected] >> >>>>>> wrote: >> >>>>>>> Yeah, fair enough about per-developer branch would only confuse >> patch >> >>>>>>> applying more. >> >>>>>>> >> >>>>>>> Applying in a local branch does not mean you close the patch >> >>>> immediately. >> >>>>>>> You close them when the branch gets committed to master. >> Differencial >> >>>>>>> revisions will be closed because of "Differnecial Revision: FOO" >> >>>> mention, >> >>>>>>> for patch tracker think we can make it so "Patch TXXX" also closes >> >>>> tasks >> >>>>>>> (that we can/should do anyway i think). >> >>>>>>> >> >>>>>>> But i'm still fine with just "staging-" branches, would help >> >>> organizing >> >>>>>>> work with the patch tracker a bit more. But what's your opinion >> about >> >>>>>>> staging- branch for non-tracker patches (like regular development >> >>>>>> things)? >> >>>>>> >> >>>>>> Think its fine as long as the feature branches are clearly marked. >> >>>>>> This is almost what `temp-` branches are being used for already. >> >>>>>> `staging-` is just indicator its ready for master. >> >>>>>> >> >>>>>> >> >>>>>>> On Fri, Mar 6, 2015 at 1:56 PM, Campbell Barton < >> >>> [email protected]> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> On Fri, Mar 6, 2015 at 7:48 PM, Bastien Montagne < >> >>>> [email protected] >> >>>>>>>> wrote: >> >>>>>>>>> Hi, >> >>>>>>>>> >> >>>>>>>>> I’m not fan at all of a 'global staging' branch idea, afaik >> >>>> gooseberry >> >>>>>>>>> was supposed to be that… What I mean is, I think it will always >> >>>>>> diverge >> >>>>>>>>> one way or the other. We could make per-patch staging branches, >> but >> >>>>>>>>> would add some noise in our git repo… >> >>>>>>>>> >> >>>>>>>>> I really prefer storing such things locally. That way, each dev >> can >> >>>>>>>>> handle things under his responsibility the way he prefers (local >> >>>>>>>>> branches of course, but maybe also mere list of patches to >> apply, >> >>> or >> >>>>>>>>> whatever). "Public" branches should be kept for reasonably big >> >>>>>> projects, >> >>>>>>>>> or sensitive things that need early testing/team work/whatever, >> >>> imho. >> >>>>>>>> The problem with storing things locally is... >> >>>>>>>> >> >>>>>>>> - Its not clear to the patch submitter what happened. >> >>>>>>>> - We rely on each devs hard-disk/backups... or knowing the URL of >> >>>>>>>> their github repo. >> >>>>>>>> - Another dev can't easily apply the patch (or wont have access >> to >> >>> any >> >>>>>>>> improvements made after applying). >> >>>>>>>> _______________________________________________ >> >>>>>>>> Bf-committers mailing list >> >>>>>>>> [email protected] >> >>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >> >>>>>>> >> >>>>>>> -- >> >>>>>>> With best regards, Sergey Sharybin >> >>>>>>> _______________________________________________ >> >>>>>>> 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 >> >>>>> _______________________________________________ >> >>>>> 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 >> >>> _______________________________________________ >> >>> 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 >> _______________________________________________ >> 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
