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 <[EMAIL PROTECTED]> > > > 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
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
