On 28/07/17 17:35, Simon Lees wrote: > > > 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. > > I forgot to say, and the worst thing that can possibly happen by trying this is in 6 months we decide we don't like it at which point we can merge the stable and development branches and rename them back to master, we will still have a release branch for each release and will be back to before.
-- 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
