Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-09 Thread Róbert Čerňanský
On Tue, 9 Mar 2010 00:17:18 +0100
Jeroen Roovers j...@gentoo.org wrote:

 On Mon, 08 Mar 2010 14:13:30 +0100
 Róbert Čerňanský hslis...@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: hslis...@zoznam.sk
Jabber: h...@jabber.sk



Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Róbert Čerňanský
On Mon, 08 Mar 2010 11:06:40 +0100
Sebastian Pipping sp...@gentoo.org wrote:

 There are a few patterns for potentially low hanging fruits among
 Gentoo bugs:
 
   SRC_URI errors
   Missing depencies

(Sorry for answering a developer targeted question while I'm not one.)

- Minor version bumps (After examination what upstream changed and
  after confirmation with mantainer, if any.)

And perhaps also:
- Stable requests
- New ebuilds


Robert

-- 
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@jabber.sk



Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Markos Chandras
On Monday 08 March 2010 12:06:40 Sebastian Pipping wrote:
 Hello!
 
 
 There are a few patterns for potentially low hanging fruits among Gentoo
 bugs:
 
   SRC_URI errors
   Missing depencies
   ...
 
 What else?
 
 Anything you look after repeatedly that doesn't take days to get it
 fixed?
 
 
 
 Sebastian
Documentation installation
There are few packages that call missing  documents on dodoc commands
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org



Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Angelo Arrifano
On Seg, 2010-03-08 at 11:06 +0100, Sebastian Pipping wrote:
 Hello!
 
 
 There are a few patterns for potentially low hanging fruits among Gentoo
 bugs:
 
   SRC_URI errors
   Missing depencies
   ...
 
 What else?
 
 Anything you look after repeatedly that doesn't take days to get it fixed?
 
 
 
 Sebastian
 

* Missing/crappy ebuild USE flag description on metadata.

That is something, I think, that always help users. There is nothing
worse than rebuilding a entire package just because the USE flag purpose
was not what we think it was.

Regards,
-- 
Angelo Arrifano AKA MiKNiX
Gentoo Embedded/OMAP850 Developer
Linwizard Developer
http://www.gentoo.org/~miknix
http://miknix.homelinux.com





Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Mark Loeser
Sebastian Pipping sp...@gentoo.org said:
 Hello!
 
 
 There are a few patterns for potentially low hanging fruits among Gentoo
 bugs:
 
   SRC_URI errors
   Missing depencies
   ...
 
 What else?
 
 Anything you look after repeatedly that doesn't take days to get it fixed?

What is this even in reference to?  Its not at all clear what you are
trying to do.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Sebastian Pipping
On 03/08/10 18:08, Mark Loeser wrote:
 What is this even in reference to?  Its not at all clear what you are
 trying to do.

Okay, sorry.

I was wondering what classes of bugs there are that are

 - reoccuring (therefore beloning to a class or pattern)

 - relatively easy to fix

 - ideally suited for non-maintainer updates,
 i.e. stuff where the original maintainer just won't mind
 that you touched his ebuild, even if he feels more or less
 like its owner

From such patterns I expect:

 - to find candidates more easy when I myself want to fix something
   within limited time

 - raising awareness on these bugs in hope other feel motivated
   to look outr and fix for some of those, too.

 - use these patterns to find future bugday candidates

A bit clearer now?



Sebastian



Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Sebastian Pipping
On 03/08/10 14:27, Markos Chandras wrote:
 Documentation installation
 There are few packages that call missing  documents on dodoc commands

any idea how to find all these bugs?



sebastian



Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Sebastian Pipping
On 03/08/10 14:13, Róbert Čerňanský wrote:
 On Mon, 08 Mar 2010 11:06:40 +0100
 Sebastian Pipping sp...@gentoo.org wrote:
 
 There are a few patterns for potentially low hanging fruits among
 Gentoo bugs:

   SRC_URI errors
   Missing depencies
 
 (Sorry for answering a developer targeted question while I'm not one.)

happy to have your input.


 - Minor version bumps (After examination what upstream changed and
   after confirmation with mantainer, if any.)

needs good care and a little luck, but still, yes.


 - Stable requests

only if you're an arch tester.


 - New ebuilds

that's a tough one too, because it's often not a good idea to pull
something into the tree, e.g. when you don't use it yourself on a
regular basis.  i have done that before, but i think twice by now.



sebastian



Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Mike Frysinger
On Monday 08 March 2010 05:06:40 Sebastian Pipping wrote:
 There are a few patterns for potentially low hanging fruits among Gentoo
 bugs:

work with the bugday guys to get this incorporated into their documentation

   SRC_URI errors
   Missing depencies
   ...
 
 What else?

incorrect LICENSE / HOMEPAGE
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Jeroen Roovers
On Mon, 08 Mar 2010 14:13:30 +0100
Róbert Čerňanský hslis...@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.

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).

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.


 jer