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
