UDS Prep: Making it easier to fix bugs
Scott Kitterman
scott at kitterman.com
Tue Nov 2 22:34:27 GMT 2010
"Vishnoo" <vish at ubuntu.com> wrote:
>On Mon, 2010-10-18 at 11:50 +0200, Daniel Holbach wrote:
>>
>> 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.
>
>One issue I'v noticed [with the Papercuts and Ubuntu Desktop Packages]
>is that, new contributors dont understand or rather have a hard time
>understanding that the patch is not applied directly *in* the Ubuntu
>package.
>We usually request the patch to be sent to GNOME and the patch flows
>back down to Ubuntu.
>[Patching Ubuntu desktop packages is usually only done by the Canonical
>Desktop team]
>
>They are often put off by this and lag time it leads to. [I do try to
>poke the upstreams regarding the papercut patches, but it is not always
>easy to catch hold of the upstreams, Timezones! :-/ ]
>
>We should probably look at how we can shorten this lag time or how do
>we
>make it clearer that packages have less Ubuntu-specific patches?
>And that we try to co-ordinate with Upstream or Debian and try to get
>the bugs fixed there first?
>
For Kubuntu development, we have a number of developers that have upstream VCS commit rights and several with commit rights to the relevant Debian team VCS. We often commit to the Ubuntu archive and upstream at the same time.
This generally limits the maintenance effort to dropping the patch when we get a new upstream release hits, but gets the fix out in our next release. IME putting the change in a VCS is much more effective than dropping patches into a bug tracker.
Scott K
More information about the ubuntu-devel
mailing list