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