On 28/07/17 16:54, Stefan Schmidt wrote: > Hello. > > On 07/28/2017 09:09 AM, Simon Lees wrote: >> >> >> On 28/07/17 16:30, Stefan Schmidt wrote: >>> Hello. >>> >>> Reading my mails from yesterday again I think one might be able to get >>> the impression I actually want to shoot this idea down before it >>> actually has a chance to proof itself. That is not what I wanted to >>> bring across. :) >>> >>> I'm actually very much interested to get the workflow improved if there >>> is a significant improvement that comes with it. As you can see from all >>> these questions in my mails I have a lot of doubts that it would improve >>> the situation. Maybe I just need to get educated. Hard to say. :) >>> >>> Another thing is that I am _very_ reluctant to try such a big change in >>> efl first. If people want to move on with this we would need to see some >>> examples in smaller community projects here to get a first idea. >> >> I suspect the only problem here could be that most of the other projects >> in the community either A) don't have enough people contributing or B) >> don't release regularly enough for this approach to make as much sense. >> I certainly think its overkill for a project with 1-2 main authors and >> only semi regular releases, at that scale its much easier to keep >> feature branches up to date should you decide they won't make the next >> release etc. > > So what is the alternative? A flag day in efl? I don't think that would > be a sane proposal. Something like this would need to be tested and > evaluated before we could make a decision here. Not going to do that > live on the efl repo. At peak times we had over 100 contributors for a > release, they all need to be educated for this. > > If you and Andy, as its two supporters, would want to convince more > people a way to try it in real life but without interfering with our > normal workflow is what we need imho.
I am neither strictly for or against this style of proposal in efl.
There have been other projects in my previous working life where I think
such a proposal would be much better which is why i've spent time
learning and understanding it. As I understand it and think it could be
a viable option that's why i'm stating my view but personally I don't
have a strong opinion over whether we should adopt it or not.
I would be equally happy with a slightly different proposal where all
bugfixes first go into a stable branch efl-1.19 atm, and from there get
cherrypicked or merged into master. The Stable / Development part really
makes life easier for those still working on features during a code
freeze which isn't really me. I think if we were to test the idea in
another repo be it edi or terminology etc, it would mostly go to waste
because they don't have long freezes so everything would stay in stable
anyway and devel branch probably wouldn't be touched much.
If we were to go down this route I agree we'd need reasonable basic
documentation for developers something like below, but if its clear
enough I don't think people need somewhere to test and experiment first
although maybe a dummy repo is a option, but this is git after all and
if something goes to the wrong place we can A) cherry pick it to the
right place because it should have been where it ended up eventually ie
a bugfix that accidentally goes to stable, or we can revert it and
resubmit.
Simple doco as follows
Are you submitting a bugfix:
Yes:
Was this bug in the last release
Yes:
Submit to bugfix
No:
Submit to Stable
No:
Can your commit go into the next release(Depending on freeze rules):
Yes:
Submit to Stable
No:
Submit to Development
Its not too complex and if images worked well in mailinglists I could
have made you a simple flowchart.
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
