Fwd: Mentoring for a new member from Brazil.

[Robie Basak]

What do others think about preparing SRUs as a way to get started - in
particular, for upstream bugs fixed upstream? For someone with
programming skills, understanding these triaged bugs and isolating and
cherry-picking fixes shouldn't be too difficult.

I'm ignoring SRUs that are packaging issues here - I think these are
probably more difficult for newcomers.

Then that leaves:

Finding SRU bugs to work on: use our SRU tracker [1].

Understanding the SRU process: it's well documented [2].

Packaging fixes: most packages seem to be quilt packages now, so it's
not much to learn and it's the same process every time.

Another advantage is that it's not difficult to study previous SRUs
- pick a package that's been SRU'd, pull the sources, and run debdiff.
This can provide good examples of how SRUs are done, and this is in
exactly the same format that contributors can attach to bugs for
sponsorship.

[1]: http://people.canonical.com/~jamespage/server-sru/precise-sru.html
[2]: https://wiki.ubuntu.com/StableReleaseUpdates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20130516/74e81a48/attachment.pgp>