[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-11-01 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-11-01 23h59 UTC. Removals: x11-base/x11-drm2009-10-26 16:48:52 battousai net-wireless/kdebluetooth 2009-10-26 20:28:20 ssuominen dev-python/rhpxl2009-10-26 21:31:53 remi dev-python/pyxf86config 2009-10-26 21:33:14 remi net-p2p/nicotine2009-10-28 05:43:14 dirtyepic net-wireless/bluez-hciemu 2009-10-30 16:43:23 nirbheek media-libs/glut 2009-10-30 23:40:57 scarabeus media-libs/vgui 2009-10-30 23:40:58 scarabeus app-accessibility/SphinxTrain 2009-11-01 18:13:52 eva app-accessibility/accerciser2009-11-01 18:13:53 eva app-accessibility/at-poke 2009-11-01 18:13:53 eva app-accessibility/brltty2009-11-01 18:13:54 eva app-accessibility/dasher2009-11-01 18:13:55 eva app-accessibility/eflite2009-11-01 18:13:56 eva app-accessibility/emacspeak 2009-11-01 18:13:57 eva app-accessibility/emacspeak-ss 2009-11-01 18:13:58 eva app-accessibility/epos 2009-11-01 18:13:59 eva app-accessibility/espeak2009-11-01 18:14:00 eva app-accessibility/espeakup 2009-11-01 18:14:00 eva app-accessibility/festival 2009-11-01 18:14:01 eva app-accessibility/festival-fi 2009-11-01 18:14:02 eva app-accessibility/festival-freebsoft-utils 2009-11-01 18:14:04 eva dev-db/xindice 2009-11-01 19:40:01 caster dev-java/tagunit2009-11-01 19:42:55 caster dev-java/xmojo-bin 2009-11-01 19:54:46 caster dev-java/crimson2009-11-01 19:57:42 caster dev-java/axion 2009-11-01 20:00:00 caster Additions: dev-util/mutrace2009-10-26 18:21:11 ford_prefect dev-haskell/utf8-string 2009-10-27 06:46:30 kolmodin x11-plugins/desklet-Mouse 2009-10-27 11:24:17 nixphoeni x11-plugins/desklet-Genesis 2009-10-27 11:26:08 nixphoeni dev-ml/fieldslib2009-10-27 12:08:13 aballier net-libs/netembryo 2009-10-27 12:11:03 ssuominen dev-ml/core 2009-10-27 12:36:35 aballier net-libs/libnemesi 2009-10-27 12:45:51 ssuominen app-admin/fsvs 2009-10-27 19:04:52 dertobi123 kde-misc/kosd 2009-10-27 23:40:39 ssuominen kde-misc/synaptiks 2009-10-28 09:05:22 ssuominen kde-misc/fancytasks 2009-10-28 12:48:54 ssuominen sci-biology/ucsc-genome-browser 2009-10-28 20:47:27 weaver kde-misc/kim4 2009-10-28 21:02:31 ssuominen kde-misc/systemloadviewer 2009-10-29 08:21:41 ssuominen app-emulation/open-vm-tools-kmod2009-10-29 14:02:43 vadimk dev-libs/libindicate2009-10-29 15:47:05 mrpouet sys-apps/gnome-disk-utility 2009-10-29 21:50:37 eva dev-libs/libgdata 2009-10-29 22:38:39 eva dev-cpp/mm-common 2009-10-29 22:57:21 eva dev-python/brasero-python 2009-10-29 23:09:25 eva sys-auth/polkit 2009-10-29 23:28:01 eva gnome-extra/polkit-gnome2009-10-29 23:35:10 eva sys-apps/devicekit-disks2009-10-29 23:43:29 eva dev-libs/libatasmart2009-10-29 23:50:37 eva dev-libs/libindicate-qt 2009-10-30 00:06:11 scarabeus media-video/miro2009-10-30 08:29:50 volkmar media-libs/libmpdclient 2009-10-30 17:34:03 angelos app-vim/snipmate2009-10-30 17:37:00 spatz media-plugins/gst-plugins-gl2009-10-30 18:49:53 ssuominen dev-util/perf 2009-10-30 19:30:24 flameeyes dev-java/jsr305 2009-10-31 02:11:19 nerdboy kde-misc/qalculate-applet 2009-10-31 12:34:38 ssuominen kde-misc/kcm_touchpad 2009-10-31 13:46:02 ssuominen
[gentoo-dev] Lastrite: app-misc/tracker-0.6* support
01 Nov 2009; Gilles Dartiguelongue package.mask: Mask app-misc/tracker, bug #291501. 01 Nov 2009; Gilles Dartiguelongue package.use.mask: Mask tracker USE flag in apps using it, bug #291501. Tracker-0.7 will soon take over (gnome-2.28 mostly has it already). -- Gilles Dartiguelongue Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Re: [RFC] Improve policy of stabilizations
On Sun, 1 Nov 2009 17:36:30 +0100 Arfrever Frehtes Taifersar Arahesis wrote: > Some packages have new releases more than once a month and sometimes it's > reasonable > to not skip stabilization of any version. Given version of a package is > usually no > longer tested by users after release of a newer version, so I suggest the > following > change to the policy of stabilizations: > Stabilization of given version of a package can be requested if this version > has been > in the tree for at least 10 days and a newer version of this package has been > added > to the tree. I thought the arch teams were already overworked. Why do you need every last version stable? -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Improve policy of stabilizations
Richard Freeman wrote: > Mart Raudsepp wrote: >> >> Is it stated in any documentation that 30 days is a policy? >> > > Not that I'm aware of - it is a guideline as you indicate. However, > don't expect anybody to actually take action on a STABLEREQ if there > isn't some kind of rationale for going stable so quickly. > Yes it's a guideline that you should follow unless you can give reasons to deviate. > > The whole point of stable is that they provide some sanity to the > release process - if upstream releases a new version every other week > then perhaps we should either: > > 1. Question whether it should go stable at all. > 2. Pick a version once in a while and target it for stabilization, > backporting fixes as needed. > Yeah one can question if adding every release is really important for users. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Improve policy of stabilizations
Mart Raudsepp wrote: Is it stated in any documentation that 30 days is a policy? Not that I'm aware of - it is a guideline as you indicate. However, don't expect anybody to actually take action on a STABLEREQ if there isn't some kind of rationale for going stable so quickly. The whole point of stable is that they provide some sanity to the release process - if upstream releases a new version every other week then perhaps we should either: 1. Question whether it should go stable at all. 2. Pick a version once in a while and target it for stabilization, backporting fixes as needed. We don't need to be Debian stable, but if the only reason for stabilizing a package is that upstream has already moved on, then I think we're making a mistake. In fact, if upstream abandoned a release after only two weeks that would be a good reason NOT to stabilize it. End users can always run ~arch if they need to - at least this way they know in advance what they're getting into.
[gentoo-dev] Lastrite: gnome-extra/gnome-keyring-manager
# Gilles Dartiguelongue (01 Nov 2009) # Old gnome component superseeded by seahorse. # See bug #291456 for details. gnome-extra/gnome-keyring-manager -- Gilles Dartiguelongue Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] [RFC] Improve policy of stabilizations
On Sun, 2009-11-01 at 17:36 +0100, Arfrever Frehtes Taifersar Arahesis wrote: > Some packages have new releases more than once a month and sometimes it's > reasonable > to not skip stabilization of any version. Given version of a package is > usually no > longer tested by users after release of a newer version, so I suggest the > following > change to the policy of stabilizations: > Stabilization of given version of a package can be requested if this version > has been > in the tree for at least 10 days and a newer version of this package has been > added > to the tree. I am not aware of there being a 30 day policy, and have always considered it as a guideline, not policy. If the maintainer sees that 10 days is good for the package sometimes, I see no problem with it. Arch teams might kindly request explanations of why the quicker stabilization, but I don't represent any myself, but in case of quicker stabilization of package I maintain myself I try to state in the STABLEREQ bug why the quicker stabilization. Is it stated in any documentation that 30 days is a policy? -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] [RFC] Improve policy of stabilizations
Some packages have new releases more than once a month and sometimes it's reasonable to not skip stabilization of any version. Given version of a package is usually no longer tested by users after release of a newer version, so I suggest the following change to the policy of stabilizations: Stabilization of given version of a package can be requested if this version has been in the tree for at least 10 days and a newer version of this package has been added to the tree. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
