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

[David Fenner]

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
>