UDS Prep: Making it easier to fix bugs

[Daniel Holbach]

Am 15.10.2010 19:15, schrieb Emmet Hikory:
> Daniel Holbach wrote:
>> at UDS I'd like to discuss how we can make it easier to fix bugs,
>> especially for new contributors.
>>
>> I documented the steps that are necessary at
>>
>>        http://people.canonical.com/~dholbach/Fixing%20a%20bug.png
> 
>     A couple complications to add :)
> 
> 1) Under "Finding the solution", there's also other distributions, and
> downstream.
> 2) Under "Follow conventions", there's also often writing test cases

Thanks, added.


>     A lot of this process grew because we had one or another issue
> that ended up causing us to add something.  Some of it comes from an
> attempt to preserve choice (either by us, or inherited from Debian).
> I think we'd do best to avoid attempting to develop a
> one-size-fits-all *the way* for new folk to get stuff done.  Instead,
> I think we'd do better to enage in two parallel paths:
> 
> A) Break down the process of finding a bug to having the fix as far
> upstream as makes sense into lots of little steps, and encourage
> newcomers to pick some step and repeat it for N bugs.  This makes the
> barrier to entry for any of the steps fairly low, and lets someone
> contribute effectively quickly.  It also fosters communication and
> coordination within the community as people hand off things from one
> stage to the next.
> 
>     Note that nothing here would involve any of the messiness of
> dealing with Ubuntu packaging, Ubuntu conventions, release-stage
> considreations, multiple parallel review processes, etc.  Just find
> bugs, identify the responsible bit, track down fixes, test them (local
> direct conventionless builds are probably fine), and get them
> upstream.  While nothing here directly appears to affect Ubuntu, every
> bugfix patch that gets upstream improves Ubuntu in the long term, and
> it often is not hard to cherrypick such patches if there is some
> special need to have them in Ubuntu sooner, or as an SRU.

Do you envision something like the process of the Patch Reviewers team
to do this? So tags (and/or fixed-elsewhere statuses) would show things
that can be "picked from upstream"?

	https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide


> B) Much more heavily encourage each of the growing number of
> development teams to document some realtively easy tasks that can be
> done through completion, following procedures, conventions, etc. (the
> annoying bits), but using known bugfixes for known packages (e.g.
> cherrypicks, backports, merges, upstream updates, etc.).

I hope the new Harvest (announce coming soon) will help with that. We
will need to tweak and add some data feeds, but I'm sure it'll help with
that.


>     People who just want to do *something* or fix *this* bug would use
> the (A) processes, either handling one step for many bugs, or all the
> steps for one bug, or whatever mix they prefer.  People who want to
> focus on some particular development area (e.g. Xubuntu Desktop,
> CLI/Mono, etc.) would have an easy way to get involved with the
> relevant development team, and help improve whatever "product" is
> produced by that team.

I hope that packageset selection in Harvest will help with that.


>     Those folk who stick around a long time will eventually understand
> larger and larger portions of the big messy diagram, but it's just too
> much to grasp at first, and we can easily produce much more palatable
> chunks of work.

I like the ideas you had above, but I still think that we need to
improve our documentation and stream-line it some more, also we should
fix our tools to make it easier to make an informed decision and take
away some of the busy-work.

Have a great day,
 Daniel