[arch-dev-public] Arch project management?
juergen at hoetzel.info
Wed Apr 18 12:47:59 EDT 2007
On Tue, Apr 17, 2007 at 01:52:11PM -0400, Dan McGee wrote:
> On 4/17/07, Jason Chu <jason at 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.
More information about the arch-dev-public