I'm wondering whether it is a bug that [1] and [2] don't claim to have maintainers, but they actually do.
If the web interface doesn't know of a maintainer, can it still send the maintainer an email that it is outdated (which is the case for [2]), of which a build for a newer version can be found at [3]
[1] http://www.archlinux.org/packages/testing/i686/glib2/ [2] http://www.archlinux.org/packages/testing/i686/bitlbee/
[3] http://github.com/Pnevma/config/tree/master/Builds/bitlbee
On Mon, 2008-08-11 at 04:42 -0400, Adam Vogt wrote:
I'm wondering whether it is a bug that [1] and [2] don't claim to have maintainers, but they actually do.
If the web interface doesn't know of a maintainer, can it still send the maintainer an email that it is outdated (which is the case for [2]), of which a build for a newer version can be found at [3]
[1] http://www.archlinux.org/packages/testing/i686/glib2/ [2] http://www.archlinux.org/packages/testing/i686/bitlbee/
[3] http://github.com/Pnevma/config/tree/master/Builds/bitlbee
Our web frontend works with 2 things when it comes to assigning maintainers: - the repository it is in - the architecture of the package
So when I package glib2, I add two packages, one for i686 and one for x86_64. Because of our signoff policy, I will have to do updates to testing, creating another set of packages. The testing packages are created and deleted everytime they're moved to the core or extra repository. It makes no sense to adopt these packages everytime. If you flag a testing package, nobody gets notified. Flag the extra/core package instead.
* On Monday, August 11 2008, Jan de Groot wrote:
Our web frontend works with 2 things when it comes to assigning maintainers:
- the repository it is in
- the architecture of the package
So when I package glib2, I add two packages, one for i686 and one for x86_64. Because of our signoff policy, I will have to do updates to testing, creating another set of packages. The testing packages are created and deleted everytime they're moved to the core or extra repository. It makes no sense to adopt these packages everytime. If you flag a testing package, nobody gets notified. Flag the extra/core package instead.
Thanks for clearing that up.
In the case of bitlbee, the package in [extra] appears orphaned. If that's not the case, wouldn't it be better if the web interface determined maintainership from the pkgbuild itself?
On Mon, Aug 11, 2008 at 3:34 PM, Adam Vogt vogt.adam@gmail.com wrote:
- On Monday, August 11 2008, Jan de Groot wrote:
Our web frontend works with 2 things when it comes to assigning maintainers:
- the repository it is in
- the architecture of the package
So when I package glib2, I add two packages, one for i686 and one for x86_64. Because of our signoff policy, I will have to do updates to testing, creating another set of packages. The testing packages are created and deleted everytime they're moved to the core or extra repository. It makes no sense to adopt these packages everytime. If you flag a testing package, nobody gets notified. Flag the extra/core package instead.
Thanks for clearing that up.
In the case of bitlbee, the package in [extra] appears orphaned. If that's not the case, wouldn't it be better if the web interface determined maintainership from the pkgbuild itself?
Simo was the last owner of that package, but he has since orphaned it on purpose. There is currently no maintainer.
arch-general@lists.archlinux.org