Gentoo Archives: gentoo-dev

From: "Róbert Čerňanský" <hslists2@××××××.sk>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Low hanging bug fruit patterns
Date: Tue, 09 Mar 2010 18:25:03
Message-Id: 20100309192432.75f8b756@amit.kihnet.sk
In Reply to: Re: [gentoo-dev] Low hanging bug fruit patterns by Jeroen Roovers
1 On Tue, 9 Mar 2010 00:17:18 +0100
2 Jeroen Roovers <jer@g.o> wrote:
3
4 > On Mon, 08 Mar 2010 14:13:30 +0100
5 > Róbert Èeròanský <hslists2@××××××.sk> wrote:
6 >
7 > > - Minor version bumps (After examination what upstream changed and
8 > > after confirmation with mantainer, if any.)
9 >
10 > The stuff you put in brackets is exactly the sort of stuff that
11 > tends to make version bumps hard to fix.
12 >
13 > You would first have to determine what major/minor means, on a per
14 > package-version basis, so these aren't really as trivial to fix as
15 > (non) package maintainer as a "minor version change" might suggest.
16
17 Yes, one needs to be carefull when doing even "minor" version bump. And
18 after examination of changes one can decide to do the bump or leave it
19 because it looks too risky. I'm sure there are upstream releases that
20 contains only bug fixes and it can be relatively easy determined by
21 looking into NEWS, Changelog or similar files.
22
23 After all, the examination should not exceed 1 day of effort (Sebastian
24 wrote that it should not "take days" to fix). So if we say that 1 day
25 is still less than "days" then I think it is plenty of time to examine
26 upstream changes. But maybe 1 day is too much for "low hanging fruits"
27 so let's say 2 hours is acceptable. In that time it should be possible
28 to fully examine changes. Which means read the changelogs, do some
29 internet search (upstream and other distros bugzillas) and even take a
30 peek to the source code.
31
32 > Also, any version bump is a splendid occasion on which to revise the
33 > ebuild (introduce missing features, check for novel QA issues, move up
34 > an EAPI to cut out a few build phases, review COPYING to make sure
35 > the LICENSE variable is still OK, figure out that one slight syntax
36 > change might serve to fix a compilation error with a
37 > newer-toolchain-than-you-use).
38
39 It still can be done at another time after bump; which is maybe even
40 better because it could be easily distinguished whether potencial new
41 bugs were caused by the bump or by ebuild enhancement changes.
42
43 Also I think that the overall quality of a package is increased if it
44 is "just" bumped to the new minor/bugfix upstream release and ebuild
45 stays at the same quality level as before. Compared to staying at the
46 older upstream version and also with the same ebuild because nobody has
47 time to do bump with ebuild enhacement.
48
49 > So I generally don't regard a version bump as a low hanging fruit,
50 > as you might end up painfully ignoring the wasps' nest hanging
51 > directly beside it.
52
53 Cenrtailny not in general. So let's say it is low hanging fruit at
54 which you have to stare for a while and look at it from all sides
55 before you pick it up. ;-)
56
57 Robert
58
59
60 --
61 Robert Cernansky
62 E-mail: hslists2@××××××.sk
63 Jabber: hs@××××××.sk