Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
Date: Sun, 18 Jan 2015 04:34:27
Message-Id: 54BB37C4.9020607@gentoo.org
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog by Patrick Lauer
1 Patrick Lauer:
2 > On Saturday 17 January 2015 17:25:15 hasufell wrote:
3 >> Patrick Lauer:
4 >>> On Friday 16 January 2015 18:29:08 hasufell wrote:
5 >>>> Patrick Lauer:
6 >>>>> On 01/16/15 23:26, hasufell wrote:
7 >>>>>> Patrick Lauer (patrick):
8 >>>>>>> patrick 15/01/16 04:16:55
9 >>>>>>>
10 >>>>>>> Modified: ChangeLog
11 >>>>>>> Added: libuv-1.2.1.ebuild
12 >>>>>>> Log:
13 >>>>>>> Bump
14 >>>>>>
15 >>>>>> I expect people to ask me for review if they bump any of my packages.
16 >>>>>> That includes QA team members.
17 >>>>>
18 >>>>> Are you always in such a bad mood?
19 >>>>
20 >>>> Do you, as QA team member, think that a review workflow improves quality?
21 >>>
22 >>> No.
23 >>>
24 >>> Bureaucracy does not improve quality by itself.
25 >>
26 >> Patrick, I am really sorry, but this answer made me laugh and cry.
27 >>
28 >> A review workflow is a fundamental concept in programming methodology
29 >> and we have decades of experience that taught us how important it is.
30 >
31 > But just "add review" or "add agile" doesn't fix quality. Same way Security is
32 > not just a checkbox, but a process. (Plus there's the whole manpower thing
33 > we'll ignore for now, etc. etc. ...)
34 >
35
36 Yes exactly. A review is not a checkbox, but a process (in contrary to
37 running repoman). It's the process of asking someone for comments on
38 your patch, getting useful answers and then going ahead with a commit maybe.
39
40 You didn't follow that process. That in conjunction with your weird
41 answer makes me think that you really don't like getting reviews. Your
42 attempts to relativize the review workflow defined in devmanual (which
43 is still a bit lax, tbh) is confusing at best.
44
45 So unless you can tell me how your flawed commit (the sed call was
46 silently broken) did improve the quality of my ebuild, I am still
47 insisting on a review workflow.