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 <[email protected]>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 >
-- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
