Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

2009-09-13 Thread Richard Freeman

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

2009-09-13 Thread Jesús Guerrero
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

2009-09-13 Thread Richard Freeman

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

2009-09-13 Thread Sebastian Pipping
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

2009-09-13 Thread Sebastian Pipping
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

2009-09-12 Thread Marijn Schouten (hkBst)
-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

2009-09-12 Thread Sebastian Pipping
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

2009-09-12 Thread Sebastian Pipping
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




[gentoo-dev] DistroWatch and Gentoo packages: status quo and future

2009-09-11 Thread Sebastian Pipping
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 net-firewall/iptables
jre dev-java/sun-jre-bin
k3b app-cdr/k3b
kaffeine media-video/kaffeine
kdebase kde-base/kde-meta
kdevelop dev-util/kdevelop
kdewebdev kde-base/kdewebdev
koffice app-office/koffice
krusader kde-misc/krusader
ktorrent net-p2p/ktorrent
less sys-apps/less
lftp net-ftp/lftp
libgnome gnome-base/libgnome
libselinux sys-libs/libselinux
libtool sys-devel/libtool
libvorbis media-libs/libvorbis
lighttpd www-servers/lighttpd
lilo sys-boot/lilo
links www-client/links
linux sys-kernel/vanilla-sources
lvm sys-fs/lvm2
lxde-common lxde-base/lxde-common
lynx www-client/lynx
lyx app-office/lyx
m4 sys-devel/m4
MailScanner mail-filter/MailScanner
make sys-devel/make
man sys-apps/man
man-pages sys-apps/man-pages
mc app-misc/mc
mod_perl www-apache/mod_perl
module-init-tools sys-apps/module-init-tools
mono dev-lang/mono
MPlayer media-video/mplayer
mutt mail-client/mutt
mysql dev-db/mysql
nautilus gnome-base/nautilus
ncftp net-ftp/ncftp
ncurses sys-libs/ncurses
ndiswrapper net-wireless/ndiswrapper
nedit app-editors/nedit
netatalk net-fs/netatalk
NetBeans dev-util/netbeans
NetworkManager net-misc/networkmanager

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

2009-09-11 Thread Aaron Bauman
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