Fwd: Mentoring for a new member from Brazil.

[Tiago Porangaba]

It sounds interesting! I did read SRU process and did setup the dev
environment on my machine.

However I am not sure what you mean saying *"isolating and*
*cherry-picking fixes shouldn't be too difficult."*
*
*
My guess is that you mean that I should pick a triaged bug, pick one fix
from some suggested fixes and submit this fix (after QA). Is that right?

Meanwhile, I am starting to run debdiff for some previous SRU as you
suggested.

Good way to learn, by the way. Thanks!

Um abraço,
Tiago Porangaba


On Thu, May 16, 2013 at 3:02 AM, Robie Basak <robie.basak at canonical.com>wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20130518/ea552a96/attachment.html>