Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Jesús Guerrero wrote: Most Gentoo users will have no problem to use overlays as they need them. If we had more developers we could as maintain more packages, as simple as that. I actually tend to agree with this position, however to use overlays as a valid solution for end-users we need to do more to support them. Right now it is at least a little painful to get set up with an overlay. There also isn't really any official place to vet overlays, and there isn't any official source for overlays that aren't maintained by gentoo. Sure, overlays.g.o has tons of overlays - but which ones are mostly-stable, and which ones are intended to break systems? What is the QA policy for each overlay? If I'm an end-user not interested in breaking my system, what overlays are safe for me to use? If we really want overlays to be an outlet to allow more non-devs to contribute, then there needs to be some way to standardize them. Maybe a simple ratings system - an overlay needs to comply with one set of rules just to get listed on o.g.o. If you want to be marked as stable, then you obey some additional rules. And so on... Then we can have overlays of various types for various purposes, and users can pick which ones they want to follow. We could also have things like overlay groups - like stable or desktop or KDE / etc. Maybe a fancy GUI to allow users to configure all of this. Of course, for this to work somebody needs to develop it. If somebody were willing to do the work I doubt anybody would get in their way. It isn't like any of this would interfere with anybody who just wanted to make their own overlay without rules and not have it listed on some official site.
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
On Sun, 13 Sep 2009 06:47:27 -0400, Richard Freeman ri...@gentoo.org wrote: Jesús Guerrero wrote: Most Gentoo users will have no problem to use overlays as they need them. If we had more developers we could as maintain more packages, as simple as that. I actually tend to agree with this position, It's not something to agree or disagree. There aren't developers to maintain all the software under the sun, period. however to use overlays as a valid solution for end-users we need to do more to support them. Yeah, devs for that as well. Right now it is at least a little painful to get set up with an overlay. No, it's a matter of using layman -a whatever There also isn't really any official place to vet overlays, and there isn't any official source for overlays that aren't maintained by gentoo. Sure, overlays.g.o has tons of overlays - but which ones are mostly-stable, and which ones are intended to break systems? What is the QA policy for each overlay? If I'm an end-user not interested in breaking my system, what overlays are safe for me to use? There's no policy. Just like unofficial repos for any other distro. We can't control that. It's outside Gentoo. While I agree that having more packages and being more up to date is a good thing, I can never agree that we should sacrifice Gentoo for that. You want stability for what I see on your answer, well, that's what you have. I don't think we can do any more with the number of developers we have right now unless we start dumping blindingly and without any check every ebuild that we get across. -- Jesús Guerrero
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Jesús Guerrero wrote: Yeah, devs for that as well. Yup - I think we're actually on the same page. Ultimately quality matters more than quantity and everybody does what they can given the resources we have. Right now it is at least a little painful to get set up with an overlay. No, it's a matter of using layman -a whatever Sure, and that is fine if overlays are intended only as experimental development spaces. However, some (not necessarily including yourself) advocate that it is perfectly fine that the portage tree gets stale since we have all those overlays. That certainly is a possible approach to take, but to go that route overlays need to become more robust. Right now they're really not a replacement for /usr/portage. There's no policy. Just like unofficial repos for any other distro. We can't control that. It's outside Gentoo. Exactly. And, because it is outside of Gentoo - packages in overlays don't count when we consider how up-to-date Gentoo is. If we want to say that package foo isn't stale because there are recent versions in some overlay, then Gentoo needs to take responsibility for the overlays. That might be as simple as being a gatekeeper - auditing overlays and booting ones that drift out of control. I don't think we can do any more with the number of developers we have right now unless we start dumping blindingly and without any check every ebuild that we get across. Absolutely. The whole logic behind going to an overlay-based approach is that it allows developers to leverage external help more effectively - a developer can essentially delegate a whole mini portage-tree to some other entity to manage, simply providing oversight and QA. In theory you could even have official overlays - which would allow better delineation of responsibilities (you don't need to grant people commit access to everything - just their project's overlay). Ultimately, as you argue, it doesn't make a difference if nobody is willing to step up and actually maintain ebuilds. Personally, I like the overlay idea, but right now it just isn't necessary. In theory proxy maintainers work almost as well, and we're not really making heavy use of this model right now. If we had hundreds of users submitting high-quality ebuilds in bugzilla and simply couldn't find enough devs to commit them all, then a more overlay-based approach would help reduce the bottleneck of having a centralized group of committers. Right now we probably have far more devs than proxy-devs, so the need to delegate the tree further really isn't there.
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Jesús Guerrero wrote: On Sun, 13 Sep 2009 06:47:27 -0400, Richard Freeman ri...@gentoo.org Right now it is at least a little painful to get set up with an overlay. No, it's a matter of using layman -a whatever I think Richard was including the manual setup required to use layman and the procedure required to add overlays that are not in layman-global.txt. I agree, that both are no fun. I wrote a tool layman-add a while back to ease up the latter, because I felt it sucks so badly. Sebastian
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Richard Freeman wrote: Personally, I like the overlay idea, but right now it just isn't necessary. In theory proxy maintainers work almost as well, and we're not really making heavy use of this model right now. I disagree about this. One of the reasons my overlay is fun to me is because I am _not_ proxied. Sebastian
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sebastian Pipping wrote:
Hello there!
Among other information the Gentoo page at DistroWatch [1] displays a
table on about 200 selected packages [2] and how up to date Gentoo is
per package. I assume that DistroWatch is still one of the first places
people go to get a feeling for a Distro they heard about, besides
Wikpedia and ${distro}.org.
The freshness of these 200 packages have influence on how people
perceive Gentoo on DistroWatch. While the tree as a whole is what we
should keep as up to date as possible keeping these 200 packages (list
further down) up to date can therefore be of particular importance.
From a quick look at the table these packages seem to need extra care in
Gentoo:
cups (1.4.0) 1.3.11 -- latest in Gentoo unstable/testing
koffice (2.0.2) 1.6.3
There has been koffice-meta-2.0.2 for a while.
mysql (5.1.38) 5.0.84
perl (5.10.1)5.8.8
php (5.3.0) 5.2.10
samba (3.4.1)3.3.7
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqrhLwACgkQp/VmCx0OL2xRjQCfUPpebxYVEaUC2aMAgFGOm8ov
Y/oAoLWiRr4kXCsS/JCFb6R5mleJKCqi
=DENW
-END PGP SIGNATURE-
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Aaron Bauman wrote: Sebastian, I definitely admire your point and know that through your tracking and Google SoC project you have good visibility on this I do however have to disagree. As much as I enjoy the open source community and admire the products they put out I do believe Gentoo has the right approach to packaging. My standpoint is that Gentoo always ensures stability in the fact that we require packages to be tested prior to release in the main portage tree and secondly the Gentoo developers always ensure security as best as they can. These I believe are what keep the portage tree somewhat behind the latest and greatest and as always there are overlays and options that allow users to pull these packages down if they want. I believe the great thing about Gentoo is the choice of whether to be cutting edge or not. If I have missed anything please let me know. I don't think we should trade away quality. You said you disagree with me but with that said I don't see at which point. Sebastian
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Marijn Schouten (hkBst) wrote: koffice (2.0.2) 1.6.3 There has been koffice-meta-2.0.2 for a while. Good catch, thank you! Sebastian
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Sebastian,
I definitely admire your point and know that through your tracking and
Google
SoC project you have good visibility on this I do however have to disagree.
As much as I enjoy the open source community and admire the products they put
out I do believe Gentoo has the right approach to packaging.
My standpoint is that Gentoo always ensures stability in the fact that
we
require packages to be tested prior to release in the main portage tree and
secondly the Gentoo developers always ensure security as best as they can.
These I believe are what keep the portage tree somewhat behind the
latest and
greatest and as always there are overlays and options that allow users to pull
these packages down if they want.
I believe the great thing about Gentoo is the choice of whether to be
cutting
edge or not. If I have missed anything please let me know.
On Friday 11 September 2009 19:02:44 Sebastian Pipping wrote:
Hello there!
Among other information the Gentoo page at DistroWatch [1] displays a
table on about 200 selected packages [2] and how up to date Gentoo is
per package. I assume that DistroWatch is still one of the first places
people go to get a feeling for a Distro they heard about, besides
Wikpedia and ${distro}.org.
The freshness of these 200 packages have influence on how people
perceive Gentoo on DistroWatch. While the tree as a whole is what we
should keep as up to date as possible keeping these 200 packages (list
further down) up to date can therefore be of particular importance.
From a quick look at the table these packages seem to need extra care in
Gentoo:
cups (1.4.0) 1.3.11 -- latest in Gentoo unstable/testing
koffice (2.0.2) 1.6.3
mysql (5.1.38) 5.0.84
perl (5.10.1)5.8.8
php (5.3.0) 5.2.10
samba (3.4.1)3.3.7
Packages not found in Gentoo that DistroWatch monitors across discros are:
apt
synaptic
.. Debian stuff, that Gentoo does not have packaged
apache
mod_ssl
.. Apache 1.x seems gone from Gentoo (I suppose security)
openjdk
.. Not packaged in Gentoo, no idea why
checkinstall
Miro
.. Not in official tree (yet?), available through an Overlay
xmms
.. Removed for security reasons, available through an Overlay
Maybe we should move Miro to the main tree?
Since today DistroWatch's sources on tree freshness are [3] and [4] as
they provide more accurate data than previously used sources do.
What is the process to migrate the generating script over to Gentoo
infrastructure?
See you,
Sebastian
[1] http://distrowatch.com/table.php?distribution=gentoo
[2] http://distrowatch.com/packages.php
[3] http://www.hartwork.org/public/distrowatch_gentoo_x86_latest_stable.txt
[4]
http://www.hartwork.org/public/distrowatch_gentoo_x86_latest_unstable.txt
List of all Gentoo packages currently monitored
===
abiword app-office/abiword
AfterStep x11-wm/afterstep
alpine mail-client/alpine
alsa-lib media-libs/alsa-lib
amarok media-sound/amarok
apache-tomcat www-servers/tomcat
ati-driver x11-drivers/ati-drivers
audacity media-sound/audacity
autoconf sys-devel/autoconf
automake sys-devel/automake
avidemux media-video/avidemux
banshee media-sound/banshee
bash app-shells/bash
bind net-dns/bind
binutils sys-devel/binutils
bison sys-devel/bison
blender media-gfx/blender
bluefish app-editors/bluefish
bzip2 app-arch/bzip2
cdrkit app-cdr/cdrkit
cinelerra media-video/cinelerra
compiz x11-wm/compiz
coreutils sys-apps/coreutils
cups net-print/cups
curl net-misc/curl
cvs dev-util/cvs
db sys-libs/db
DeviceKit sys-apps/devicekit
dhcp net-misc/dhcp
diffutils sys-apps/diffutils
digikam media-gfx/digikam
dillo www-client/dillo
dosbox games-emulation/dosbox
dovecot net-mail/dovecot
doxygen app-doc/doxygen
e2fsprogs sys-fs/e2fsprogs
eclipse dev-util/eclipse-sdk
emacs app-editors/emacs
enlightenment x11-wm/enlightenment
epiphany www-client/epiphany
evolution mail-client/evolution
exim mail-mta/exim
fetchmail net-mail/fetchmail
ffmpeg media-video/ffmpeg
file sys-apps/file
findutils sys-apps/findutils
firebird dev-db/firebird
firefox www-client/mozilla-firefox
flex sys-devel/flex
fluxbox x11-wm/fluxbox
freetype media-libs/freetype
f-spot media-gfx/f-spot
gawk sys-apps/gawk
gcc sys-devel/gcc
gettext sys-devel/gettext
gftp net-ftp/gftp
ghostscript app-text/ghostscript-gpl
gimp media-gfx/gimp
git dev-util/git
glade dev-util/glade
glibc sys-libs/glibc
gnucash app-office/gnucash
gnumeric app-office/gnumeric
gnupg app-crypt/gnupg
gparted sys-block/gparted
grep sys-apps/grep
groff sys-apps/groff
grub sys-boot/grub
gstreamer media-libs/gstreamer
gtk+ x11-libs/gtk+
gzip app-arch/gzip
hal sys-apps/hal
httpd www-servers/apache
icewm x11-wm/icewm
ImageMagick media-gfx/imagemagick
inkscape media-gfx/inkscape
iptables
