QA is unimportant?
 

On Monday 09 November 2009 11:30:27 Patrick Lauer wrote:
> And instead of being happy that people like ssuominen just fix things where
> other people don't (be it because these other people have no interest, only
> care about a few packages or have become distracted with life) some people
> get really confused and start working on demotivating us.

oh muffin ! get over it already. either do it right or stop doing it.

> You should understand one thing: I don't care at all about most packages.

then let them die.

> I'm handling virtualbox because right now jokey doesn't seem to have the
> time.

jokey hasnt been doing virtualbox in a long time either. it's been proxy
maintained. i know because i was fixing things for a while too.

> So find me a dozen recruits that can properly maintain things and I won't
> feel the need to touch random packages. Stop living in your sandbox and
> have a look at the bigger picture :)

we are looking at the bigger picture. everything in the tree is an example
for people. if you throw crap in, people think crap is acceptable and will
base their work on it.

> (Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let users
> discover them. I love that QA!)

hmm, let's see, one package that was already broken under other C libraries
broke under glibc-2.11. and it's already been fixed. of course, if you'd
simply used bugzilla's search function, you wouldnt have to rhetorically
wonder aloud.
-mike

QA is unimportant?
 

I believe QA is important from the perspective that you want to assure that the ebuilds work. *Nothing makes a casual user more annoyed that having an emerge for his machine fail to work. *But if you are running the emerges unconstrained (e.g. you specify them in the keywords file) then you are "exposed".

A recent example is the mythtv package. *It does not compile on an x86 without significant intervention (Gentoo Bug #292421). *How does it make it into the "release" category without it compiling on the most common machines? *(I'm dealing with an older x86 Pentium IV Prescott machine from HP and there have to be millions of them out there in the world.).

There should be some sort of QA procedure which says "the package builds on these minimal list of machines" before it should be released.
Then there is a separate discussion about how to best migrate people from the "approved" packages to the cutting edge packages with some level of warning to the user ("this may be problematic")

Robert

QA is unimportant?
 

On Monday 09 November 2009 17:30:27 Patrick Lauer wrote:
>
> "Unmaintained stuff is unmaintained"
>

If i can recall my recruitment process, i remember one sentence which was like
"if you touch any package, you are responsible for it".

Please don't hide behind your great job that you are doing here (we all
appreciate it) and admit you are wrong. QA (not the QA team itself, but
policies we have here) is important and talking "excuse me my mistakes because
i do things others do not" doesn't really matter.

--
Cheers
Dawid Węgliński

QA is unimportant?
 

On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:

> oh muffin ! get over it already. either do it right or stop doing it.

perl?

That's how you want to handle things? Great.
I think we can agree that that strategy doesn't work.

> > You should understand one thing: I don't care at all about most packages.
> then let them die.
Not an option. I refuse to sabotage the best distro in the world.

> > (Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let users
> > discover them. I love that QA!)
>
> hmm, let's see, one package that was already broken under other C libraries
> broke under glibc-2.11. and it's already been fixed. of course, if you'd
> simply used bugzilla's search function, you wouldnt have to rhetorically
> wonder aloud.
So you actually built all packages against it? Awesome. I thought flameeyes
and the sabayon people were the only one doing that at the moment.

And talking about glibc ...

For 2.11 you didn't even test if all patches apply (bug #292139)
and maybe forgot to upload a patch (#292223)

Plus a few bugs (hello simple bugzilla search function!) that I can't comment
on yet as they might be user error.
So please, do not try to talk to me about QA when you can't even handle simple
things without error yourself. Especially on critical system packages.

Let's just agree that things aren't perfect and when we discuss this topic
next time - maybe in a year - we want things to be better.

Bye,

Patrick

QA is unimportant?
 

Mike Frysinger wrote:
> hmm, let's see, one package that was already broken under other C libraries
> broke under glibc-2.11. and it's already been fixed. of course, if you'd
> simply used bugzilla's search function, you wouldnt have to rhetorically
> wonder aloud.
> -mike

and I was all excited about new toolchain porting tracker, which never
came... the one bug (kdelibs) was all I had to fix... boo!

more rice!

:)

QA is unimportant?
 

On Monday 09 November 2009 17:52:23 Patrick Lauer wrote:
> On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:
> > oh muffin ! get over it already. either do it right or stop doing it.
>
> perl?

you [thankfully] arent handling perl, so i dont see how that package is
relevant.

> > > You should understand one thing: I don't care at all about most
> > > packages.
> >
> > then let them die.
>
> Not an option. I refuse to sabotage the best distro in the world.

apparently you're incapable of realizing that you already are.

> > > (Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let
> > > users discover them. I love that QA!)
> >
> > hmm, let's see, one package that was already broken under other C
> > libraries broke under glibc-2.11. and it's already been fixed. of
> > course, if you'd simply used bugzilla's search function, you wouldnt have
> > to rhetorically wonder aloud.
>
> So you actually built all packages against it? Awesome. I thought flameeyes
> and the sabayon people were the only one doing that at the moment.
>
> And talking about glibc ...
>
> For 2.11 you didn't even test if all patches apply (bug #292139)

this example is bs and you know it. i'm not going to test every USE flag
combo, especially ones that take specific profiles. ignoring that, this is
for configurations that another team handles. i'm not maintaining the
hardening patches.

> and maybe forgot to upload a patch (#292223)

yes, i roll so many patch tarballs that i sometimes forget to post some. and
it's not an obvious scenario to me since it emerges fine on my system.

> Plus a few bugs (hello simple bugzilla search function!) that I can't
> comment on yet as they might be user error.
> So please, do not try to talk to me about QA when you can't even handle
> simple things without error yourself. Especially on critical system
> packages.

this is sort of argument is also complete bs. other people causing bugs is
absolutely no excuse to knowingly introduce bugs of your own. unlike yours,
mine werent done on purpose.

> Let's just agree that things aren't perfect and when we discuss this topic
> next time - maybe in a year - we want things to be better.

no. you've been told by multiple developers, including the QA team, to stop
knowingly introduce crap into the tree. if you dont fix your development
processes, the next step is to punt you yet again from the pool.
-mike

QA is unimportant?
 

Richard Freeman <rich0@gentoo.org> said:
[good stuff]

i share this sentiment. lets stay an open community and encourage
learning.

if somebody improves a package then that is a good thing. even if it could
be improved even more.

QA is unimportant?
 

On Monday 09 November 2009 18:45:46 Mike Frysinger wrote:
> On Monday 09 November 2009 17:52:23 Patrick Lauer wrote:
> > On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:
> > And talking about glibc ...
> >
> > For 2.11 you didn't even test if all patches apply (bug #292139)
>
> this example is bs and you know it. i'm not going to test every USE flag
> combo, especially ones that take specific profiles. ignoring that, this is
> for configurations that another team handles. i'm not maintaining the
> hardening patches.
>
> > and maybe forgot to upload a patch (#292223)
>
> yes, i roll so many patch tarballs that i sometimes forget to post some.
> and it's not an obvious scenario to me since it emerges fine on my system.

also, unlike you, i acked/fixed the bugs right away instead of whining on a
mailing list over and over that people are making you fix bugs you introduced
-mike

QA is unimportant?
 

Le 09/11/2009 17:30, Patrick Lauer a écrit :

Ok, here's the real problem;

"Unmaintained stuff is unmaintained"


Patrick,

Just piping in to say that dropping a package from portage isn't the end
of the world, we have a very good process for it and it has proven to be
very effective.


Dead packages should be masked :

1) it tells users that no-one among us devs really care about the
package. And it's good because we're not lying or pretending to care. I
think it's honest of us to admit that some packages are abandoned. Users
deserve to know.


2) it sends a crystal-clear message that this package is up for grabs,
either by another dev or by a user with a proxy-maintainer. This is yet
another good thing because it might encourage users to join our ranks.


3) it allows to effectively clear out cruft, and $deity knows portage is
full of it. Faster sync times, fewer security risks, etc.


So while of course we're not going to p.mask perl because its sole
maintainer has decided to stop working on it, but for _less_ _important_
packages, masking and treecleaning is a *good* thing.


And besides, the beauty of CVS is that deleted files are never really
gone, so a deleted package can be brought back from the dead in a few
minutes.


So really, don't feel obliged to touch/bump/fix all unmaintained
packages, fix those that you use and treeclean the rest. It'll be for
the best.


Cheers,

Rémi