[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Who should be in the QA Group Committee



Raphael Hertzog wrote:
> Le Mon, Sep 20, 1999 at 03:41:57PM +0200, Martin Schulze écrivait:
> 
> [Joey I'm still getting the mail 3 times, maybe you're not yet on
>  the moderators list ... ]

Hmm, wonderful.  I am in the moderators file, and apparently no
mail got distributed through the list yet.  I haven't found something
wrong or broken, Rince will check now. [30min later] I've checked
and corrected it as well.

Hmm, he told me that there has to be an Approved: header.

Will add it automagically.
[30min later]
This is done now, tested on another list so should work.

> > Both lists could be similar, but both lists don't contain the same
> > information.
> 
> Well most of the QA task are more or less package related. Of course,

As a result, yes.  As the source, no.

> > I disagree.  If there is too much to do, then we need more people.
> 
> Well, I can only agree with you but tell me how you will get more 
> people ? Do you have money to pay them ? :) We are only volunteers.

I don't know how to aquire new people.  However, I know that it won't
work without a proper framework.  This is what you're doing and I'm
really happy that you have stepped forward to create this framework,
even if I disagree in certain details.

> > Ignoring our problems is the current way Debian tries to work but it
> > does not work.  That's a mistake.  Please don't continue with it.
> 
> Keeping the task list not too big is NOT ignoring our problem. In fact,
> we can list all our problems on a separate page if you want.

That doesn't make sense, I'm sorry, thus I strongly disagree.

> > I don't think that an area with Packages files would be required.  I
> > would just open http://qa.debian.org/packages/ and a directory for
> > each package where the files will be put in, completely with .changes
> > files etc.  The links would be added to the BTS then.  Thus if the
> > maintainer doesn't react, the whole dir would be copied into the
> > proper incoming directory and removed there.  Also people could
> > download and test packages.
> 
> Ok I guess, this would be only only a big Incoming directory ...

Yes.

> then we can had this information to dupload so that we can just do
> dupload --to qa <package>.changes

Hmm, no.  Only proper people (i.e. qa core team members) should be able
to upload there, according to your policy, or better, furthering the
policy.

> > No, you don't.  You said, however, that the list must not grow too much
> > and that's where I disagree.  If there are problems and tasks, they have
> > to be addressed, regardless of how many other tasks are there.
> 
> Yes, but adding them to the list doesn't mean that they will be adressed.

That may be true, or may not.

> Since we don't agree I think that I will have to write yet another web
> page that will only list the 50 first tasks to do. Would this be
> acceptable for you ?

Args.  As long as you will present all tasks as well, that's sufficient.
You have introduced priorities, so use them to select tasks for the
first page.  I guess that I won't complain about that then.

> This way you can fill up the task list but most of the people will never
> look at it and just concentrate on the first tasks to do ... for me the
> most important thing is what is really done (and not only what has 
> to be done). :-)

And this is wrong.  This has lead us to where we are now.  Some pkg's
are maintained (this is done) boot-floppies are not done.  Thus we
cannot install pure potato.

> BTW, I intend to add yet another page for "tasks beeing worked on".

*This* sounds far better than restricting the listing to 50 most
important ones.  Please do it so.

Regards,

	Joey

-- 
This is Linux Country.  On a quiet night, you can hear Windows reboot.


Reply to: