[arch-dev-public] Arch project management?
A lot of people have been saying that quality control in Arch has gone down the crapper (gotten worse, for the non-native english speakers). Obviously we can't test everything on everyone's machine or even test all the features of all of our packages, so what can we do? Someone suggested that we have someone who manages quality control. I don't like thinking of it as a procedural problem, so I'm going to phrase it differently. I think we need someone who makes sure that things don't get forgotten, by the developers and by the community. Someone to prod the devs and the community to test things and make sure things don't get lost. Roman already does this very very well for the bug tracker. Since we hired a bug hunter, bugs get addressed^H^H^H^H^H^H^H^H^Hassigned very quickly. What if we had the same thing for the larger/more important packages, like kernel26, glibc, apache, everything in core? The idea isn't to just throw process at the problem, but to be a little more organized in our package verification. I don't care how the organizer does it either, just as long as they make sure that people are happy with changes before they go into current/extra. I'm not suggesting any of the developers do this either, we need someone new who isn't maintaining packages, already busy with Arch developer stuff, and is active in the community. Everyone has 1 week to get their comments in before I start looking. Jason
On 4/17/07, Jason Chu <jason@archlinux.org> wrote:
A lot of people have been saying that quality control in Arch has gone down the crapper (gotten worse, for the non-native english speakers). Obviously we can't test everything on everyone's machine or even test all the features of all of our packages, so what can we do?
Someone suggested that we have someone who manages quality control. I don't like thinking of it as a procedural problem, so I'm going to phrase it differently. I think we need someone who makes sure that things don't get forgotten, by the developers and by the community. Someone to prod the devs and the community to test things and make sure things don't get lost.
Roman already does this very very well for the bug tracker. Since we hired a bug hunter, bugs get addressed^H^H^H^H^H^H^H^H^Hassigned very quickly. What if we had the same thing for the larger/more important packages, like kernel26, glibc, apache, everything in core?
The idea isn't to just throw process at the problem, but to be a little more organized in our package verification. I don't care how the organizer does it either, just as long as they make sure that people are happy with changes before they go into current/extra.
I'm not suggesting any of the developers do this either, we need someone new who isn't maintaining packages, already busy with Arch developer stuff, and is active in the community.
Everyone has 1 week to get their comments in before I start looking.
Jason
This is not quite the same, but quite related- I feel that the testing repo is not used as often as it should be for single-package upgrades. We have been tending to use it for large rebuilds, but you don't see packages hit testing near as often when it is all by itself. I don't like having hard and fast rules on when a move through testing is appropriate. Having bleeding-edge packages is great with this distro, but having broken-edge packages is not so hot. Just my two cents. -Dan
On 4/18/07, Dan McGee <dpmcgee@gmail.com> wrote:
This is not quite the same, but quite related- I feel that the testing repo is not used as often as it should be for single-package upgrades. We have been tending to use it for large rebuilds, but you don't see packages hit testing near as often when it is all by itself. I don't like having hard and fast rules on when a move through testing is appropriate. Having bleeding-edge packages is great with this distro, but having broken-edge packages is not so hot.
This isnt the same either, but it's related closely anyway. There's users who want to test. For many smaller updates, we should seek out a group of users who we can issue the package to, get it tested, then release. Just let them know they can uncomment testing at the *end* of their pacman.conf and pacman -S testing/somepackage (this way they won't get all of testing... which many do not want) If the package has [testing] depends, yeah, that complicates things, but for many bumps, that's not the case. But yeah, corresponding with users, takes time. We *could* automate it easily with some scripts, or as suggested, create a new position for someone to do this for us.... not sure who'd want to do that though. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com
On 4/18/07, James <iphitus@gmail.com> wrote:
On 4/18/07, Dan McGee <dpmcgee@gmail.com> wrote:
This is not quite the same, but quite related- I feel that the testing repo is not used as often as it should be for single-package upgrades. We have been tending to use it for large rebuilds, but you don't see packages hit testing near as often when it is all by itself. I don't like having hard and fast rules on when a move through testing is appropriate. Having bleeding-edge packages is great with this distro, but having broken-edge packages is not so hot.
This isnt the same either, but it's related closely anyway. There's users who want to test. For many smaller updates, we should seek out a group of users who we can issue the package to, get it tested, then release.
Just let them know they can uncomment testing at the *end* of their pacman.conf and pacman -S testing/somepackage (this way they won't get all of testing... which many do not want)
It might actually be useful to create some sort of notification system for our updates in this case. If we were to create a commit mailing list for PKGBUILDs, users would be able to know when things are updated in CVS (or whatever). Alternatively, this could be done with pacbuild's build process, but I think Jason wanted to hold off on pacbuild for a bit...
On Tue, Apr 17, 2007 at 01:52:11PM -0400, Dan McGee wrote:
On 4/17/07, Jason Chu <jason@archlinux.org> wrote:
A lot of people have been saying that quality control in Arch has gone down the crapper (gotten worse, for the non-native english speakers). Obviously we can't test everything on everyone's machine or even test all the features of all of our packages, so what can we do?
Someone suggested that we have someone who manages quality control. I don't like thinking of it as a procedural problem, so I'm going to phrase it differently. I think we need someone who makes sure that things don't get forgotten, by the developers and by the community. Someone to prod the devs and the community to test things and make sure things don't get lost.
Roman already does this very very well for the bug tracker. Since we hired a bug hunter, bugs get addressed^H^H^H^H^H^H^H^H^Hassigned very quickly. What if we had the same thing for the larger/more important packages, like kernel26, glibc, apache, everything in core?
The idea isn't to just throw process at the problem, but to be a little more organized in our package verification. I don't care how the organizer does it either, just as long as they make sure that people are happy with changes before they go into current/extra.
I'm not suggesting any of the developers do this either, we need someone new who isn't maintaining packages, already busy with Arch developer stuff, and is active in the community.
Everyone has 1 week to get their comments in before I start looking.
Jason
This is not quite the same, but quite related- I feel that the testing repo is not used as often as it should be for single-package upgrades. We have been tending to use it for large rebuilds, but you don't see packages hit testing near as often when it is all by itself. I don't like having hard and fast rules on when a move through testing is appropriate. Having bleeding-edge packages is great with this distro, but having broken-edge packages is not so hot.
[testing] also needs more testing from end-users. Python 2.5 was in testing for a long time. But most bug reports appeared after the move to [current]. Every dev. appreciates patches. Jürgen
On 4/18/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
[testing] also needs more testing from end-users. Python 2.5 was in testing for a long time. But most bug reports appeared after the move to [current]. Every dev. appreciates patches.
I think this kinda comes back to the point I made - there's no real way for users to see what goes into, or changes, in testing, as it happens. Sure, we throw news posts up every so often like "blah is in testing", but that's a static report of a dynamic process.
On Wed, Apr 18, 2007 at 11:53:26AM -0500, Aaron Griffin wrote:
On 4/18/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
[testing] also needs more testing from end-users. Python 2.5 was in testing for a long time. But most bug reports appeared after the move to [current]. Every dev. appreciates patches.
I think this kinda comes back to the point I made - there's no real way for users to see what goes into, or changes, in testing, as it happens. Sure, we throw news posts up every so often like "blah is in testing", but that's a static report of a dynamic process.
Ok, so after you guys all hijacked and beat up my thread, let's see if I can summarize: developers don't use testing, users don't use testing, we need someone to get developers to use testing and get users to use testing. Anyone have suggestions for who could fill this position? Jason
participants (5)
-
Aaron Griffin
-
Dan McGee
-
James
-
Jason Chu
-
Jürgen Hötzel