Hey guys,
I know it's really a double-edged sword, but still. What about having
branch which:
- Called somewhat clear what it is: like continous_integration (not the
best name in the world perhaps)
- It allows developers to commit stuff, regardless of the BCon level
- Mainly used dugin bcon3 and
I think the term you might be looking for is staging branch. I've
considered making one for BGE patches. So, +1 from me for making such a
branch.
On Thu, Mar 5, 2015 at 2:42 PM, Sergey Sharybin
wrote:
> Hey guys,
>
> I know it's really a double-edged sword, but still. What about having
> branch
Its a real problem...
There are 2 main issues I have with current system.
- We don't have a good place to queue changes to be made after release.
When looking at patches to review I found a reply of mine...
something like: "I'll apply this after 2.61"
... its really weak there isn't a way to
Hi,
First of all, i it's not going to be distractive for developers, i'm fine
with per-feature branch as well, especially if they're using some common
prefix. "staging" is a bit misleading tho, but can't think of something
better atm. However, there are still some issues with that. Mainly, who
doe
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 local
On Fri, Mar 6, 2015 at 7:38 PM, Sergey Sharybin wrote:
> Hi,
>
> First of all, i it's not going to be distractive for developers, i'm fine
> with per-feature branch as well, especially if they're using some common
> prefix. "staging" is a bit misleading tho, but can't think of something
> better a
On Fri, Mar 6, 2015 at 7:48 PM, Bastien Montagne 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
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" ment
On Fri, Mar 6, 2015 at 8:05 PM, Sergey Sharybin 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
> re
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.
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 i
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 l
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 stil
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:
>
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,
Hello,
Sorry, seems there is already a "blender next" project
> Le 6 mars 2015 à 13:42, Julien Duroure 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
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
(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 :
> Truth be told, release candidates
@Gaia,
Users like to use the *best* version of Blender (who can blame them!)
if there is a version with 3+ interesting improvements which will be
in the next release. I'm sure they'll use it, build on graphicall...
etc.
Of course anyone can make some patches version of Blender, but if we
have a lot
I would say:
- Being able to filter in dev.b.o is omsething we must have. I've created a
quick patch to filter differencial revisions by project [1]. It was
rejected by upstream because phabricator team wants to have general way to
filter all objects which depends on project without having duplica
Hi,
Have you considered using the git flow workflow [1]? The idea is that you
keep one branch (probably master) always "ready" for release. Then you have
an unstable/staging branch called develop. All significant development is
done on feature branches. I've found it to be quite nice in my own
pro
Le 06/03/2015 09:38, Sergey Sharybin a écrit :
> We could approach to the issue of applying patches from a totally different
> angle tho. Screw it creating branches in the main repository, just whoever
> is responsible for that patch could have a local staging branch with all
> the commits ready f
On Sat, Mar 7, 2015 at 2:11 AM, Sergey Sharybin wrote:
> I would say:
>
> - Being able to filter in dev.b.o is omsething we must have. I've created a
> quick patch to filter differencial revisions by project [1]. It was
> rejected by upstream because phabricator team wants to have general way to
>
Hi,
That's true that real testing starts after the release. But it doesn't we
shouldn't make it so master is as well tested as we possible can do it.
As for the rest of suggestion -- we already had that in more early 2.5x
days. That approach has it's own strong and weak sides. Strong side you
alr
On Sat, Mar 7, 2015 at 12:57 AM, David Fenner 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 simp
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 certif
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 so
27 matches
Mail list logo
