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
