Steps to become MOTU

[Charlie Smotherman]

On Thu, 2009-10-29 at 09:58 -0400, Mathieu Trudel-Lapierre wrote:
> Matthias,
> 
> On Thu, Oct 29, 2009 at 9:33 AM, Matthias Klumpp <matthias at nlinux.org> wrote:
> 
> [...]
> 
> > Thank you! At time people aren't very happy about my patches, because my
> > lack of C skills.
> 
> I'm in the same boat. I'm not great at C, but I manage. And obvious,
> practice counts for a lot -- your skills will keep improving. You need
> to keep into account that style will often differ between projects,
> that can also count in getting your patch accepted upstream.
> 
> [...]
> 
> > Because of this difficulties for creating patches (sometimes you build a
> > patch and upstream has fixed this bug for ages! Or you need a very long
> > time to create a patch and while you try this another one fixed this in
> > minutes.), I applied for mentoring, because I think I do something wrong in
> > finding the right bugs for me to patch ;-)
> 
> Maybe it's not that you look at the wrong bugs, but rather simply that
> the code is complex, and familiarity with the it helps. There's also
> one nice source of information if you want to start with "easy" stuff;
> take a look at Harvest:
> 
> http://daniel.holba.ch/harvest/
> 
> Truly awesome to find bugs you can work on, especially look at the
> first column, the "bitesize" bugs. Thanks for that Daniel :)
> 
> Perhaps someone can correct me if I'm wrong, but I find the "easiest"
> workflow is:
> 
> - File a bug in Launchpad, if it's not there already. To make sure
> people who use this in Ubuntu know it's been found, and someone can
> look at it.
> - File the bug upstream, or link to it if it's already there.
> - Make sure you're doing a patch against the latest upstream code, if
> possible. Patch against older versions if necessary.
> - Publish to both bug trackers (launchpad and upstream).
> - Get the patch accepted upstream.
> - If the patch is for something critical (or Ubuntu-specific), and
> getting the latest release from upstream is not possible, patch the
> packaging and provide a debdiff, or bzr merge request, etc.
> 
> You'll obviously as much as possible always want patches accepted
> upstream because it makes sure everybody benefits from the work -- and
> it's easier down the run if patches don't have to be carried over
> between versions and adjusted when the code changes.
> 
> Of course it kind of duplicates the "bureaucratic" aspects of the work
> -- filing the bugs and managing the reports and all, but you get to be
> helpful to both Ubuntu and upstream.

Please forward your patches to the debian maintainer I'm sure he/she
would appreciate it.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-motu-mentors/attachments/20091029/3e7ee6a2/attachment.pgp