On Fri, 2009-04-10 at 11:41 -0300, Gustavo Sverzut Barbieri wrote: > 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).
seriously, even pulseaudio went in a release that had a long-term support. and most people didn't hear shit with pulseaudio around. arguably, it's gotten better since then, but it was a very, very rough ride > > > > 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. > ------------------------------------------------------------------------------ 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
