About forwarding bugs and patches to Debian and documenting your changes

[Nicolas Valcarcel]

Thanks for the examples, now i'm clearer on what you meant.

I also think this will we great, but to have a wiki page for every
package and to edit it with every change it's not the best to do IMHO.
On the other hand we can open a bug for the changes and explain
everything there and just include the (LP: #XXXXX) part to it.

On Wed, 2008-06-18 at 09:44 +0200, Lucas Nussbaum wrote:
> On 17/06/08 at 20:11 -0500, Nicolas Valcarcel wrote:
> > On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum <lucas at lucas-nussbaum.net>
> > > Secondly, you generally could improve a lot at documenting your changes.
> > > If you put more effort on properly documenting what you change in your
> > > packages, it would allow Debian developers to understand why you made a
> > > specific change, and they would be a lot more likely to merge the change
> > > in the Debian package (which means less work for you during the next
> > > merge). If a DD can't figure out why you made a change, it's likely that
> > > he won't ask you, and will just ignore the change.
> > 
> > Can you please give an example of that i don't think i'm fully understanding
> > your point (not a real example, just whatever comes to your mind first)
> 
> Sure. Here are a few examples:
> 
> +  * Merge from debian unstable, remaining changes:
> +    - usbmount creates /var/run/usbmount if it does not exist.
> If you said that this breaks the package on systems where /var/run is
> emptied at boot time (which is FHS-compliant), it would probably help.
> (also, you might want to push that change to a release goal in Debian
> for lenny+1, that would allow to fix all those packages at the same
> time).
> 
> +  * debian/control: add missing libxext-dev build-dependency (fixes
> FTBFS).
> If you said that this was going to be needed in Debian with libx11
> 2:1.1.4-2, I'm sure more maintainers who have merged it.
> 
> +  * debian/rules: Set ARCH_FLAG
> (where the diff in debian/rules is:)
> -ARCHFLAG =
> +ARCHFLAG = -B $(shell dpkg-architecture -qDEB_BUILD_ARCH)
> Everybody can see that you set ARCHFLAG (not ARCH_FLAG, btw). Why was
> that necessary? Which problem is it fixing? Is Debian affected as well?
> 
> +  * debian/patches/03_missing_includes.dpatch: Added. Fixes FTBFS
> Under which conditions does it FTBFS? Is Debian affected as well, or
> likely to become affected as well?
> 
> +  * Merge from debian unstable, remaining changes:
> +    - Use dpatch
> +    - debian/patches:
> +      * kubuntu_01_branch_patch.dpatch
> +      * kubuntu_02_installer_mode.dpatch
> +      * kubuntu_03_fix_desktop_file.dpatch
> +      * kubuntu_04_libparted17.dpatch
> +      * kubuntu_05_german.dpatch
> +      * kubuntu_06_english.dpatch
> +      * kubuntu_07_root_is_sudo.dpatch
> $ grep "^+## DP:" xxxxxxxxxx-3ubuntu1.patch 
> +## DP: No description.
> +## DP: No description.
> +## DP: No description.
> +## DP: No description.
> +## DP: Fix mistakes in German translation, thanks to Christian A.
> Reiter.
> +## DP: Fix mistakes in English strings.
> +## DP: Replace references to root and fix some sentence in the Catalan
> translation.
> Patches without description....
> 
> > > It would be great if, in addition to listing the remaining changes in
> > > the last changelog entry, you could also list for each change:
> > > - the URL of the corresponding Ubuntu bug (if any)
> > > - the URL of the corresponding upstream bug (if any)
> > > - the URL of the corresponding Debian bug (if any)
> > > - a summary of the changes (pointing to URLs explaining the context of
> > >  the change, if possible/needed)
> > > - whether the change is Ubuntu-specific, or should be merged upstream
> > >  or in Debian (with a rationale if is Ubuntu-specific)
> > >
> > 
> > We already work like this, we use to use (LP: #XXXX) which means Launchpad
> > Bug report #XXXX as DD's use (Closes: #XXXX), so there is no much more to do
> > for LP Bugs (Ubuntu ones). For the upstream and debian bugs we link them on
> > the LP Bug report, so if the DD is interested on following links he can from
> > them, with this i'm not saying is the best to do and rejecting your
> > suggestions, just noticing it if you didn't know it, maybe is not as good as
> > it could and we can do it better, so if you have anything to add please do
> > it.
> 
> Linking to bugs is a good thing, but many changes are done without any
> bug in launchpad (or the bug wasn't linked in the changelog). So
> answering the "But why are you making this change? Should I merge it in
> the Debian package?" question requires a lot of effort. I'm not asking
> you to write a ten-line rationale for the patch. Often, 1 to 3 lines
> should be enough. And you could link to a wiki page to provide a more
> detailed explanation of the problem.
> 
> For example, instead of:
> +  * debian/control: add missing libxext-dev build-dependency (fixes FTBFS).
> You could write:
> +  * debian/control: add missing libxext-dev b-dep. See
> +    http://wiki.ubuntu.com/Changes/libext-dev
> +    Should be merged in Debian.
> And then, explain on the wiki that Ubuntu ships a more recent libx11,
> where the dep on libext-dev was removed, so many packages needed to be
> updated, and the change will arrive in Debian too, so it's better if the
> Debian maintainer fixes it as well.
-- 
aka nxvl
Key fingerprint = BCE4 27A0 D03E 55DE DA2D  BE06 891D 8DEE 6545 97FE
gpg --keyserver keyserver.ubuntu.com --recv-keys 654597FE

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20080618/510b61c4/attachment.pgp