On Wed, Aug 19, 2009 at 7:52 PM, <s...@reboot.sh> wrote: > (back from vacation) welcome back.
> And no, for the desktop, which is what we care about, the long term > gains wouldn't be _that_ big, even for rPath. You're right no longterm solution here, we would always need to either rebase fl every 6 month or replacing the binary import one by one with our own packages, to not end up in the same situation we have now. > 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. So I guess we need to get smart. > some issues will remain untangled - _someone_ need to keep anaconda > synced with upstream in a way to fit desktop's users needs, and someone I fear I don't have enough time to do much more then trying to build what we already have, I wish I would have. Maybe with a lot of rpath guys help we can at least identify where we need to change anaconda. It would even better if we could supply patches upstream, that abstracts all the Packagemanagement thing and use some plugins for each packagemanager one wants to use, but maybe it's already like that. I didn't dive too deep into anaconda yet. > 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 :). I guess you have a picture of how to do that in mind already. Would be nice if you can share how you think it would work. Metadata is still sort of fuzzy. Maybe you can elaborate a bit more on that. > -- *on the community* We still have a pretty welcoming community I hope, at least on irc. Can't say much about the forum. I never liked them, so I'm not using our forum that much. > -- *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. I need to confess that I don't have a fl:2 box right now. One is running 2-devel, one is on 2-qa and the third is a mix of fl:2-devel and group-xfce from xfce.rpath.org. But they all run pretty well. > * 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) Up to know it was just searching anaconda changelog and do some trival changes. If I really need to get their new hardware probing in, I'm probably lost :) > * 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 > * Waiting :-P > All the Best, > > *António Meireles*, aka *doniphon* Mark -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
