On Mon, Nov 29, 2010 at 09:33:46AM -0800, Adam Williamson wrote:
On Mon, 2010-11-29 at 14:34 +0000, Petr Pisar wrote:
> I do not get the idea why I should filter some irrelevant mails if
> better is to not sent them. Especially if I cannot solve the subject of
> the mail. Yeah, the subject is somobody does not did his job. I cannot
> imagine the knowledge would help me in my packager duties.
Your packager duties include aiding in ensuring testing of your packages
Note that this is not explicit. What is explicit is that maintainers are
"Deal with reported bugs in a timely manner "
I think one source of the feelings on some maintainers' parts is that the new
update criteria get in the way of "timey manner" in the quest to prevent
It is not true that there is nothing you can do. You can
contact proven testers and ask them to test your package, you can
contact people who use your package (I would hope you know some!) and
ask them to become proven testers to ensure that your updates are pushed
in timely fashion in future.
QA is not 'someone else's problem', it's a collaborative effort. Fedora
is a community-based volunteer-driven project; neither Red Hat nor The
Fedora Project has a thousand minimum-wage Fedora test slaves in a room
somewhere ready to do all the testing we could ever desire.
Actually, what you say here is both true and untrue. If you look at Fedora
as a product to be delivered, then QA is a problem for everyone delivering
that product to worry about. However, if you look at Fedora as an open
source project then you'll find that tasks are divided among contributor
interest rather than end-product. It is the problem of the people who care
about QA to worry about QA -- the people who have an itch to scratch have
the responsibility to scratch it for themselves.
These ideas are not diametrically opposed, rather they're two different ways
to look at this problem and try to understand that an ideal solution
encompasses both viewpoints. On the one hand, convincing everyone to care
about QA and make sure that packages they care about are tested to prevent
regressions, and on the other hand, giving maintainers the ability to make
judgements about the risk vs benefit of the update that they want to push
and getting the high benefit packages into users hands asap.