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

[Sergey Sharybin]

Francois, this is really bad altitude which should be even mentioned in
open source projects like Blender (this might be acceptable in other
open-source project if it's some really nasty security issue found and work
is needed to solve it, without attracting all the bad guys around). This is
not something we would ever accept in our project.

To conclude:

- We'll update dev.b.o rather soon, with latest phabricator and
differencial filtering patches applied
- It is fine to have staging-<D123>-some_awesome_feature branches to
accumulate patches which would be applied after the release

This way we're addressing the root of the issue which is patches being
forgotten in the tracker and we don't distract development process at all.

For other cases everyone is welcome get use of de-centralized nature of Git
and have patches in their local branches for until git is open. Or it it'd
a bigger change create a temp branch in our repository which then will get
removed after the merge.

Would consider the discussion closed. If there's some strong disagreement
be welcome to talk to be or Campbell in IRC.

P.S. dev.b.o update will cause some downtime of the resource, i'll try to
minimize it as much as possible and do at the time when majority of the
people around are sleeping. Details i'll mail to the list once the patched
phabricator is totally backed and ready for deployment.


On Sun, Mar 8, 2015 at 10:43 PM, François T. <francoistarlier at gmail.com>
wrote:

> Hey Campbell,
>
> thinking about a older comment you made about users will want to only test
> the shiny one with all the new features. I kind of agree with that, I would
> probably be the first. But who says that this version tested/compiled via
> CI should be available to public ?
> Like the way only certified developers could submit code, why can't we
> think about "only dev binary". So this branch could only be used and see by
> devs having credentials ?
>
> 2015-03-08 12:48 GMT+01:00 Campbell Barton <ideasman42 at gmail.com>:
>
> > On Sat, Mar 7, 2015 at 12:57 AM, David Fenner <d4vidfenner at gmail.com>
> > wrote:
> > > 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.
> >
> > Blender used to do releases much less frequently (release when its
> > ready) as you described and it didn't work well for us.
> >
> > Also the comment "nobody tests them right now" isn't true, we get bug
> > reports specifically from users testing RC's in our tracker.
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> ____________________
> François Tarlier
> www.francois-tarlier.com
> www.linkedin.com/in/francoistarlier
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin