packagekit need more powers :S waiting for the next email ...
On 8/19/09, s...@reboot.sh <s...@reboot.sh> wrote:
> (back from vacation)
> --
>
> Michael's (mkj) series of missives, and the chain of reactions they
> got, touch a wide array of issues that while interconnected are
> separate, and very different, some of them not even foresight specific.
>
> bellow, i'll do my best to address, and comment, those.
>
> -- *on history, overall identity*
>
> <context>
>
> Foresight was started, by Ken, as an overlay on top on rPath Linux 1
> (rPL1) to provide the _latest_ gnome bits. Early, _latest_, mean
> that the goal was to get any stable gnome release available on
> foresight, in a clean, lightweight, tasteful fashion, on its very
> release day. This latest bit, being a _binary_ rolling distro was
> basically our early claim to fame. The axioms were, built on top on
> rPL (rpath linux) and using conary. Given that, over the last years
> the core operating workflow of foresight development has been
> basically this - Integrate/Provide/Release Gnome (and KDE/XFCE)
> releases on schedule, _and_ implement any kind of mods underneath
> (on top of rPL) to make that happen (Xorg, migration to python26,
> etc). Other than a few major standalone 'bricks' (xulrunner/ffox,
> OOO) everything else was secondary and subsidiary. I and ken
> handled Gnome, Int and jtate kde, and MarkT xfce. In addition to
> this i took care of making sure that at a wider (group) level
> everything was kept minimally consistent. This all happened on
> fl:2-devel. Then, Ken and pcutler, handled -2qa and general
> releases, with ISOs and so on.
>
> </context>
>
> >From the start, foresight was an odd beast, as it tried to do things in
> a different way, from everyone else. _before_ we had source based
> distros, and the 'normal' ones. on source based distros, one gets the
> very latest, at a price, and on the 'mainstream' ones one, on paper,
> gets some stability, at the cost, of being conservative. Foresight
> wouldn't fit in any of those categories, as its purpose was, and is, to
> mesh the bleeding-edginess of the source distro with the predictability
> of the timed release ones, turning it something consumable by mere
> mortals. Understanding this, and its full implications, is key, as
> this turns to be the problem we are trying to solve.
>
> that problem, could be summarized into something like ...
>
> The (distro) timed release model at large - specially for desktop
> plays - doesn't work, much less scale, for practical reasons : there
> are tons of oss projects with tons of development models, completely
> disparate release schedules, that will never ever agree on global
> matching release schedules. This has profound implications, which
> often imply planning within 2/3 releases of advance, gets too much
> 'innovation' packed into small times slots, as end users, get to
> digest too much stuff/change at once, at time of every major distro
> release, and overall, IMHO, it ends slowing down the overall pace of
> (open-source software) innovation, as it either increases latency
> (with newer stable stuff being delivered later, sometimes _years_
> later, which is bad, or getting into the public, into
> pre-release/unstable form - to meet distro schedules/deadlines,
> which isn't good either).
>
>
> Then, _our_ attempt of a solution to that problem would be formulated
> into something like ...
>
> to build/maintain, using 'stock/upstream' a distro, _suitable_ to
> end users, in a way that all its different building blocks, could be
> managed asynchronously, while maintaining overall consistency, i.e.
> being able to at, any given time, update/touch/modify any part of
> the whole stack without breaking it.
>
>
> This is what we kept trying to do, with more or less success, until today.
>
> So, bullets points to retain here are ...
>
> a) is the 'problem' described above the one _we_ as a community want to
> solve, or put it - another way - is it worth of being solved ?
> b) is it 'constrained' enough so that it can be solved in a finite
> amount of time, with finite resources, i.e. can _we_ ever solve it ?
>
> -- *on conary, rPath, the development model, and everything in between*
>
> conary, and related tools, didn't get picked by Foresight by any sort of
> 'religious' question. conary got picked because it was, and still is,
> simply the best tool available in order for us to try to achieve the
> goals we proposed to (ken only got into rPath well after giving birth to
> Foresight). Yes, in many fronts, foresight development needs/goals were
> the main drivers of lots of conary/rMake/rBuild{,er} fixes and new
> features, but rPath objectives, and Foresight ones, never were quite the
> same, nor they had to be. Over time we developed a symbiotic
> relationship where in exchange of getting 'burn testing' for free,
> rPath, whenever they could, improved their tools/offerings in order for
> us to give wings to our imagination.
>
> Getting to the point, as much as i like conary, and co-related tools,
> they are just that - tools. An OS doesn't get better or worst, just by
> being wrapped around conary, yes, it gets more resilient, but IMHO,
> opinion that isn't enough. Foresight pursuit isn't to use conary at any
> cost, under any conceivable scenario, Foresight pursuit has been to use
> the best tools to do the job we proposed to - to deliver the best distro
> experience, being the early provider of stable upstream bits, whatever
> they are, whatever their level at the stack. That tools, happen to be
> conary related.
>
> Yes, i do know, that today, is relatively trivial, to rPath and with
> 'controllable' effort, to wrap almost anything (binary-built) with
> conary, from Ubuntu, to OpenSuse, SLES, CentOS, Scientific Linux and, of
> course, Fedora;
> Yes, i see the point of it, it's 'cheap', it works, and one gets
> something a bit more deterministic and resilient than the original.
> I even foresee a good bunch of use cases for which getting a (conary)
> re-wrapped fedora would be a good thing.
>
> But then, in the name of consistency, and coherency please _don't_ call
> it foresight, because, well, Foresight wasn't intended to be something
> like that, from the start...
>
> And no, for the desktop, which is what we care about, the long term
> gains wouldn't be _that_ big, even for rPath.
>
> Conary isn't Foresight, nor vice-versa, but it is conary that allows us
> to scale, it is conary that allows us to glue things in a (we try)
> consistent fashion, and that - my friends - turns sometimes conary into
> our biggest enemy. It's so well wrapped, so simple, so beautiful, so
> logic (most of the times) that some expect _everything_ around it to be
> as simple as calling the AutoPackage superClass in a recipe. Well, in
> the end conary scales only, is only as smart, as the ones using it.
>
> We, as a community, have a real problem - lack of resources, not lack of
> passion, not of love or great ideas, but resources. Our time are
> limited, our talent is limited, and we all have other things to do. So
> we need to be creative, bold, do more with less, define priorities.
> Also, a good chunk of that talent is at rPath, another good chunk, was
> there in the past, and today is direct or indirectly bound to
> 'non-competes', and then, there 's the non trivial problem that what we
> are trying to do wasn't ever done before, which means trial, and error,
> and lots of time, the most valuable asset of all...
>
> If, as Og implicitly conceded in one of his mails on this thread, one
> admits that the _end-goal_ may _just_ be to have _something_ managed by
> conary, then yes we are all wasting our time. There are simpler ways to
> achieve that, and re-wrapping with conary Fedora blobs is an option.
>
> If not, and _i_ think the end goal, shouldn't be that one, even in the
> sake of conary's own long term success, then we need to find ways to
> scale, and _grow_ (in all the senses of the word) And scale means lot of
> things...
>
> Means to get a consensus on the strategy we want to follow, and _how_ to
> get there. It means, given that most of the talent we need/depend is at
> rPath, to find ways not to scare/overclock it, to the point, of
> Foresight development stealing too much of rpath's key personal quality
> time. It means increasing the 'not related to rpath' talent pool, it
> means rethinking what our community is, acts and behaves, it means
> rethinking/streamlining a lot of things. That's, btw, is where i hope,
> we stand now.
>
> -- *on those damn tricky details*...
>
> I don't see any kind of overlay, in the way we had/have in the past for
> Gnome/KDE/Xfce/Xorg/whatever/moblin as a viable scenario on top of
> _someone_ else BLOBs. We need to have the ability to at any given time,
> touch, any layer of the stack, if we can't do that, we get no rolling
> stuff, no illusions about that, be them from rawhide or somewhere else;
> At source level, things are different. Yes, one can with a limited
> amount of effort wrap 'legacy' build tools (rpm/deb) and pipe them into
> ours - way better, but with limitations, as we loose, as in the blobs
> import, some of expressiveness that _only_ an end to end use of conary
> allows. Also, in either 3 models, from (conary recipes) source,
> re-wrapping 3rd party blobs, and from source piping 3rd party tools,
> some issues will remain untangled - _someone_ need to keep anaconda
> synced with upstream in a way to fit desktop's users needs, and someone
> needs to properly get PackageKit married with conary (if that desktop
> is to be taken as something serious) as that is something users expect.
>
> Anyway, other than the time/resources issue, IMHO, the main issue in the
> scalability front is to define/sort the best way to leverage the immense
> conary potential, in order for our goals to be achieved. I 'd like
> everything to be meta-data driven, from ground up, from recipe
> maintenance, to group handling. as it would make things immensely
> simpler than they are today. Ambitious ? certainly; Simple ? no way.
> Worthy ? i think so :).
>
> -- *on the community*
>
> Traditionally informality has the rule in foresight land, in fact i
> don't remember ever someone having vetoed or blocked anything. Now,
> albeit, on practice, nothing has changed, some feel somewhat orphans -
> Ken, our founder, has other issues to worry about - it's paid for that,
> and to some that translates in some sort of identity crisis. As i said
> before, we are what we are - either we want to be part of a solution, or
> prefer to be part a problem, real or imaginary, sitting, or waiting, for
> miracles to happen. Adapt and evolve is key. In order to scale, grow and
> survive, we will need to get more disciplined and focused, to pass (to
> the outside and among us) the right message. Yes, the end user is our
> target, yes we want to deliver things in the simplest fashion, yes, we
> want to cover 100% of the market but our resources are limited, but
> _right_ now we can't be all things to all people. We need pick choices,
> to admit that right now we may have too many editions, for too few
> man-power, too many packages for too few developers. We need to
> communicate better, document better, and get everybody to understand
> that not all things are equal. To admit that we need help, that perhaps
> our marketing message, short term, should be to target more (non aligned
> distro) developer oriented, and so on.
>
> And we need to keep being humble. We got a long journey already, and, in
> some ways, sometimes, success seemed easy, too easy, it never is, and
> when one thinks it is/was, usually is wrong, dead wrong...
>
> -- *on short term actions*
>
> If we can't say fairly that 2-devel - currently - is in a much worst
> state than it was ever, (isn't), fact is that the speed of propagation
> to 'exposed' fl;2 slowed a lot. as basically things get stalled into
> 2-qa. Yes, it's a matter of typing a few commands to get things pushed,
> but then we do know that anaconda needs a refresh, and _that_ update
> only is safe after a given amount of testing is done, and in a sane
> manner. So, the dilemma quickly turns into what is worst - update at
> risk of breakage (and the fact that things generally seem to work in
> fl:2-qa is not enough insurance as 2-qa users are typically not a good
> sample of an end-user, as usually more savvy and prone to solve issues)
> or not to update, passing the idea of 'stalliness'. If one goes and look
> at the logs, main topics of the two latest Council meetings has been how
> to get around this.
>
> very short term, IMHO, what we face, need to solve, is...
>
> * Restate the flow from 2-devel -> 2-qa -> fl:2, managing the QA side,
> which means assembling a reliable team to it with the time and the mix
> of qualities/know-how of those who made it in the past.
> * Fix/update anaconda, needed to get updated ISOs out. (MarkT making
> good progress on it)
> * Get the PackageKit conary back-end saner, less hungry than what it is
> today.
>
> I repeat - this is very short term - as none of this will solve will
> solve, long term, the root issues, but then, this should allow for some
> 'normalization', in the meantime.
>
>
> --
> *to be continued in next 24hrs
> *
>
> All the Best,
>
> *António Meireles*, aka *doniphon*
>
>
>
> _______________________________________________
> Foresight-devel mailing list
> Foresight-devel@lists.rpath.org
> http://lists.rpath.org/mailman/listinfo/foresight-devel
>
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
