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: MOTU Decision Making Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Scott Kitterman schrieb: It has seemed to me for some time that making decisions about process and policy changes at MOTU meetings based on votes of those present is not serving us particularly well. Thanks Scott for posting this proposal. I like it very much and have been thinking about the problem myself. 2. Decisions must be ratified on the appropriate mailing list. Discussions at a meeting are good and necessary, but the mailing list has the final say. This is important so that all time zones can be represented and missing a meeting doesn't leave people out. Also in the past we've been exclusively discussing some items just in the MOTU team although the proposed changes affected all developers. It'd be great for those changes to be 1) discussed on ubuntu-devel-discuss@ too 2) be announced on ubuntu-devel@ or ubuntu-devel-announce too This might not apply to each and every debate we have, but for process changes (like SRU and FF) it might make a lot of sense to seek input from a wider range of Ubuntu Developers. (This is not intended as a change to the proposal, but more of a side-note.) Have a nice day, Daniel - -- My 5 today: #224568, #240670, #193502, #196635, #240799 (mlocate) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWNgERjrlnQWd1esRAuWFAJ4i4nOMFhsxMQE8aoXxpyliFxxReQCcCj2y o5L1WsW+Rj8M1Y3R9eGsRik= =LrIz -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
Thank you for the new Quick Search on Synaptic
Thank you for the new Quick Search on Synaptic. It looks great and makes searches much, much, much faster and easier. That's (one of the things) why I love Ubuntu and FOSS so much. -- BUGabundo :o) (``-_-´´) http://Ubuntu.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net 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
merges free for all?
Hi folks, we're getting closer and closer to DebianImportFreeze, which is scheduled next week[1], and we still have a big number of oustanding merges. Hence I'd like to propose that everyone works towards getting merges done, regardless who did the last merge/upload. Of course checking bugs in LP (there are some debdiffs waiting in the sponsors-queue) should always been done first. What do you think? Cheers, Stefan. -- [1]: https://wiki.ubuntu.com/IntrepidReleaseSchedule 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: merges free for all?
Stefan Potyra wrote: we're getting closer and closer to DebianImportFreeze, which is scheduled next week[1], and we still have a big number of oustanding merges. Hence I'd like to propose that everyone works towards getting merges done, regardless who did the last merge/upload. Of course checking bugs in LP (there are some debdiffs waiting in the sponsors-queue) should always been done first. What do you think? That certainly sounds good to me. With only two weeks remaining, there's a fair bit to be merged. In addition to checking bugs in LP, it may also be worth checking bugs in the BTS for greater context for some of the changes to be merged: while a sync remains a goal to reduce work, it's not worth missing testing integration just because someone said I'll get to that soon. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: merges free for all?
Where does it say DebianImportFreeze means anything other than they turn off autosync? 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: merges free for all?
On Wed, Jun 18, 2008 at 08:04:10AM -0400, Scott Kitterman wrote : Where does it say DebianImportFreeze means anything other than they turn off autosync? https://help.ubuntu.com/community/Debian/ImportFreeze?action=showredirect=DebianImportFreeze By this date, all packages that have been modified by both Debian and Ubuntu since the last merge should have been merged at least once in the current release cycle. However, I don't really get the point of such a requirement. Nor do i understand why this has anything to do with DebianImportFreeze Albin Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Albin Tonnerre 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: merges free for all?
Scott Kitterman wrote: Where does it say DebianImportFreeze means anything other than they turn off autosync? I'm not sure it is written anywhere, but historically DebianImportFreeze has always been the target date for completing at least the first round of merges (with an understanding that further merging may be interesting as Debian continues to improve packages). I don't see any reason to change that practice now, simply because such documentation may not exist in some location. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: merges free for all?
Sounds more than fair to me. If anyone has merges outstanding that they want to keep for themselves at this point, they should file a bug and set it in progress. These people are likely to be very much in the minority. Hobbsee 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: merges free for all?
Albin Tonnerre wrote: https://help.ubuntu.com/community/Debian/ImportFreeze?action=showredirect=DebianImportFreeze By this date, all packages that have been modified by both Debian and Ubuntu since the last merge should have been merged at least once in the current release cycle. Oh, excellent. It does exist :) However, I don't really get the point of such a requirement. Nor do i understand why this has anything to do with DebianImportFreeze The primary motivation for doing so is that after this point it should be safe to assume that most of the packages that are being updated for the next distribution have been updated. Whie there may be specific updates after this date to meet certain goals, or close certain bugs, there is no longer the expectation that every package will be updated, and developers may focus on better integration of the current package set, and closing bugs in the existing packages. This time of bug fixing should help us to procude a better quality release. While such bugfixing may include merges, having them long outstanding is more likely to cause transition coordination issues and the like. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: merges free for all?
Hi Iain, Am Mittwoch 18 Juni 2008 14:14:36 schrieb Iain Lane: [..] Can we assume that the advice in the thread from the Hardy cycle[1] is still valid for us now? Right now we haven't reached DebianImportFreeze yet. Generally I think most bits should still apply after DIF. I'll bring that up again, once we've reached DIF, ok? Iain [1] https://lists.ubuntu.com/archives/ubuntu-motu/2007-December/thread.html#288 8 Cheers, Stefan. 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: Thank you for the new Quick Search on Synaptic
2008/6/17 (``-_-´´) -- Fernando [EMAIL PROTECTED]: Thank you for the new Quick Search on Synaptic. It looks great and makes searches much, much, much faster and easier. That's (one of the things) why I love Ubuntu and FOSS so much. -- BUGabundo :o) (``-_-´´) http://Ubuntu.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net -- Ubuntu-devel-discuss mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss Nice feature but atm its not working for me, last time I checked it was greyed out. -- -- Russell -- 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: merges free for all?
Stefan Potyra wrote: Hence I'd like to propose that everyone works towards getting merges done, regardless who did the last merge/upload. +1 from me, although I won't be able to do many merges (if any) anytime soon. 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
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
Re: Packaging JBoss AS for Debian/Ubuntu
Florian Grandel wrote: I am currently helping out in packaging JBoss AS for Debian. It's a first time experience for me so please do not expect me to know the Debian and/or Ubuntu processes very well. 1) Who can I talk to at Ubuntu to coordinate packaging with the Ubuntu developer team or to get sponsorship from Ubuntu? How can I make sure that there is no duplication of efforts at Ubuntu? Is there a Java mailing list or a Java developers group for Ubuntu? The Java packaging team tends to spend time in #ubuntu-java on freenode, but the best strategy is that which you are already following: to get the package into Debian first. 2) What do I have to do to make sure that the package can be admitted to Ubuntu universe once it has been released to Debian contrib? (It certainly is our goal to replace all non-free dependencies but this is work-in-progress.) Once it is accepted into Debian contrib, if DebianImportFreeze (1) has passed, one files a sync request (2), and subscribes the ubuntu-universe-sponsors group for inclusion in universe. A package so constructed will end up in the in the multiverse respository, due to the dependencies. 1: 26 June - see https://help.ubuntu.com/community/Debian/ImportFreeze 2: https://wiki.ubuntu.com/SyncRequestProcess -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
