Hello, Sorry, seems there is already a "blender next" project....
> Le 6 mars 2015 à 13:42, Julien Duroure <[email protected]> a écrit : > > 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
