Re: [gentoo-dev] 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
Re: [gentoo-dev] QA is unimportant? (was: gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild)
В Пнд, 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=0rev=1.1view=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.
Re: [gentoo-dev] QA is unimportant? (was: gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild)
If you have concerns, try a friendly approach and ask Patrick to fix them. I'm quite convinced he would be happy to do so. Your offensive approach achieves the opposite. That isn't in the interest of QA either. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] QA is unimportant?
Peter Volkov wrote: 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. Keep in mind the downside to such a policy is that people just ignore problems that are trivial to fix, because they don't have the time to go over the ebuild with a fine-toothed comb. Then, if people get their heads chewed off on -dev if they do miss something that lowers the motivation just a bit more. Sure, if a dev fixes an ebuild they should give it a once-over to make sure there are no major problems, and obviously they should do moderate testing to make sure it builds and works. However, if I spotted a minor problem with an ebuild that I could fix, and a major problem that I couldn't fix, chances are that I wouldn't touch it at all. Then the ebuild stays in the tree with both problems, instead of one fewer. I think it all boils down to we're all in this together. If you see a problem try to fix it, and if you see somebody make a mistake try to help them out.While we do need policies, and policies do imply police, nobody likes the police, so let's try to make that work with the minimum in fuss. A good rule of thumb is whether a dev has left a situation better off or worse off than when they touched something, and in this case I'd have to say that we're better off. While the good can be the enemy of the best, sometimes the best can be the enemy of the good, and I think that sums up the current situation well.
Re: [gentoo-dev] QA is unimportant?
On Monday 09 November 2009 13:08:52 Peter Volkov wrote: [Snip] 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. Ok, here's the real problem; Unmaintained stuff is unmaintained 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. You should understand one thing: I don't care at all about most packages. I'm handling virtualbox because right now jokey doesn't seem to have the time. I fixed Xen bugs because drobbins pointed out that there were a few bugs with it, and the current maintainers seem to have gone for a long walk in the park. Can't blame anyone there (I've disappeared for some time too), but those packages would be in a really useless state now. And if I break something for a day or two, well, that's ~arch for you. I try to avoid breaking things, but if things break in ~arch the users shouldn't be too surprised. Otherwise we wouldn't even have to care about having the arch/~arch split. Better a slightly buggy version than a security-exploitable version. Especially when the bug gets fixed the next day. 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 :) (Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let users discover them. I love that QA!) I'm trying to get people to help me, but it's a slow tedious process to even motivate most. And then our recruiting puts up a virtual wall many don't want to climb over. At times it's tiring, it's demotivating, and still we go on. Because we still believe that we can improve things. And as they say, you can't make an omlette without breaking some eggs. Take care, Patrick
Re: [gentoo-dev] 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
Re: [gentoo-dev] 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
Re: [gentoo-dev] 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
Re: [gentoo-dev] 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! :)
Re: [gentoo-dev] QA is unimportant?
Richard Freeman ri...@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. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
