Re: About forwarding bugs and patches to Debian and documenting your changes
One other option for dealing with getting fixes back to Debian that I don't recall seeing mentioned in this thread is to join a packaging team in Debian relevant to an interest area and then just push relevant fixes into the team VCS. I did that with Debian Python Modules Team myself just yesterday. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On 18/06/08 at 13:34 -0500, Nicolas Valcarcel wrote: On Wed, 2008-06-18 at 18:48 +0200, Lucas Nussbaum wrote: On 18/06/08 at 10:12 -0500, Nicolas Valcarcel wrote: 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: #X) part to it. I didn't mean that there should be one wiki page per package. Only that there should be one wiki page (or one section on the same wiki page) for each class of change. In the case of libext-dev, there was probably at least 20 packages affected by that change, where the exact same patch (add libext-dev to build-deps) was needed. Well, i still prefer to open a bug report instead of using a wiki page, it's easier and better for comments/discussion. Do you mean one bug report per package that needs to be changed, or one global bug report, filed against Ubuntu, to track the changes everywhere? In the first case (one bug per package), I think that this creates a huge overhead, and is not going to work. You will have problems convincing people to file a bug each time they make a very simple change that needs to be done in tens of packages. In the second case, as long as there's a simple place with documentation about the change, I'm happy. But I think that a wiki page is a better solution because it's easier to summarize a problem (people can edit the summary). With a bug report, you sometimes have to read a very long discussion before you understand the current state of the issue. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On Tue, 2008-06-17 at 22:10 -0400, Scott Kitterman wrote: On Tuesday 17 June 2008 21:11, Nicolas Valcarcel wrote: Hi, On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum [EMAIL PROTECTED] There's a wiki page on https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines about basically the same thing (it documents the changes in the patches, which is not suitable if the changes are made directly in the source, without using a patch system), but that policy doesn't seem to be in widespread use, unfortunately. I didn't knew about that page and i'm sure a lot of people doesn't know also, are you interested on helping me dive into wiki pages to write a complete document with all of them and then try to spread the word about it/them? Did someone want to help? We have https://wiki.ubuntu.com/ContributingToDebian that would presumably be the right place to start. Yes i knew this one, but there are more things to keep in mind, like keeping track of links and evidence. Also, we have this document but not everyone knows/follows it. Scott K -- 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 Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On 17/06/08 at 22:10 -0400, Scott Kitterman wrote: On Tuesday 17 June 2008 21:11, Nicolas Valcarcel wrote: Hi, On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum [EMAIL PROTECTED] There's a wiki page on https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines about basically the same thing (it documents the changes in the patches, which is not suitable if the changes are made directly in the source, without using a patch system), but that policy doesn't seem to be in widespread use, unfortunately. I didn't knew about that page and i'm sure a lot of people doesn't know also, are you interested on helping me dive into wiki pages to write a complete document with all of them and then try to spread the word about it/them? Did someone want to help? We have https://wiki.ubuntu.com/ContributingToDebian that would presumably be the right place to start. I disagree: the change I'm suggesting is not about being nice to Debian. If you improve the documentation of your changes, you will help yourself (Ubuntu) first. Almost two years ago, I proposed to switch from a simple Merged with Debian entry in changelog, to listing the various changes in the top changelog entry[0]. I think this was a success, and this only pushes things further. [0] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000182.html -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
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: xx-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: #) which means Launchpad Bug report # as DD's use (Closes: #), 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. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On Wed, 18 Jun 2008 09:46:46 +0200 Lucas Nussbaum [EMAIL PROTECTED] wrote: On 17/06/08 at 22:10 -0400, Scott Kitterman wrote: On Tuesday 17 June 2008 21:11, Nicolas Valcarcel wrote: Hi, On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum [EMAIL PROTECTED] There's a wiki page on https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines about basically the same thing (it documents the changes in the patches, which is not suitable if the changes are made directly in the source, without using a patch system), but that policy doesn't seem to be in widespread use, unfortunately. I didn't knew about that page and i'm sure a lot of people doesn't know also, are you interested on helping me dive into wiki pages to write a complete document with all of them and then try to spread the word about it/them? Did someone want to help? We have https://wiki.ubuntu.com/ContributingToDebian that would presumably be the right place to start. I disagree: the change I'm suggesting is not about being nice to Debian. If you improve the documentation of your changes, you will help yourself (Ubuntu) first. Almost two years ago, I proposed to switch from a simple Merged with Debian entry in changelog, to listing the various changes in the top changelog entry[0]. I think this was a success, and this only pushes things further. I agree that was a success and a very good change for Ubuntu. As an Ubuntu developer (that's generally familiar with where to find bugs in Launchpad and BTS), I don't see a lot of benefit within Ubuntu for this last lot of suggestions. Getting more stuff from Ubuntu back into Debian does benefit Ubuntu, but I don't think better debian/changelogs in Ubuntu will help much.. In my experience, reactions to the diff available on PTS are rare. If I want something feed back to Debian, I almost invariably have to put a bug in BTS with the patch. I can explain the rationale there. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On Wed, 2008-06-18 at 01:25 -0700, Bryce Harrington wrote: On Wed, Jun 18, 2008 at 09:44:56AM +0200, Lucas Nussbaum wrote: 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. For this last line, something terser would be preferrable and easier to synthetically parse (i.e. something that won't be likely to word-wrap). Yes, but we lucas isn't saying Do it that way just giving some recommendations to get into a policy or good practices document so the relations between ubuntu and any upstream will improve. Bryce I'm working on a wiki page about good practices [1]. Feel free to add whatever you want, but keep in mind that this must be a general upstream collaboration guide, not just debian. 1. https://wiki.ubuntu.com/GoodPractices -- 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 Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
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: #X) 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: xx-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: #) which means Launchpad Bug report # as DD's use (Closes: #), 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
Re: About forwarding bugs and patches to Debian and documenting your changes
On Wed, 2008-06-18 at 09:13 -0700, Jordan Mantha wrote: This of course assumes the person writing the changelog entry actually knows the answer to those questions. As you say, it requires a lot of effort on the part of the DD. I think it probably takes at least the same if not more effort on the part of the person writing the changelog. A fair amount of the time I don't think merger's really know why a change is needed or if it applies to Debian or not. Yes, but mergers don't change anything, just apply some changes, we are talking about changing things, and if you don't know these answers when you make a change, then you are not able to do changes to ubuntu packages. About the applies to debian thing i'm with you, it's hard to know if you don't have a debian system on hands, but if you know that it applies also to debian, please write it there. -- 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 Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On 18/06/08 at 10:12 -0500, Nicolas Valcarcel wrote: 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: #X) part to it. I didn't mean that there should be one wiki page per package. Only that there should be one wiki page (or one section on the same wiki page) for each class of change. In the case of libext-dev, there was probably at least 20 packages affected by that change, where the exact same patch (add libext-dev to build-deps) was needed. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On 18/06/08 at 09:13 -0700, Jordan Mantha wrote: On Wed, Jun 18, 2008 at 12:44 AM, Lucas Nussbaum [EMAIL PROTECTED] 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] snip 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. This of course assumes the person writing the changelog entry actually knows the answer to those questions. As you say, it requires a lot of effort on the part of the DD. I think it probably takes at least the same if not more effort on the part of the person writing the changelog. A fair amount of the time I don't think merger's really know why a change is needed or if it applies to Debian or not. While I appreciate your suggestions here and think it should definitely be the goal push things back to Debian, many people simply won't know if something applies to Debian specifically or not. I can think of several Debian bugs I've seen over the years where an Ubuntu contributor mistakenly thought an Ubuntu change applied to Debian when in fact it did not. The Debian maintainer is definitely in the best position to figure out if it applies them or not. They know the package and they know Debian. We should certainly try to give the information a Debian maintainer needs. But, for instance, I feel quite uncomfortable telling a Debian maintainer (who has maybe worked on package for years) they should take a patch in a package I've never touched before and am just propagating Ubuntu changes in. I hope that mergers understand the changes they merge, and understand if they are still necessary or not (for Ubuntu). If not, that confirms that there's an issue with documentation of the changes. But I agree with you that the Ubuntu Developer is not in the best position to judge whether a change is applicable or not to Debian. Something you could do without giving the impression that you are giving orders to the Debian maintainer, is to clearly mark Ubuntu-specific changes, when they are only useful for Ubuntu. A simplistic example could be: * Replace iceweasel with firefox in Depends. Ubuntu-only: firefox is renamed iceweasel in Debian. This is why I agree with Scott Kitterman that bugs in Debian's BTS are a much better place to discuss the appropriateness of Ubuntu changes for Debian than in changelog entries. Sure. But that's a different issue: Ubuntu developers are never going to open a bug in the BTS for every minor change they make to a Debian package. I agree that bugs should be preferred, but that's not a reason not to improve the way you communicate through debian/changelog. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On Wed, 2008-06-18 at 18:48 +0200, Lucas Nussbaum wrote: On 18/06/08 at 10:12 -0500, Nicolas Valcarcel wrote: 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: #X) part to it. I didn't mean that there should be one wiki page per package. Only that there should be one wiki page (or one section on the same wiki page) for each class of change. In the case of libext-dev, there was probably at least 20 packages affected by that change, where the exact same patch (add libext-dev to build-deps) was needed. Well, i still prefer to open a bug report instead of using a wiki page, it's easier and better for comments/discussion. I have open a wiki page [1] with some points about this conversation. 1. https://wiki.ubuntu.com/GoodPractices -- 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 Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
Lucas Nussbaum wrote: I didn't mean that there should be one wiki page per package. Only that there should be one wiki page (or one section on the same wiki page) for each class of change. In the case of libext-dev, there was probably at least 20 packages affected by that change, where the exact same patch (add libext-dev to build-deps) was needed. For big transitions or things like this, IMHO I think it's better to do a MBF in the BTS if that's going to affect Debian as well. And when it's specific to one package, it would be overkilling to put it in the wiki. The changelog should explain it. So I agree with you in that Ubuntu changes should be better documented, but I don't like the wiki idea. Cheers, Emilio signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On 18/06/08 at 21:22 +0200, Emilio Pozuelo Monfort wrote: Lucas Nussbaum wrote: I didn't mean that there should be one wiki page per package. Only that there should be one wiki page (or one section on the same wiki page) for each class of change. In the case of libext-dev, there was probably at least 20 packages affected by that change, where the exact same patch (add libext-dev to build-deps) was needed. For big transitions or things like this, IMHO I think it's better to do a MBF in the BTS if that's going to affect Debian as well. The problem is that sometimes, Ubuntu transitions earlier (or does transitions that Debian doesn't even consider -- think of /var/run). In that case, a MBF in Debian won't be useful, because the Debian maintainers might simply ignore the bugs. And when it's specific to one package, it would be overkilling to put it in the wiki. The changelog should explain it. So I agree with you in that Ubuntu changes should be better documented, but I don't like the wiki idea. I agree that a wiki page should only be used for big transitions, not for every small change. I now realize it wasn't clear earlier, sorry. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
About forwarding bugs and patches to Debian and documenting your changes
Hi, As you might have read in [1], I worked on exporting more info about packages in Ubuntu to the Debian infrastructure, specifically the Debian PTS[2] and the Debian Developer Packages Overview[3]. [1] http://www.lucas-nussbaum.net/blog/?p=295 [2] http://packages.qa.debian.org/d/dpkg.html [3] http://qa.debian.org/[EMAIL PROTECTED]ubuntu=1 However, I'd like to use that opportunity to discuss a few points: I know you are over-busy, etc., and that your #1 priority can't be to push changes back to Debian. But those changes should not replace submitting bugs to the Debian BTS, like the patches on patches.u.c should not replace submitting patches to the BTS. Most Debian Developers will probably only rarely have a look at the bugs in LP. If I hear Ubuntu Developers saying but there was no need to report it to Debian, you already should have known about it since there was a link on PTS/DDPO!, I will strongly regret pushing that change. 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. 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 it's Ubuntu-specific) There's a wiki page on https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines about basically the same thing (it documents the changes in the patches, which is not suitable if the changes are made directly in the source, without using a patch system), but that policy doesn't seem to be in widespread use, unfortunately. Thank you, -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
Hi, On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum [EMAIL PROTECTED] wrote: Hi, As you might have read in [1], I worked on exporting more info about packages in Ubuntu to the Debian infrastructure, specifically the Debian PTS[2] and the Debian Developer Packages Overview[3]. [1] http://www.lucas-nussbaum.net/blog/?p=295 [2] http://packages.qa.debian.org/d/dpkg.html [3] http://qa.debian.org/[EMAIL PROTECTED]ubuntu=1 However, I'd like to use that opportunity to discuss a few points: I know you are over-busy, etc., and that your #1 priority can't be to push changes back to Debian. But those changes should not replace submitting bugs to the Debian BTS, like the patches on patches.u.c should not replace submitting patches to the BTS. Most Debian Developers will probably only rarely have a look at the bugs in LP. If I hear Ubuntu Developers saying but there was no need to report it to Debian, you already should have known about it since there was a link on PTS/DDPO!, I will strongly regret pushing that change. This is true, it doesn't take a long time to report a Bug tu debian, and we can't be lazy and say the patch is there, if the DD want's it, he/she can download it from there since we want our changes in there for easier maintainment of our packages, DD's only care about their Bugs, not ours. 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) 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 it's Ubuntu-specific) We already work like this, we use to use (LP: #) which means Launchpad Bug report # as DD's use (Closes: #), 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. There's a wiki page on https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines about basically the same thing (it documents the changes in the patches, which is not suitable if the changes are made directly in the source, without using a patch system), but that policy doesn't seem to be in widespread use, unfortunately. I didn't knew about that page and i'm sure a lot of people doesn't know also, are you interested on helping me dive into wiki pages to write a complete document with all of them and then try to spread the word about it/them? Did someone want to help? Thank you, -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIV5dZ2hliNwI7P08RAmtUAJoC7JrcZ1xZwsQMOx5tKgYFYfndRQCdHhg2 ZI7NB+Hh5rbVCL+VoIrEtDI= =Bft/ -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On Tuesday 17 June 2008 21:11, Nicolas Valcarcel wrote: Hi, On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum [EMAIL PROTECTED] There's a wiki page on https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines about basically the same thing (it documents the changes in the patches, which is not suitable if the changes are made directly in the source, without using a patch system), but that policy doesn't seem to be in widespread use, unfortunately. I didn't knew about that page and i'm sure a lot of people doesn't know also, are you interested on helping me dive into wiki pages to write a complete document with all of them and then try to spread the word about it/them? Did someone want to help? We have https://wiki.ubuntu.com/ContributingToDebian that would presumably be the right place to start. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
