Bug/patch reviewing



  Hi all,

(I'm new to this list, but I hang around on IRC, so I hope I'm not too
far off.)

  I'm a happy F-Spot user, and until recently I was only that.  I had
an external (Perl) script to download pictures from my camera and into
F-Spot, but I decided to port it to Mono when 0.4.1 came out, to reuse
the F-Spot classes so I don't have to change the code next time the
database schema changes.  Which got me into the F-Spot coding, then
into the Bugzilla.  I find it great that there are so many patches,
but... they don't seem to get committed, and many of them probably
don't even apply to current code anymore.  I suppose the sheer number
of open bugs and patches is discouraging the core hackers.

  So I'm proposing to help with (part of) the grunt work of looking at
patches to see if they still apply, maybe make suggestions, maybe port
them to current code, and adding comments to the reports.  I'll
probably go on with patch-less bugs afterwards, trying to reproduce
them and checking whether they're still applicable.  Hopefully someone
with the appropriate permissions can then commit the patches and/or
close the bugs.  Any suggestions concerning how I can be most
efficient in this triaging task would be welcome.

  I'm also going to try and give some of the patches more visibility.
By that, I mean make it easier for people to try out the code with the
patches applied.  Not everyone likes to apply patches by hand and deal
with conflicts, and not everyone likes to build their software from
sources.  So my plan involves a bunch of unofficial things:

- a bzr branch, which I'll call upstream-svn/trunk, tracking SVN trunk
  (bzr-svn makes that trivial);

- another one, debian/original+sid, tracking trunk + Debian packaging
  based on the packages currently in Debian unstable (0.4.1, but I'll
  track that too), to allow easy installation of F-Spot trunk;

- a series of patches/bz-123456 branches, each tracking trunk with a
  patch taken from bgo #123456; obviously, bzr's merge abilities will
  allow me to merge updates from trunk if needed to update the patch,
  and from Bugzilla if new versions of the patch are proposed there;

- a patches/superpatch branch, which will track trunk *and* all the
  changes made in patches/bz-* (and I'll handle the conflicts);

- a debian/superpatch+sid, which will contain both the superpatch and
  the Debian packaging;

- an APT repository, where I'll regularly upload Debian packages made
  from debian/superpatch+sid.

  I will of course start with the low-hanging fruit: my initial focus
will be on short patches fixing obvious bugs, and nonintrusive patches
adding simple features.  I'll also use http://f-spot.org/User:Bengtt
as a starting point to select what patches to focus on.

  I would like to gather comments before I commit to doing all that.
I'm particularly interested in making it useful to the committers and
the "official" triagers; I don't want to flood you guys in more email
and updates than necessary, so I'd like to know what kind of
information would make your life easier.

Roland.
-- 
Roland Mas

Reincarnation likes a joke as much as the next philosophical hypothesis.
  -- in The Truth (Terry Pratchett)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]