On 03/30/2016 07:52 AM, Martinx - ジェームズ wrote: > On 29 March 2016 at 10:02, Stefan Schmidt <ste...@osg.samsung.com> 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! :) >> >>> 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. >> >>> 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? >> o Are you ok with other devs putting in backports there as well? Maybe >> only after talking to you? >> o Are planning to do tarball releases based on this branch? >> >> 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. >> >>> 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. >> >> I'm very much looking forward to have someone handling efl LTS releases! >> >> regards >> Stefan Schmidt >> > > I would like to invest a very small amount of money (maybe Bitcoins) to > bring Enlightenment into Debian with full Wayland support! > > Especially if it is a LTS! > > Cheers! > Thiago
Debian packaging is a very steep learning curve and in order to push to debian repositories on your own you need to be a debian developer or find a sponsor. Unfortunately I don't have time to take this on. You are probably better off asking on the appropriate debian mailing list. If you find someone there feel free to put them in contact with me as I probably have lots of useful info and resources for them. My current plan probably wouldn't be long enough for a whole debian release but if there was someone maintaining debian and they did use the LTS we could look at extending it further if there was critical issues that came up after that time which should hopefully be really limited. Cheers -- 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
