future ideas
Andrew D Kirch
don't often participate, and though we try to avoid politics here, I
want to provide some political background over at Gentoo to describe
what's happening, how it's affecting us, and how we can choose to move
forward. NB this is an early draft, I'm of course not Dan, but I do
have a particular and unique insight into this as I'm much more of a
civics and politics geek than a coder (ask Dan how often I gripe about
having to pull out his developer works stuff when I go behind him to
change stuff if you don't believe me)
Gentoo's in an ugly scenario where there are a lot of people in charge.
Ignoring Infra and Trustees, you have the Gentoo council voted on by
devs yearly who vote on matters brought before them. The previous
council was dominated mostly with concerns over GLEP's 54 (handling SCM
packages in portage) and GLEP 55 (donating EAPI by suffixing the .ebuild
extension), and EAPI-3. Most of these proposals were entirely hijacked
by the Paludis development lead Ciaran McCreesh. You also have
user/devrel who step in to try to keep people playing nicely.
Ironically they're so tired of dealing with Ciaran complaints (of which
there are at least 7 in b.g.o, one of which resulted in his termination
as a Gentoo dev) that they will refuse to be a neutral party when he
becomes a problem. I spent the majority of the summer (as Daniel has
jokingly referred to it as my flamewar) trying to sort this mess out,
and I have to admit that I have failed.
Realizing this I have a solution I've brought up before which would be
exceptionally labor intensive, but beneficial in the long run.
1. The current aim at compatibility with Gentoo while a huge benefit is
going to become a long-term detriment as the stagnation of innovation
continues there. It also poses a significant risk that that stagnation
of innovation might creep in at Funtoo, and indeed such attempts have
already occurred. http://bugs.gentoo.org/show_bug.cgi?id=273261. This
for what it's worth is a bitter pill to swallow as many invested a lot
of time into Gentoo, some a large chunk of their lives.
2. We need to look at this history of Gentoo, learn from it, and try to
take a snapshot from where things went wrong and continue forward
productively. In doing this we need to standardize on a package
manager, which thus far has been portage. Thoguh I'd advocate a look at
the history of portage as perhaps the most current version doesn't serve
us best.
3. this would require an increase in time and developers obviously, and
with that will come some sort of organizational system (Daniel scales no
better than Linus, and I probably not as well as either of those).
4. initially we would want to focus on an initial base of 500 or so
packages making up stage 3, editors, logging, common apps, and basic X11
5. during this process the behavior of portage needs to be examined and
fixed, especially pertaining to slotting, and the integration of myriad
"tools" which should be basic portage functionality but are not
(examples including but not limited to revdep-rebuild, depclean,
python-updater, eix, etc)
6. a serious effort and thought needs to be put towards QA, and tools
like repoman, and other tools which prevent bugs.
7. this needs to be done with a structure of governance removes Daniel
from the need to work a full time volunteer job at no pay (I'm not
looking to sign up for lots of work and no pay either!). I think a lot
of discussion of project size and goals have to be put here along with
how we intend to accomplish this. What I don't want is a massively
complicated constitution: http://www.oftc.net/oftc/Constitution. I
don't think we're looking for a for-profit system either, though if one
were found, it would be examined.
8. it should be very clear that this recommendation is in many ways a
recommendation that we start over (or nearly over), and rely on overlays
to decentralize development
9. avoid the urge to create red tape, restrictions, and lots of
governance, it's already crippled Gentoo with indecisiveness. We need a
BFDL-like system without putting the time requirements on a sole BFDL.
This will probably result in a bit of a secret cabal which is fine. (or
perchance a military junta which would allow me to disappear political
enemies (excellent!)). But this should be the development model for
each overlay (apache, kde, gnome, openoffice, etc)
Andrew D Kirch
Moesasji
> recommendation that we start over (or nearly over), and rely on overlays
> to decentralize development
Although many of the above points make sense to me I would just like
to pick out the last two points to comment on as personally I think
that doing all development in overlays is the wrong approach from a
user perspective and I would strongly advocate keeping as large a tree
as possible (provided it is maintainable).
A user wants to be able to type "emerge -av <random package>" and get
it installed instead of trying to find the correct overlay (or digging
the ebuild out of bugzilla!). The power of just having a single
command to install software should not be lost...searching for
packages in overlays to me feels too much like trying to find the
correct drivers/software under windows.
Currently once found the package in an overlay you just have to hope
that you don't get some strange incompatibilities because eclasses can
be overwritten without warning as there doesn't appear to be any
version-management for those in Gentoo. As a sidenote: I find
installing complicated packages not in the tree relatively difficult
to do on Gentoo in comparison to a distro as Arch Linux maybe partly
because of the fact that a lot of the logic is hidden in the e-
classes, combined with a lot of changes compared to upstream config-
files and/or file-locations.
Although it might just be the choice of words? Referring to moving to
"overlays" also seems to omit the benefits that have been introduced
by using a distributed development approach through Git. Incorporation
of coherent sets of packages such as for example Gnome could be done
by others in their branch and if good be integrated into Funtoo by
pulling by the BFDL. With the benefit that the average user knows
where to look as he/she would typically run from the branch of the
BFDL....in that sense much like the model used in the kernel
development where Linus typically pulls from people he trusts. In that
sense the rant by Linus on the philosophy of Git as linked to on the
FAQ (http://www.youtube.com/watch?v=4XpnKHJAok8) made clear to me why
he so strongly advocates the Git-model. In particular as it is easier
for people to step in and fix something without a lot of red tape
preventing this to happen.
Clearly it would take time to built up such a network of trust and
contributers, but having clear "unmaintained" bits still in the tree
with large warnings might actually stimulate users to step in and try
to fix those problems provided there is not too much red tape. One
point to think about might be what steps are needed to get through
this transition-phase from an early point.
Oleg
Let me write down my thoughts,I sure this "gentoo" overlay' will not be "try-to-find-the-package-i-need-overlay", it will be good one.About
portage tree-the idea of all funtoo project is to improve core packages (the ones included in stage3) and next level will be splitiing off the core
package ebuilds and clean them off gentoo eclasses, unneeded tools, perl-cleaner hell, wrappers (iam not an exepert here).The resulted core tree will be
absolutely clear, easy maintanable.Probably there will be funtoo-ized portage as well to satisfy the idea of core-tree.I feel that such lightweight
build is more server-oriented, but I really like it. Also as Andrew said, there will be not only stage3 ebuilds, but also very useful tools and
every-day-usage packages,so I exepecting some kind of "real" release, like iso, where you can find core-stage+tools,also providing binary packages, you
can easy install the system and work from that.If you unsatisified, then you can add a "gentoo" overlay, but then you are "doomed" to use all the stuff current gentoo has.In this way, the system will be easy (not "for everyone" for sure) but attractive with
it's usability, lightweightness, good for embedded , study purposes (you really learn how is your system build from source, for example, in more mature
way compared to LFS).I spent many hours (days, weeks, as many others did so) by fixing my failed emerges or patiently waitng for next sync and fixes
from crappy-designed ebuilds, yet still gentoo is the best OS i found.I really dislike DE, xorg, other monstrous packages, that's why i keep my world as
small as possible (175 pckgs) and it works great.
Kind regards, and Merry Christmas for all funtoo users.
Moesasji
I really like the idea of a "cleaned-up" core that is easier to
understand for the average coder and does not change that often!
However I would seriously worry if the ultimate goal of funtoo would
be to only focus on the core-set of packages as you don't really use
the benefit for the larger tree that the move to Git can have (my
assumption is that this is currently the focus mainly because of man-
power reasons and you anyway have to start by cleaning up the
foundations before one starts building the rest).
To me "ignoring" the bigger tree almost feels like a step backwards as
you get much closer again to the FreeBSD model (or to Slackware!)
where the core is excellent and good for a server, but adding packages
onto the core is definitely not that straight-forward compared to
Gentoo in its current form. Something that I think would get even
worse if development of packages not in the core would only happen in
overlays and never be integrated into a coherent/complete tree, but I
might be wrong on this. But once again, my question would be how you
could benefit from the use of Git here? (as to me overlays seem to be
a model that working well(/is needed) with SVN where few people have
commit access to the main tree)
---footnote---
*) I have in the past played with FreeBSD and Gentoo was definitely an
improvement in ease of maintenance, mainly due to "use-flags" being
better integrated into the package-manager. Slackware was also nice to
run, but again maintenance in my opinion became very painful when too
many packages are added to the core-set as the package-manager does
not support you. Although I must say that it was much easier to get
something not existing as a Slackbuild to install on Slackware in
comparison to Gentoo if you don't have an ebuild (and yes I have read
the devguide).
**) I find the PKGBuilds from Arch (or Slackbuilds which are very
similar) much easier to understand as options can be compared to the ./
configure options of the packages and all the code is mostly in the
script. (I often have trouble figuring out what a use-flag exactly
does as a lot of "descriptions don't tell much). Yet I really missed
the flexibility of tuning use-flags through the package-manager on
Arch as it pulled in an awful lot of stuff I didn't want by default
and once you started compiling your own you don't have that good of an
overview in comparison to using portage.
Andrew D Kirch
serious exception. Portage is MASSIVELY more capable (staggeringly more
capable) than the FreeBSD ports system. With tools such as layman,
ANYONE can start an overlay project for Gnome, KDE, LAMP, GPS/NAV (MINE
MINE MINE!), OpenVZ, Xen, etc. This would allow small dedicated groups
to work totally independently of core.
In response to a previous e-mail, though I'm not a huge fan of the
"stick everything on a CD" suggestion, there has been serious discussion
of high quality binary packages. I'm really a fan of this goal as it
allows for some additional flexibility, and any standard bootable CD
will still work as install media.
Andrew
> --
>
> You received this message because you are subscribed to the Google Groups "Funtoo" group.
> To post to this group, send email to funto...@googlegroups.com.
> To unsubscribe from this group, send email to funtoo-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/funtoo-dev?hl=en.
>
>
>