Re: [gentoo-dev] QA is unimportant? (was: gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild)

[Peter Volkov <pva@gentoo.org>]

В Пнд, 09/11/2009 в 01:37 +0100, Vlastimil Babka пишет:
> I totally agree. And I must say it started with the very first mail of 
> pva. Accusing of not knowing quizzes was totally uncalled for.

If you know how to do thing properly what are the reasons avoid doing
that? All I heard here is laziness and I don't think this is acceptable.

> As patrick said, the SRC_URI thing was simply forgot to be polished after 
> testing, and the dobin thing he didn't even touch. Who remembers what 
> everything should have || die or not from the top of his head and spots 
> it immediatelly?

Quizzes are the basic knowledge required to work with tree. Do you state
that it's impossible to remember answers on quizzes? Should we drop
quizzes then and let people do whatever they want with the tree? Please,
stop this nonsense advocation.


> And this offensive tone just provoked adequate reaction

Offence was not my intention. I apologize for tone.


That said, Patrick insist on mistakes he is well aware about, e.g. take
a look at this ebuild:

http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/snort/snort-2.8.4.1.ebuild?hideattic=0&rev=1.1&view=markup

This is user submitted ebuild, without any modifications and with number
of QA problems that Patrick commited. I've tried to contact Patrick and
Jason (user who did and does snort job) and while Jason fixed everything
in next version Patrick avoided to fix even crying things (e.g. missed
|| die after emake) in the tree for ebuild that was fast stabilized. No
offense, but again I have to admit that Patrick forgot an answers on
ebuild-quiz questions 3 (b) and 4. And worst thing is that he is not
going to fix things he commited to the tree... I hope this explains my
tone, but again I apologize for it.


> and here we are, useless flame.

This thread is not "useless flame". It revealed at least two concerns:

1. Our good non-formal policy "if developer touched anything he becames
responsible for that ebuild and should fix issues noticed" is sometimes
ignored. We see people reacting: you've noticed - you fix. I think such
attitude is unacceptable.

Telling somebody that crap was in the previous version of ebuild so I'm
not gonna fix it does not make any sense. Things change and developers
are supposed to follow changes. This means that since new coding
standards were introduced new ebuilds follow them. Even users on Sunrise
managed to learn this easy || die thing and I really hope that
developers who passed quizzes are capable too. I don't even see how ||
die is "cosmetics" - it is either redudand (in case of econf) or missed
code (in case of make). The first one just introduces more crap around
the latter could make ebuild miss build failure.

2. Some developers prefer to do "blind" bumps (just rename .ebuild and
check if it builds). This kind of things are possible in case package is
used on daily basis and package development was followed. In all other
cases if developer touchs new package he is supposed to check it as a
"new package", from the very beginning. In case version bump done
properly the things I'm asking about will take less then 1% of
developer's time: with bump developer is supposed to review
modifications of build system, check if seds/patches inside package are
still required and check that there are no new deps. At the same time
it's really easy remove redudant || die or drop default src_compile
{ emake || die ; } functions. I'm really surprised to see that people
insist that such ebuilds are better then unmaintained: it's really hard
to call such "blind" bump as package maintainance but this bump hides
unmaintained packages in the tree. Yes, this makes things worse.


Well, it looks like the root of this problem is the following statement:
"QA is less important then new packages in the tree". I failed to hear
any arguments why QA is unimportant so I still believe that QA problem
is a problem.

-- 
Peter.