On Fri, Apr 10, 2009 at 7:57 AM, Albin Tonnerre <albin.tonne...@gmail.com> wrote: > On Thu, Apr 9, 2009 at 8:45 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: >> On Thu, Apr 9, 2009 at 2:29 PM, Luca De Marini >> <luca.darkmas...@gmail.com> wrote: >>> 2009/4/9 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> >>>> and please, let's try to get these things upstream into debian, ubuntu >>>> and others. At least the base libraries and e17 itself. >>>> >>> >>> Of course. We will be in upstream, I'm sure of it, when we'll be stable. For >>> Ubuntu at least. I don't know debian policies but Ubuntu won't host >>> officially our E17 packages unless they are stable. So, whenever libraries >>> will become stable, we'll be able to ask Ubuntu to host them in their >>> officla repos and time by time, the entire E will hopefully be in Ubuntu :) >>> Don't worry, we'll strictly collaborate, if you wish, to transform this into >>> reality. >> >> often we become unstable, with things like moving ecore/evas to eina >> data types and major refactors, but other than that it works, maybe >> better than most software that is labeled as "stable". Also, it is not >> true that everything in Ubuntu/Debian is stable and all, you can see >> how many packages break now and then, how many request you to export >> weird -DI_KNOW_THIS_IS_UNSTABLE_API and all. >> > > They break the interfaces at a slower pace, though :) > That's IMO the sole reason for e17 not being in ubuntu: it's hard to > push it to a stable release knowing that you'll have to support it for > a long time, during which at least half a dozen API changes will > happen. Otherwise, I would have uploaded the whole stack in ubuntu a > long time ago (and as said on IRC, I plan on uploading what's > currently in debian experimental to ubuntu when it's possible)
i disagree here, it's just a matter of uploading them. DBus went in Ubuntu it was much more unstable yet it was deemed as "core" component. E17 is not core and basic the "leaf" of a system, if it does not work, nothing but it is affected (and its users, of course - but these are either experienced users that know e17 and are just not bothering to compile it or newbies that will try and go back to something else later). > As for the schedule, I think it's better no to plan on the packagers > being able to deliver packages within a day. You probably know there > are a lot of packaging rules (even if the SVN packaging doesn't really > care about them, as it would be a pain, like packages renaming when > there's an interface break and so on), and updating the packages may > take time. I think we could just skip the first build, that will give > some more time. the dates there are mostly for developers, packagers are suggested to act at that time, but if not, just get a revision around that time and do it later. I plan to commit FEATURES-LOCK in /trunk and remove it when freeze is over, you can use those revision numbers to generate it. We're not a company with obligations, rather a community with good will to do things, so no way to force packagers to generate packages at midnight UTC, but if you want to use a script, then you can crond/atd and be happy. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
