public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Róbert Čerňanský" <hslists2@zoznam.sk>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Low hanging bug fruit patterns
Date: Tue, 09 Mar 2010 19:24:32 +0100	[thread overview]
Message-ID: <20100309192432.75f8b756@amit.kihnet.sk> (raw)
In-Reply-To: <20100309001718.3b2e4c0e@epia.jer-c2.orkz.net>

On Tue, 9 Mar 2010 00:17:18 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Mon, 08 Mar 2010 14:13:30 +0100
> Róbert Čerňanský <hslists2@zoznam.sk> wrote:
> 
> > - Minor version bumps (After examination what upstream changed and
> >   after confirmation with mantainer, if any.)
> 
> The stuff you put in brackets is exactly the sort of stuff that
> tends to make version bumps hard to fix.
> 
> You would first have to determine what major/minor means, on a per
> package-version basis, so these aren't really as trivial to fix as
> (non) package maintainer as a "minor version change" might suggest.

Yes, one needs to be carefull when doing even "minor" version bump. And
after examination of changes one can decide to do the bump or leave it
because it looks too risky. I'm sure there are upstream releases that
contains only bug fixes and it can be relatively easy determined by
looking into NEWS, Changelog or similar files.

After all, the examination should not exceed 1 day of effort (Sebastian
wrote that it should not "take days" to fix). So if we say that 1 day
is still less than "days" then I think it is plenty of time to examine
upstream changes. But maybe 1 day is too much for "low hanging fruits"
so let's say 2 hours is acceptable. In that time it should be possible
to fully examine changes. Which means read the changelogs, do some
internet search (upstream and other distros bugzillas) and even take a
peek to the source code.

> Also, any version bump is a splendid occasion on which to revise the
> ebuild (introduce missing features, check for novel QA issues, move up
> an EAPI to cut out a few build phases, review COPYING to make sure
> the LICENSE variable is still OK, figure out that one slight syntax
> change might serve to fix a compilation error with a
> newer-toolchain-than-you-use).

It still can be done at another time after bump; which is maybe even
better because it could be easily distinguished whether potencial new
bugs were caused by the bump or by ebuild enhancement changes.

Also I think that the overall quality of a package is increased if it
is "just" bumped to the new minor/bugfix upstream release and ebuild
stays at the same quality level as before. Compared to staying at the
older upstream version and also with the same ebuild because nobody has
time to do bump with ebuild enhacement.

> So I generally don't regard a version bump as a low hanging fruit,
> as you might end up painfully ignoring the wasps' nest hanging
> directly beside it.

Cenrtailny not in general. So let's say it is low hanging fruit at
which you have to stare for a while and look at it from all sides
before you pick it up. ;-)

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: hs@jabber.sk



  reply	other threads:[~2010-03-09 18:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-08 10:06 [gentoo-dev] Low hanging bug fruit patterns Sebastian Pipping
2010-03-08 13:13 ` Róbert Čerňanský
2010-03-08 17:37   ` Sebastian Pipping
2010-03-08 23:17   ` Jeroen Roovers
2010-03-09 18:24     ` Róbert Čerňanský [this message]
2010-03-09 23:17     ` [gentoo-dev] " Duncan
2010-03-08 13:27 ` [gentoo-dev] " Markos Chandras
2010-03-08 17:33   ` Sebastian Pipping
2010-03-08 14:42 ` Angelo Arrifano
2010-03-08 17:08 ` Mark Loeser
2010-03-08 17:31   ` Sebastian Pipping
2010-03-08 18:00 ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100309192432.75f8b756@amit.kihnet.sk \
    --to=hslists2@zoznam.sk \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox