[Pkg-e-devel] [Debian] E17 on the FreeRunner

[Carsten Haitzler (The Rasterman)]

On Sat, 28 Feb 2009 02:00:22 +0100 Enrico Zini <enrico at enricozini.org> said:

> On Sat, Feb 28, 2009 at 12:01:08AM +1100, Carsten Haitzler wrote:
> 
> > thats not the way upstream (ie e development) sees it. e17 should install
> > everything for your ui to be functional and useful and get you to the point
> > of running apps to.. install more stuff. thats how we see it. :) you should
> > install it (from source as we deilver it) and have a functional desktop
> > shell ready to go without needing yet more companion apps just to get
> > there. :)
> 
> [...]
> 
> > then.. you are in trouble. your distro policy basically goes entirely
> > against a fast development model. we are not able to help you with your own
> > distro's policies that slow down the rate you can adapt to changes :( there
> > is a reason we haven't stamped out a release - we know we change api's.
> > more rapidly than most places. in fact is is our plan to make lots of them
> > to make sure once we stamp a 1.0 on libs - it wont break much in future. do
> > all the breaks now - while we can.
> 
> You do realise that this means that you will never release any code fit
> for serious adoption?

do you realise your distro policy basically creates a lag of many months
before a release can make it into the distro? actually do you know your distro
also takes years between releases? so long that it can't be used for serious
adoption? (same argument you make about efl can be made about debian - everyone
uses unstable/testing, like everyone uses svn for efl. releases take a looong
time). yes i've done debian development and packaging - admittedly as a
"customised debain distro based off a debian release" and had to deal with the
problem that the base distro was incredibly behind in a tonne of libraries and
utils that needed all upgrading for the custom distro as it was centered around
a specific product whose source was being worked on on more "bleeding edge"
land. it's literally the same exact problem. debian simply creates a fair bit
of work for the scenario where development of upstream is faster than debian
can keep up with due to policies that make it slow to adopt changes. i am not
saying to change your policy - but don't complain when development is simply at
a pace you can't keep up with.

> Anyway, thank you for making it clear: now I know what to expect.

bingo. expect breaks. until 1.0 for libs. after that we will carefully only add
api calls. any breaks will move to anew major version. 1.0 == "stable supported
release from upstream". (excepting E 0.17.0 as that would be considered
equivalently).

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com