[Bf-committers] RFC: "Continuous integration" branch?

Fri Mar 6 15:14:07 CET 2015

(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 <d4vidfenner at gmail.com>:

> 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 <julien.duroure at gmail.com>:
>
> 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 <gaia.clary at machinimatrix.org> 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 <aligorith at gmail.com>
>> 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 <gaia.clary at machinimatrix.org>
>> >>> 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 <
>> ideasman42 at gmail.com
>> >>>>> wrote:
>> >>>>>
>> >>>>>> On Fri, Mar 6, 2015 at 8:05 PM, Sergey Sharybin <
>> sergey.vfx at gmail.com
>> >>>>>> 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 <
>> >>> ideasman42 at gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> On Fri, Mar 6, 2015 at 7:48 PM, Bastien Montagne <
>> >>>> montagne29 at wanadoo.fr
>> >>>>>>>> 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
>> >>>>>>>> Bf-committers at blender.org
>> >>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> With best regards, Sergey Sharybin
>> >>>>>>> _______________________________________________
>> >>>>>>> Bf-committers mailing list
>> >>>>>>> Bf-committers at blender.org
>> >>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>>>>
>> >>>>>> --
>> >>>>>> - Campbell
>> >>>>>> _______________________________________________
>> >>>>>> Bf-committers mailing list
>> >>>>>> Bf-committers at blender.org
>> >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>>> _______________________________________________
>> >>>>> Bf-committers mailing list
>> >>>>> Bf-committers at blender.org
>> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>> _______________________________________________
>> >>>> Bf-committers mailing list
>> >>>> Bf-committers at blender.org
>> >>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> _______________________________________________
>> >>> Bf-committers mailing list
>> >>> Bf-committers at blender.org
>> >>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>