Hello. On 09/04/15 10:47, Tom Hacohen wrote: > On 09/04/15 01:14, Carsten Haitzler (The Rasterman) wrote: >> On Wed, 08 Apr 2015 12:31:13 +0100 Tom Hacohen <tom.haco...@samsung.com> >> said: >> >>> On 08/04/15 11:26, thomasg wrote: >>>> On Wed, Apr 8, 2015 at 11:27 AM, Tom Hacohen <tom.haco...@samsung.com> >>>> wrote: >>>>> On 08/04/15 10:20, Stefan Schmidt wrote: >>>>>> Hello. >>>>>> >>>>>> At the EFL Dev Day US during the talk from Lars he brought up the point >>>>>> that EFL is heavily outdated in many distros and platforms. While I >>>>>> instantly agree to this I wondered how bad it really is. >>>>>> >>>>>> I think as a developer as well as a user it makes sense for us to know >>>>>> what versions of EFL and friends are packaged in which distros and >>>>>> platforms. Thus I started to pull together a wiki page for it. >>>>>> >>>>>> https://phab.enlightenment.org/w/packaging_status/ >>>>>> >>>>>> Its a tedious work and I only started today. Feel free to jump in and >>>>>> update the links and versions for your beloved distro. Please go with >>>>>> main package repositories first. You can add a line for a overlay/ppa if >>>>>> it is well maintained. When filling a new field please add the link as >>>>>> you can already see in existing entries. That way we have a page where >>>>>> we can easily look for the latest versions and update. >>>>>> >>>>>> My plan is to fill in more items over time (hoping for some >>>>>> crowdsourcing here) and run a quick update of versions numbers once a >>>>>> month (already set a calendar entry for it). >>>>> I wrote "latest" for every package of Arch. It's too crazy to maintain >>>>> it for Arch, and it's always up to date anyway. >>>> If it's too crazy to update a wiki page, no wonder the maintainers >>>> might find it crazy to do up-to-date packaging :P >>> It's too crazy for us to maintain 2000 boxes of a table. :) >>> Yes btw, we release too often nowadays (the micro releases), and it's >>> becoming more and more annoying to stay up to date, and I think that's >>> why Arch has been so slow recently with micro releases for the efl. >> look at: >> >> https://www.enlightenment.org/doku.php?id=download-latest >> >> look at the top - it's a bunch of variables for version of that package. >> that's >> it. url and label is generates from the vars. just update those vars at >> release >> of anything (add more vars and table entries when new stuff is being released >> that wasn't before). >> >> > I'm talking about two things: > 1. Maintaining the 2000 cells of the table. You have to check the > distro's websites (or script it, and then it's fine) in order to update > those. Your approach doesn't matter there.
Its easy to make it sounding scarry when using factor 10. Its actually 231 cells. Not all of them need to be updated. If someone wants to script this I would be happy. Given that I do not see this happening I will do it manually and see how this goes. > 2. Building new EFL packages. Building a newer version is easy, that's > not the problem. The problem is testing. At our current rate, if > maintainers follow our releases they need to build and *test* packages > way too often, and testing takes time. > >From what current rate do you talk here? We have two stable updates for 1.13 which out for two months. That sounds like we are still having one stable update per months on average. Which is more or less what we had all the time. Around 3-4 stable updates per major release. A month is not enough time to update a package? I try to not have to many of them (my initial goal has been 4-5 but I decreased this over time) but they are essentially bug fixes which we should offer our users. If you take 1.13.2 as example there was a evas use after free fix which was tracked for a long time and it was asked by the user to make a stable update with this. So in summary it means balancing the needs of updates and reducing the amount of updates we do. I think one stable update per month on average is good. regards Stefan Schmidt ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
