On 03/29/2016 11:32 PM, Stefan Schmidt wrote: > Hello. > > On 29/03/16 04:04, Simon Lees wrote: >> Hi All, >> >> Now that I have slightly more time on my hands and to make the next >> enlightenment release easier to manage I am proposing to volunteer to >> maintain efl 1.18 as a LTS as it will be less effort then backporting >> patches 1 by 1 into our build system. > > First of all thanks for bringing this up and most of all volunteering to > do it! > >> >> Why 1.18? It aligns best with our release cycle, which feature freezes >> in September and releases in the first week of November. Based on the >> success of this I will probably consider doing similar for every August >> efl release. > > 1.18 is both good and bad from what I can foresee. It has elm merged in > and the new Interfaces API changes. This makes it a solid ground for a > long term maintenance. > On the other hand these both big things are fresh in 1.18 and might > cause some trouble. > > My hopes are that we really catch most of these troubles before 1.18 > goes out and the corner cases we missed in the normal 1.18.x stable > window until 1.19 comes out. This should give your LTS a stable base. > Hopefully! :)
Yeah I would have liked to target 1.19, however, it comes out too late but by the time openSUSE actually releases it will be getting close to the 1.19 release anyway so hopefully 1.18 will have already had several rounds of patch updates. > >> I would expect to maintain the release for 18-24 months from the initial >> release date taking over from the 1.18.X release when or soon after 1.19 >> is released. > > What I normally did was to do a last 1.n-1.x stable update after the new > major 1.n is out. To collect all the fixes that happened during the > stabilization and might have been backported. As SeoZ handles the stable > updated now this migth be a bit different but I still believe he does that. > > That would be the point which makes most sense for LTS to take over imho. Yeah thats what I was thinking > >> I am not planning to backport every possible fix, generally >> only issues reported by users or that manifest either in enlightenment >> or another efl based app, As such it would be a rare occurrence where I >> backported a fix that didn't have an associated bug report, the author >> of the fix would probably have to contact me directly. A example of >> something I probably would backport is >> 4d6a8a7fce51b5654404226668a27d52d1e30eb3 - T3348, This example has a bug >> report containing nice info such as someone has seen the crash and this >> commit will fix it. Examples of things i'm less likely to backport >> include commits with comments such as "while working on blah I noticed >> xxx it was probably wrong and broken and fixed it." or "Potential fix >> noitced by coverty its likely know one will ever see this issue". > > That sounds good to me. Keep the commits to real bug fixes that have > been seen and reported. No need to but all kind of fixes into the LTS > branch. We have master for this. > > Some questions pop into my mind to sort out details here: > o Would you got with the efl-1.18 branch for LTS? That would be Ideal, obviously I don't currently have access to do that so we would need to resolve that. > o Are you ok with other devs putting in backports there as well? Maybe > only after talking to you? Given the amount that currently gets backported to older branches if other devs are happy to go to the effort of backporting then i'm happy to trust there judgment. > o Are planning to do tarball releases based on this branch? Yeah that's my main goal, its much more timesaving and easier to do updates in the form of a release tarball over adding each fix as a patch in the rpm. > > From my side I could keep the efl-1.18 stable Jenkins jobs available > once we switched to 1.19 (normally I remove the old stable jobs) and > name it efl-lts or similar. That way new commits there would at least go > through our normal jenkins builds. Release wise we can work out the > details when it comes up. Mostly putting you into the right group on the > server I think. That would be good. > >> To >> further make this easier it would be nice if fixes include the version >> the bug was introduced in if its easy to figure out or a more general >> this bug has been around for few years or was introduced in the last >> release. > > You might be able to get some people doing this. It would happen rarely > though and likely things will get missed. Be prepared for this. Yeah, I keep a close eye on the git log and will continue to do that. > > I'm very much looking forward to have someone handling efl LTS releases! > > regards > Stefan Schmidt > -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
