Hi,
So I guess this is quite a lot of work and folk are concerned it has not
yet been proven. To try and progress this experiment I propose that I
instead move Edi to our GitHub account where we do not have restrictions or
expectations of branching models etc.
Assuming no objections I will set
On Fri, 27 Oct 2017 14:32:40 + Mike Blumenkrantz
said:
> On Thu, Oct 26, 2017 at 8:27 PM Carsten Haitzler
> wrote:
>
> > On Thu, 26 Oct 2017 19:02:58 +0200 marcel-hollerb...@t-online.de said:
> >
> > > Two things,
> > >
> > > Calling
On Thu, Oct 26, 2017 at 8:27 PM Carsten Haitzler
wrote:
> On Thu, 26 Oct 2017 19:02:58 +0200 marcel-hollerb...@t-online.de said:
>
> > Two things,
> >
> > Calling efl-master unmanagable and unrunable is just spreading a
> > apocalyptic mood and does not really tell what is
On Thu, 26 Oct 2017 19:02:58 +0200 marcel-hollerb...@t-online.de said:
> Two things,
>
> Calling efl-master unmanagable and unrunable is just spreading a
> apocalyptic mood and does not really tell what is going on. There are
I absolutely agree. I and many others use master all day every day.
On Thu, 26 Oct 2017 13:38:12 +0100 Tom Hacohen said:
> I accidentally hit send, didn't mean to.
> Here is my full reply:
> It's possible, yes, but it doesn't address my initial concerns, which
> are that edi will stick out compared to the other e projects. This
> will be
On Thu, 26 Oct 2017 17:35:39 +0100 Tom Hacohen said:
> Intended to be would maybe be more appropriate, and then the statement
> would still apply. With that being said, I'm sorry to hear that it has
> changed, you guys should be spanking b0rokers more, don't let them
> win.
>
>
On Thu, 26 Oct 2017 16:14:14 + Mike Blumenkrantz
said:
> 'Our master is already considered "stable" and in a release state, so it
> really doesn't match our workflow.'
>
> Things have changed a bit since you've been gone, and this is not even
> remotely close
Two things,
Calling efl-master unmanagable and unrunable is just spreading a
apocalyptic mood and does not really tell what is going on. There are
bugs and a few crashes, yes, but the same happened a few years back when
i started with efl stuff. (Also, how can you call efl master unstable if
you
I haven't run efl master in a long time, and I know there are others who
have stopped running it for the same reasons that I have.
I am not necessarily advocating changing to gitflow, but several years of
the current development methodology has definitely proven that it is
unmanageable and that
Intended to be would maybe be more appropriate, and then the statement
would still apply. With that being said, I'm sorry to hear that it has
changed, you guys should be spanking b0rokers more, don't let them
win.
Regardless of that, as said on IRC, the reason why we do trunk
(master) based
'Our master is already considered "stable" and in a release state, so it
really doesn't match our workflow.'
Things have changed a bit since you've been gone, and this is not even
remotely close to being true anymore. As far as all of my use cases go
(everyday use on X, testing on Wayland, basic
I accidentally hit send, didn't mean to.
Here is my full reply:
It's possible, yes, but it doesn't address my initial concerns, which
are that edi will stick out compared to the other e projects. This
will be considered a success by you for sure, and I don't see us
changing the efl to follow, so
It is possible, yes.
On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler wrote:
> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams
> said:
>
>> Hi,
>>
>> You are absolutely right - the “show it with a smaller project and prove
>> it’s worth is
On Thu, 26 Oct 2017 07:19:51 + Andrew Williams said:
> Hi,
>
> You are absolutely right - the “show it with a smaller project and prove
> it’s worth is exactly why I brought it up. I was in the process of doing so
> and hit this roadblock. No intention to beat a dead
Hi,
You are absolutely right - the “show it with a smaller project and prove
it’s worth is exactly why I brought it up. I was in the process of doing so
and hit this roadblock. No intention to beat a dead horse - I actually
thought I was doing what was agreed.
Apologies if I got the wrong end of
On Thu, 26 Oct 2017 12:25:12 +0900 Jean-Philippe André said:
> I fail to see why we wouldn't allow Andy & Co to test out this workflow on
> EDI and use this as an experience?
> Is it impossible to allow those branch names only on EDI's repo?
I think I covered that with:
"BUT
I agree. This really isn't a big deal. You all have control of the git
projects. If someone manages branches in a project you are working on in a
way you don't like... revert it or remove it? We are being too difficult
about really small unimportant issues lately I think. If someone is willing
to
I fail to see why we wouldn't allow Andy & Co to test out this workflow on
EDI and use this as an experience?
Is it impossible to allow those branch names only on EDI's repo?
2017-10-26 8:35 GMT+09:00 Carsten Haitzler :
> On Wed, 25 Oct 2017 20:15:45 + Andrew Williams
On Wed, 25 Oct 2017 20:15:45 + Andrew Williams said:
We had this discussion before in just one place I believe until you asked for
specific branch names to be allowed. You wanted us to change how we branch and
work with efl/e etc. the last time. I don't remember there
Hi list,
This conversation seems to have now happened in many places and it seems
that a few key individuals don't really see why we should be looking at
different branching models. I understand that opinion but if we don't try
new things then we will never be able to engage with new process or
Hi TAsn,
Thanks for the reply. In gitflow these are the standards and they need to
work across different users hence why having the developer namespace is not
quite enough. Additionally the hotfix is not catered for in our current
scheme (as I understand it).
One nice thing with gitflow is the
Heya,
I don't quite understand what you are trying to do here. I mean, I
understand you are trying to have these, but what are these branches
for? If it's for you developing your own features why not put it in a
dev branch?
We have these enforcements because we want to enforce branch names to
Hi git admins,
I'm setting up gitflow on Edi but I can't push to origin because of the
branch naming rules. Can you please open up the ability to have remote
branches matching the patterns "develop", "feature/*", "bugfix/*",
"release/*", "hotfix/*" and "support/*"?
I'd really appreciate it
23 matches
Mail list logo