On 09/04/15 10:22, Stefan Schmidt wrote: > 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.
The original point has become moot ever since you said you only wanna update it once a month, it's OK (I guess) to spend 15minutes a month on that, and the value is obviously worth it. Stable update a month is great. I did the math wrong, I was under the impression it was once every two weeks (and I think I mentioned that). Bottom line: sorry for the noise. -- Tom. ------------------------------------------------------------------------------ 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
