Re: Deprecating the wiki-based Packaging Guide
Hello, On 17.12.2012 22:01, Andrew Starr-Bochicchio wrote: 1) Send a last-call anouncement to ubuntu-devel requesting bug reports about any missing material. Announce steps 2 and 3 will take place after one month. 2) Move the entire PackagingGuide wiki namespace en masse to PackagingGuideDeprecated. 3) Redirect wiki.ubuntu.com/PackagingGuide to developer.ubuntu.com/packaging/html/ 4) After six months (one full development cycle) PackagingGuideDeprecated will be deleted. I just took care of 2) and 3). The old content is still available at https://wiki.ubuntu.com/PackagingGuide Have a great day, Daniel -- Ubuntu Developer Week - https://wiki.ubuntu.com/UbuntuDeveloperWeek 29th-31st Jan 2013 - Your great chance to finally get involved! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Barry Warsaw [2013-01-08 14:59 -0500]: IMHO, the main obstacle is the success rate of the package importer. In my experience that doesn't matter. If a package doesn't have a current UDD branch, then there's always the good old apt-get source/edit. IMHO the main obstacle is that UDD does not work well for common use cases. I find myself not exactly liking UDD even for the (vast majority of) packages where the branches are up to date, mostly because its design is a bit upside down: It has pretty much perfect VCS behaviour for precisely those bits which we do not want to change in a distro: the original upstream source. For changing them, we need to use quilt and debian/patches/, which is the very same approach than with plain apt-get source, except that UDD imposes a lot of extra overhead: I have to take care to pre-apply patches, add/track all the extra .pc stuff, do things three times in a row until the pre-applied patches stop conflicting with the operation that I'm currently doing (new upstream source, editing or adding a patch), etc. A few years ago I set up a package (calibre) to use proper VCS with threads instead of patches; that worked much better and much more consistently, but I gave it up because nobody else in the world knew how to use that branch. Chicken-egg problem. Also, UDD is incompatible with having upstream develop on Launchpad as the branches share no history and thus you can't just bzr merge lp:trunk for a new upstream version, cherrypick changes, etc. This breaks a lot of the reasons why one wants to use a VCS in the first place. Now, those two things (patching packages and working with packages whose upstream is on LP) is, or at least had been for many years, my bread and butter of what I do in Ubuntu. This might be different for other people who mostly work on packaging or native packages; UDD works well for both cases, and I like those branches myself as well for those cases. But these are the reasons why the desktop team doesn't use UDD: one half of our packages has upstreams on LP (indicators, Unity, software-center, etc.), and the main exercise on other half (GNOME) is patching and upstream version updates, not changing packaging. So in summary, I think the packaging documentation should certainly explain UDD, but at least point out that some packages are maintained differently (point out https://wiki.ubuntu.com/DesktopTeam/Bzr, the Vcs-Bzr: field, and apt-get source). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On Jan 09, 2013, at 09:03 AM, Martin Pitt wrote: IMHO the main obstacle is that UDD does not work well for common use cases. I find myself not exactly liking UDD even for the (vast majority of) packages where the branches are up to date, mostly because its design is a bit upside down: It has pretty much perfect VCS behaviour for precisely those bits which we do not want to change in a distro: the original upstream source. For changing them, we need to use quilt and debian/patches/, which is the very same approach than with plain apt-get source, except that UDD imposes a lot of extra overhead: I have to take care to pre-apply patches, add/track all the extra .pc stuff, do things three times in a row until the pre-applied patches stop conflicting with the operation that I'm currently doing (new upstream source, editing or adding a patch), etc. Yeah, I get that. FWIW, I have a successful workflow for quilt branches that isn't very painful, and does benefit from having the full source package under bzr. I've mentioned it before on this list, but I should probably update the packaging guide. A couple of rules: 1) Always commit with your quilt stack at the same level as the original branch. This usually means popping your last patch before you commit. 2) Never push your branch back to Launchpad. Upload it as normal and let the package importer do all the merge magic. What I like about UDD for quilt branches is that I don't have to worry much about generating the patch. I can mostly edit the original source and use `bzr diff` to generate the first quilt patch. From there, I generally use quilt command to refresh the patch until it's ready. Rule #1 above will leave you with a clean upstream source tree and the new quilt patch (which of course you have to `bzr add`). And of course using bzr works great when you're hacking in debian/. Could it work better? Yes, definitely. It's been discussed for years now. *Will* it get better? I can't answer that. :) Also, UDD is incompatible with having upstream develop on Launchpad as the branches share no history and thus you can't just bzr merge lp:trunk for a new upstream version, cherrypick changes, etc. This breaks a lot of the reasons why one wants to use a VCS in the first place. Highly agreed here. I can see that desktop would feel this pain more acutely. Now, those two things (patching packages and working with packages whose upstream is on LP) is, or at least had been for many years, my bread and butter of what I do in Ubuntu. This might be different for other people who mostly work on packaging or native packages; UDD works well for both cases, and I like those branches myself as well for those cases. But these are the reasons why the desktop team doesn't use UDD: one half of our packages has upstreams on LP (indicators, Unity, software-center, etc.), and the main exercise on other half (GNOME) is patching and upstream version updates, not changing packaging. So in summary, I think the packaging documentation should certainly explain UDD, but at least point out that some packages are maintained differently (point out https://wiki.ubuntu.com/DesktopTeam/Bzr, the Vcs-Bzr: field, and apt-get source). stokachu mentioned that Fedora uses a dvcs (git?) to do a lot of their package management and that their workflow is well integrated with the build system. I could have that totally wrong, as I have no experience with it, but I still firmly believe that package management should be well integrated with a dvcs. It's usable in a lot of cases for Ubuntu today with UDD, but it clearly has yet to realize its full potential. Cheers, -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On Dec 18, 2012, at 07:16 PM, Mike Carifio wrote: I'm the first person to admit that I probably don't get it yet or see the obstacles to UDD utopia. IMHO, the main obstacle is the success rate of the package importer. Still, according to the status page [1] there are 821 failures. Is this page [2] is an accurate count of the number of source branches in Ubuntu (all packages in all supported releases)? If so, then we're talking about a failure rate of about 0.25% which seems pretty darn low. Of course, that doesn't help if the one you want to work on is failing. What we really need are the adequate resources of experts to help drive the failure rate to zero, but I don't think the people I know who could make a serious dent in that number are available right now. Cheers, -Barry [1] http://package-import.ubuntu.com/status/ [2] https://code.launchpad.net/ubuntu -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based, Packaging Guide)
Hi, Le 20/12/2012 13:00, ubuntu-devel-requ...@lists.ubuntu.com a écrit : Date: Wed, 19 Dec 2012 11:16:49 -0500 From: Barry Warsaw ba...@ubuntu.com To: ubuntu-devel@lists.ubuntu.com Subject: Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide) Message-ID: 20121219111649.58ce8...@resist.wooz.org Content-Type: text/plain; charset=us-ascii On Dec 18, 2012, at 06:05 PM, Steve Langasek wrote: UDD poses a different set of problems. I'm not sure how relevant it is to the upstream developer who just wants to package their software; at the very least, I think the developer docs should explicitly deal with the possibility that the upstream has already made a different VCS choice that's not bzr. The packaging guide has a bit of a schizophrenic heritage, and it's not quite sure what audience it's trying to reach. Is it upstream developers who just want to package their software? Is it drive-by Ubuntu contributors who want to gain some experience fixing a bug or scratching their own itch? Is it the experienced developer who whats a reference to preferred tools? Maybe I can share my experience on how I've seen and used the packaging guide in the past year, coming from complete debian packaging ignorance. I've looked at the guide as a best practice from the Ubuntu community on how things should be done correctly to produce good quality packaging. Since my work is solely working on existing packages, it was a great help in understanding why things are done a certain way and how to continue to do things adequately. It was a great help in doing a fast ramp up to packaging and I still use it regularly to confirm part of my workflow. Maybe a good understanding of the target audience might help to stear some of its content. Kind regards, ...Louis -- Louis Bouchard Backline Support Analyst Canonical Ltd Ubuntu support: http://landscape.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Dec 18, 2012, at 06:05 PM, Steve Langasek wrote: UDD poses a different set of problems. I'm not sure how relevant it is to the upstream developer who just wants to package their software; at the very least, I think the developer docs should explicitly deal with the possibility that the upstream has already made a different VCS choice that's not bzr. The packaging guide has a bit of a schizophrenic heritage, and it's not quite sure what audience it's trying to reach. Is it upstream developers who just want to package their software? Is it drive-by Ubuntu contributors who want to gain some experience fixing a bug or scratching their own itch? Is it the experienced developer who whats a reference to preferred tools? Certainly, the original UDD guide (from which much of the current packaging text was lifted) was written for experienced developers wanting to understand how to use UDD to maintain packages for Ubuntu. And where Ubuntu development is concerned, I regret that I have to agree with Scott that the lack of reliability for the existing UDD branches is a problem, and one that doesn't seem to be getting better over time. So while I personally favor the UDD workflow (and fervently disagree with Scott's claim that it's a more complex toolset), I think we do need to reconsider if it's actually beneficial to steer developers down this path. Whether or not there's a consensus that we should be using UDD, it's no use to new developers if it doesn't actually work. I think it's only going to get better if some of us enthusiasts step up to help start fixing things. I'm not entirely sure where to start, but that a topic for the udd mailing list, not this one. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Hello, On 18.12.2012 01:52, Scott Kitterman wrote: UDD is not mature or reliable enough to be presented to new users as the way to do packaging for Ubuntu. I think the current guide is fatally flawed as is. As soon as a branch is out of date, new users are lost. while out-of-date branches and other bits and pieces around UDD are a problem, can we please make them a separate discussion? We can certainly have a discussion about our Development Guide and what we recommend in which way. The reality and motivation of the current discussion is that two guides are simply confusing and that the Wiki documentation hasn't been touched or updated in any meaningful way in ages. I'd suggest we agree on one guide and then figure out what we recommend, rewrite or improve in there. This shouldn't be a blocker for obsoleting one of the guides. Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On 12/18/2012 09:23 AM, Daniel Holbach wrote: Hello, On 18.12.2012 01:52, Scott Kitterman wrote: UDD is not mature or reliable enough to be presented to new users as the way to do packaging for Ubuntu. I think the current guide is fatally flawed as is. As soon as a branch is out of date, new users are lost. while out-of-date branches and other bits and pieces around UDD are a problem, can we please make them a separate discussion? We can certainly have a discussion about our Development Guide and what we recommend in which way. The reality and motivation of the current discussion is that two guides are simply confusing and that the Wiki documentation hasn't been touched or updated in any meaningful way in ages. I'd suggest we agree on one guide and then figure out what we recommend, rewrite or improve in there. This shouldn't be a blocker for obsoleting one of the guides. Have a great day, Daniel I think the point is that the new guide would have to include the pull-lp-source/debdiff/attach to bug route as well before some of us are comfortable deleting that information from the Wiki. It's not so much where it lives as that it's available as a fallback. Thanks, Micah -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Hello, On 18.12.2012 16:35, Micah Gersten wrote: I think the point is that the new guide would have to include the pull-lp-source/debdiff/attach to bug route as well before some of us are comfortable deleting that information from the Wiki. It's not so much where it lives as that it's available as a fallback. It does: http://developer.ubuntu.com/packaging/html/traditional-packaging.html Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 03:16:13PM +0900, Emmet Hikory wrote: While it may appear that way at first glance, this is very much an intentional consequence of policy-based packaging, which Ubuntu inherits from Debian. By having packaging judged against policy, rather than against some arbitrary implementation, we are free to continuously innovate in our use of tools to improve our packaging. Innovations that lead to interesting consequences frequently become policy, such that all other packaging toolchains in the archive are expected to support the expected results (or be retired). However, as this has been an ongoing process of competitive improvement of the several toolchains over more than 20 years, and as many packages have not been updated in some time (this may be by design: e.g. mpi-specs, which likely won't be updated for many more years to come), and many how to package documents are floating around the internet, this means that every possible experimental means of packaging is documented somewhere (and may show up in your favorite search engine), and many of them are used for packages extant in the current archive. There is definitely a set of tools that are currently the most popular in the Debian archive, and these integrate well with a set of tools being developed under the Ubuntu Distributed Development moniker, which combination may well likely be that which is recommended by the Ubuntu Packaging Guide under development: as such, this recommendation [0] is what ought be followed by the class of developers for whom packaging is a means to an end (as they are often focused on a specific piece of software). For folk who might focus on packaging as an end, preferring the role of distribution developer to that of application developer, there is a need for a greater understanding of the underlying policy and the massive variety of tools by which this policy may be implemented. People who are aiming to contribute to Ubuntu as a distribution absolutely need to master a different set of skills than those who just want to package up their own software. In terms of developer documentation, I think the important goals are that: - We make sure everyone has a handle on the second category before they tackle the first category. - We avoid annoying or distracting developers who only care about the second category with information that's only relevant in the first category. - We ensure that developers who are looking to participate in Ubuntu development can find the information they need from the same entry point. - We ensure that the recommendations that we're giving developers for creating packages for their software aren't at odds with the consensus among experienced Ubuntu developers about how a package should look. I think the current Ubuntu Packaging Guide is doing a reasonably good job of walking this line. Where it isn't, I'm sure bug reports are welcome. Where this is understandably annoying for the application developer is that the recommendation is subject to change over time, as newer tools are developed and adopted: we tend to select toolsets that provide the most automation while leaving us the facility to make local exceptions to standard processing as appropriate for specific packages, which may appear to require an application developer to relearn from scratch every so many years. In practice, the lifecycle of a toolset is typically much longer than the period during which it is the most popular for use, and it is rare for toolsets to be entirely retired (although in some cases the maintainer of the packaging toolset may declare they no longer intend to support it, and it will only live on if someone else is willing to update it to support current policy). As a result, once one learns some means of packaging, one may usually continue with that method for a fairly long time without need to change unless one is excited about new features of a newer toolset. Where package tooling has changed recently, it has mostly been about incremental improvements rather than revolutionary changes. At the packaging level, http://people.debian.org/~cjwatson/dhstats.png shows that dh(1) has had dominant mindshare for over 3 years (shown by the constant growth in usage), and if it doesn't quite yet represent the way the majority of packages in the archive are done, this has more to do with the inertia of existing packages than with any lack of consensus. Prior to the advent of dh(1), there *was* a distinct lack of consensus, with developers divided roughly equally between cdbs and debhelper camps. So I do think it's important that any documentation that's teaching people how to package focus on dh, and explicitly relegate non-dh packaging to the category of here's what to do if you need to work on an existing package that doesn't follow best practices. UDD poses a different set of problems. I'm not sure how
Re: Deprecating the wiki-based Packaging Guide
Mike Carifio cari...@usys.com wrote: On 12/18/2012 05:48 PM, Scott Kitterman wrote: Barry Warsaw ba...@ubuntu.com wrote: On Dec 17, 2012, at 07:52 PM, Scott Kitterman wrote: UDD is not mature or reliable enough to be presented to new users as the way to do packaging for Ubuntu. I think the current guide is fatally flawed as is. Yes, it's frustrating when you need to work on a package that has import failures, and yes, I wish we had more cycles to devote to fixing this, but the majority of packages import just fine, and UDD (IMHO and YMMV) has enormous benefits which outweigh those frustrations. Of course, I'm not saying that traditional packaging shouldn't also be described. -Barry It seems obvious to me that the standard approach ought to be the reliable one. Making the UDD based approach 'normal' ensures people need to know two ways to do it and for introductory material, I think that is clearly suboptimal. Also, I think the benefits primarily accrue to people that use UDD a lot. The benefits to people that don't use it quite regularly are minimal. This reinforces the idea it's not the right default to present. Finally, it's a more complex toolset that raises the barrier to entry for newcomers. I don't think that's what we want. Scott K I don't mean to be argumentative, but none of that seems obvious to me. If UDD is a better workflow when it works, then fix it until it works. Then describe it so it makes sense. Then use it consistently to improve the ecosystem. That will make it the default. Right now, we seem to have to work with debian source packages so we can feed the build system but work with a version control system to upstream changes in a productive way. That seems suboptimal too. I'm the first person to admit that I probably don't get it yet or see the obstacles to UDD utopia. But not using a version control tool for a source code control problem doesn't make sense either. Downloading a Debian source package or even a source package and a Debian only bzr branch (as the Kubuntu team does) is much faster than downloading full source bzr branches. Unless someone works with a specific package routinely, full source branches slow the process up significantly. I find the interfaces to the UDD tools very confusing. Here's but one example (yes, I filed a bug, no I don't recall the number): The basic dpkg-buildpackage command to build a source package that will include the upstream tarball in the upload is: dpkg-buildpackage -S -sa For the non-UDD dpkg-buildpackage wrapper debuild, one attaches dpkg-buildpackage options on the end and they are passed to dpkg-buildpackage: debuild -S -sa bzr-builddeb has this interface: bzr-builddeb -S -- -sa Go figure that one out (yes, I understand it and why, but I think it's a user hostile interface design). The biggest benefit of UDD, IMO is that each upload is imported into a VCS so we have per upload history. That happens no matter how the package is built or uploaded. All the additional complexity of committing to the VCS and getting that merged has very minimal benefits for the average developer. The people you see advocating that UDD has great advantage for them are ~all people who do this full time and can live in the UDD environment. They aren't the target audience for the packaging guide. I think the lack of reliability argument is sufficient for now to make the case that UDD should not be the 'normal' method taught to new people. Even if that weren't the case though, I would still think the added leaving curve coupled with creating a barrier to collaboration with our primary upstream would mean it's still not a good idea. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. I don't think such a consensus, outside of the small group of people that invested time in the packaging guide, exists. The Kubuntu team does not use it and last I checked Ubuntu Desktop didn't either. There are people the use UDD, of course, but also large numbers that don't. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On Tue, Dec 18, 2012 at 09:09:39PM -0500, Scott Kitterman wrote: I find the interfaces to the UDD tools very confusing. Here's but one example (yes, I filed a bug, no I don't recall the number): The basic dpkg-buildpackage command to build a source package that will include the upstream tarball in the upload is: dpkg-buildpackage -S -sa For the non-UDD dpkg-buildpackage wrapper debuild, one attaches dpkg-buildpackage options on the end and they are passed to dpkg-buildpackage: debuild -S -sa bzr-builddeb has this interface: bzr-builddeb -S -- -sa 'bzr bd -- -S -sa' works equally well, and could be the usage recommended in the documentation for consistency. The biggest benefit of UDD, IMO is that each upload is imported into a VCS so we have per upload history. That happens no matter how the package is built or uploaded. All the additional complexity of committing to the VCS and getting that merged has very minimal benefits for the average developer. One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 09:19:31PM -0500, Scott Kitterman wrote: Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. I don't think such a consensus, outside of the small group of people that invested time in the packaging guide, exists. There may or may not be such a consensus. But the consensus is what matters, and the above argument is therefore irrelevant to whether UDD should be the recommended workflow. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 09:09:39PM -0500, Scott Kitterman wrote: I find the interfaces to the UDD tools very confusing. Here's but one example (yes, I filed a bug, no I don't recall the number): The basic dpkg-buildpackage command to build a source package that will include the upstream tarball in the upload is: dpkg-buildpackage -S -sa For the non-UDD dpkg-buildpackage wrapper debuild, one attaches dpkg-buildpackage options on the end and they are passed to dpkg-buildpackage: debuild -S -sa bzr-builddeb has this interface: bzr-builddeb -S -- -sa 'bzr bd -- -S -sa' works equally well, and could be the usage recommended in the documentation for consistency. The biggest benefit of UDD, IMO is that each upload is imported into a VCS so we have per upload history. That happens no matter how the package is built or uploaded. All the additional complexity of committing to the VCS and getting that merged has very minimal benefits for the average developer. One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. I should clarify here that I meant a merge of a new upstream version packaged in Debian. For packaging-only merges, debdiffs work fine. It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. I should clarify here that I meant a merge of a new upstream version packaged in Debian. For packaging-only merges, debdiffs work fine. It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. Right. What I really want (and what our docs asked for at one point) is a packaging diff (debian dir) and a pointer to the upstream tarball. I said the branch would be useless to me, because I'd have to extract out the packaging diff and redo the merge to make sense of it. BTW, I didn't come to my perspective on UDD without trying it.I gave it a real go, but it just didn't work for me. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
Steve Langasek wrote: On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. This exchange leaves me even further confused about how UDD works, but reviewing merges for new upstream sources has always been a bit fussy, and while interdiffs of diff.gz worked reasonably for format:1.0 packages, there is no useful equivalent for format:3.0 packages. When I'm attempting to review someone else's merge, I generally want them to send me enough information that I can produce their candidate artifacts locally for upload, and generally want to do so in a way that reduces the opportunity for them to submit files that don't match history (either previously in Ubuntu or in Debian). My review tends to consist of looking at the prior Ubuntu-only changes, looking at the upstream changes, looking at any changes beyond the new upstream version from Debian, and ensuring that the resulting artifacts contain the best possible blend of all of these (possibly combined with fixes for other outstanding bugs found in Ubuntu). With a non-UDD workflow, this involves getting the outstanding Ubuntu diff (patches.ubuntu.com or merges.ubuntu.com have them if one doesn't want to download source artifacts and run locally), getting the Debian diff (also available from merges.ubuntu.com), and some artifact diff (which could be that presented for sponsoring, although I tend to generate local artifacts and regenerate the diff). If I want to separate distribution changes and upstream changes, filterdiff can help, or I can run diffs only against contents of debian.tar.gz (or other selected artifacts). With a UDD workflow, this involves getting the candidate branch, reviewing the history to confirm it inherits from preexisting UDD branches, and then using bzr to generate the same set of diffs, for the same level of manual consideration. There are no shortcut pre-generated diffs I can download, but the bzr branch contains everything so there is no need to pull from multiple sources: depending on one's local environment this may be either good or bad in terms of total bandwidth and processing requirements (and one can convince launchpad to generate the diffs, if one is sufficiently motivated and lacks local processing facilities). In either case, once I have a local artifact, unless I'm dealing with a package that is handled by some team that doesn't like it, I can just upload. When I'm dealing with packages where teams want special things done, regardless of which solution I choose above, I need to go fiddle with their special VCS arrangements or get complained at later. Now, it may be that in one of my summaries above, I've mischaracterised one of the workflows, and if so I'd very much like to read an expansion of both procedures by someone who has a very strong preference for one or another workflow based on what they consider to be the user experience. On the other hand, if I've not mischaracterised it, how can *either* the branch or the necessary diff to generate candidate artifacts be useless? While I don't personally see any benefit of one over the other except in terms of access speed to review materials (which depends on sufficient local factors that it isn't likely to be generally applicable), I don't understand how I would have to redo the merge in either case, how I would be able to perform the necessary level of scrutiny of the candidate without reviewing the same set of diffs (ubuntu-to-common-ancestor, debian-to-common-ancestor, candidate-to-debian, new-upstream-to-old-upstream), nor why I would need to perform any file editing or reconcillation as part of this review. Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: Steve Langasek wrote: On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. This exchange leaves me even further confused about how UDD works, but reviewing merges for new upstream sources has always been a bit fussy, and while interdiffs of diff.gz worked reasonably for format:1.0 packages, there is no useful equivalent for format:3.0 packages. When I'm attempting to review someone else's merge, I generally want them to send me enough information that I can produce their candidate artifacts locally for upload, and generally want to do so in a way that reduces the opportunity for them to submit files that don't match history (either previously in Ubuntu or in Debian). My review tends to consist of looking at the prior Ubuntu-only changes, looking at the upstream changes, looking at any changes beyond the new upstream version from Debian, and ensuring that the resulting artifacts contain the best possible blend of all of these (possibly combined with fixes for other outstanding bugs found in Ubuntu). With a non-UDD workflow, this involves getting the outstanding Ubuntu diff (patches.ubuntu.com or merges.ubuntu.com have them if one doesn't want to download source artifacts and run locally), getting the Debian diff (also available from merges.ubuntu.com), and some artifact diff (which could be that presented for sponsoring, although I tend to generate local artifacts and regenerate the diff). If I want to separate distribution changes and upstream changes, filterdiff can help, or I can run diffs only against contents of debian.tar.gz (or other selected artifacts). With a UDD workflow, this involves getting the candidate branch, reviewing the history to confirm it inherits from preexisting UDD branches, and then using bzr to generate the same set of diffs, for the same level of manual consideration. There are no shortcut pre-generated diffs I can download, but the bzr branch contains everything so there is no need to pull from multiple sources: depending on one's local environment this may be either good or bad in terms of total bandwidth and processing requirements (and one can convince launchpad to generate the diffs, if one is sufficiently motivated and lacks local processing facilities). In either case, once I have a local artifact, unless I'm dealing with a package that is handled by some team that doesn't like it, I can just upload. When I'm dealing with packages where teams want special things done, regardless of which solution I choose above, I need to go fiddle with their special VCS arrangements or get complained at later. Now, it may be that in one of my summaries above, I've mischaracterised one of the workflows, and if so I'd very much like to read an expansion of both procedures by someone who has a very strong preference for one or another workflow based on what they consider to be the user experience. On the other hand, if I've not mischaracterised it, how can *either* the branch or the necessary diff to generate candidate artifacts be useless? While I don't personally see any benefit of one over the other except in terms of access speed to review materials (which depends on sufficient local factors that it isn't likely to be generally applicable), I don't understand how I would have to redo the merge in either case, how I would be able to perform the necessary level of scrutiny of the candidate without reviewing the same set of diffs (ubuntu-to-common-ancestor, debian-to-common-ancestor, candidate-to-debian, new-upstream-to-old-upstream), nor why I would need to perform any file editing or reconcillation as part of this review. Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian - Debian packaging diff, the Ubuntu -- Ubuntu
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
Scott Kitterman wrote: On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian - Debian packaging diff, the Ubuntu -- Ubuntu packaging diff and the Debian old/new -- Ubuntu old/new packaging diffs to ensure no Ubuntu changes have been inadvertently lost, the remaining changes are both needed and documents, and the changes from Debian are correctly applied. i end up needing then the old Debian and Ubuntu packages as well as the new Debian package and the proposed merged. There's probably some reasonable way for me to extract all that from some relevant branches somewhere, but to me it's far easier to use grab-merge and a debdiff. Do the diffs launchpad produces from UDD merge branches not work as an input diff with grab-merge? I've never tried for this specific type of merge, but in cases where it was just a patch being applied to an existing Ubuntu package, I had success pulling diffs from LP to apply. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
On Wednesday, December 19, 2012 02:02:58 PM Emmet Hikory wrote: Scott Kitterman wrote: On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian - Debian packaging diff, the Ubuntu -- Ubuntu packaging diff and the Debian old/new -- Ubuntu old/new packaging diffs to ensure no Ubuntu changes have been inadvertently lost, the remaining changes are both needed and documents, and the changes from Debian are correctly applied. i end up needing then the old Debian and Ubuntu packages as well as the new Debian package and the proposed merged. There's probably some reasonable way for me to extract all that from some relevant branches somewhere, but to me it's far easier to use grab-merge and a debdiff. Do the diffs launchpad produces from UDD merge branches not work as an input diff with grab-merge? I've never tried for this specific type of merge, but in cases where it was just a patch being applied to an existing Ubuntu package, I had success pulling diffs from LP to apply. It's been some time since I tried this, so i don't recall. I don't see how it can beat grab-merge $PACKAGE and an appropriate packaging diff in a bug for simplicity. When I use grab-merge there's everything I need sitting there is a directory ready for me to use. No hunting for diffs or branches needed. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Steve Langasek [2012-12-18 18:40 -0800]: A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. A debdiff between the current Debian and the merged Ubuntu package can be compared directly to the current Ubuntu delta on MoM, and simply calling debdiff against the current version in Ubuntun gives you the U-U debdiff. I find neither operation significantly harder than the two bzr diff commands, and bandwith-wise they are roughly comparable, too. So I disagree that they are useless. What I find useless rather are trivial merges where Ubuntu's delta is just one line in debian/control. Doing the merge yourself vs. sponsoring one take the same time. (They still might be an opportunity to learn for new contributors). But if it's a complex merge and the merge actually went through the effort of cleaning up and upstreaming patches etc., I appreciate them a lot, and the D-U debdiff is the distillation of that work. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Deprecating the wiki-based Packaging Guide
Hi all, As Daniel recently announce, the new Sphinx-based Ubuntu Packaging Guide [0] has recently reached a major milestone. It is now fully translated and available in Spanish. [1] Good progress is currently being made on making it available in other languages as well. [2] Another major milestone is on the horizon. We are about to take the next step in phasing out the old wiki-based packaging guide completely. At UDS-R, it was decided that the new guide has reached a mature enough state to officially deprecate the wiki-based guide. [3] The current plan is to: 1) Send a last-call anouncement to ubuntu-devel requesting bug reports about any missing material. Announce steps 2 and 3 will take place after one month. 2) Move the entire PackagingGuide wiki namespace en masse to PackagingGuideDeprecated. 3) Redirect wiki.ubuntu.com/PackagingGuide to developer.ubuntu.com/packaging/html/ 4) After six months (one full development cycle) PackagingGuideDeprecated will be deleted. This is the mail referred to in step 1. In one month, I will move the entire PackagingGuide wiki namespace enmass to PackagingGuideDeprecated and set up a redirect. If you feel that there are any critical pieces of information that are missing from the Sphinx-based Ubuntu Packaging Guide, now is the time to file bugs (and provide patches). [4] Many thanks to all the contributors who have helped to get the Ubuntu Packaging Guide in such great shape! [0] http://developer.ubuntu.com/packaging/html/ [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-December/000997.html [2] https://translations.launchpad.net/ubuntu-packaging-guide [3] https://blueprints.launchpad.net/ubuntu/+spec/community-r-packaging-guide [4] https://bugs.launchpad.net/ubuntu-packaging-guide/+filebug -- Andrew Starr-Bochicchio Ubuntu Developer https://launchpad.net/~andrewsomething Debian Developer http://qa.debian.org/developer.php?login=asb PGP/GPG Key ID: D53FDCB1 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Am Montag, den 17.12.2012, 16:01 -0500 schrieb Andrew Starr-Bochicchio: 1) Send a last-call anouncement to ubuntu-devel requesting bug reports about any missing material. Announce steps 2 and 3 will take place after one month. 2) Move the entire PackagingGuide wiki namespace en masse to PackagingGuideDeprecated. 3) Redirect wiki.ubuntu.com/PackagingGuide to developer.ubuntu.com/packaging/html/ 4) After six months (one full development cycle) PackagingGuideDeprecated will be deleted. This is the mail referred to in step 1. In one month, I will move the entire PackagingGuide wiki namespace enmass to PackagingGuideDeprecated and set up a redirect. If you feel that there are any critical pieces of information that are missing from the Sphinx-based Ubuntu Packaging Guide, now is the time to file bugs (and provide patches). [4] Will these bugs tracked and fixed before step four? We should only remove the wiki based guide if all missing pieces from it are available in the Sphinx-based packaging guide. -- Benjamin Drung Debian Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Andrew Starr-Bochicchio wrote: On Mon, Dec 17, 2012 at 4:53 PM, Benjamin Drung bdr...@ubuntu.com wrote: Am Montag, den 17.12.2012, 16:01 -0500 schrieb Andrew Starr-Bochicchio: 1) Send a last-call anouncement to ubuntu-devel requesting bug reports about any missing material. Announce steps 2 and 3 will take place after one month. 2) Move the entire PackagingGuide wiki namespace en masse to PackagingGuideDeprecated. 3) Redirect wiki.ubuntu.com/PackagingGuide to developer.ubuntu.com/packaging/html/ 4) After six months (one full development cycle) PackagingGuideDeprecated will be deleted. This is the mail referred to in step 1. In one month, I will move the entire PackagingGuide wiki namespace enmass to PackagingGuideDeprecated and set up a redirect. If you feel that there are any critical pieces of information that are missing from the Sphinx-based Ubuntu Packaging Guide, now is the time to file bugs (and provide patches). [4] Will these bugs tracked and fixed before step four? We should only remove the wiki based guide if all missing pieces from it are available in the Sphinx-based packaging guide. That said, I do think it is important to point out that all missing pieces will never be completely ported to the new guide. A large part of the reason for making the new guide in the first place has been to streamline it, making opinionated decisions of what to include, and eliminate the choose your own adventure style of the old guide. For instance, do we really need to discus desktop files and POD based manpages in the Packaging Guide? While I'm all in favour of a return to a managed (and packagable) packaging guide, I think there is value in being clear that folk who wish to package have a plethora of options available: by all means, let's advocate the latest labour-saving mechanisms, but at the same time, I think we need to avoid anything that implies there is some magic one true way to package. At least in the current text presented at developer.ubuntu.com, the suggestions on packaging new software recommend local compilation, which often hides all sorts of issues, although it significantly reduces the apparent setup required to get involved: I don't believe there is a good answer as to how folk should do this: some may prefer to set things up to match what they think most developers use, and others may just want to get something done. Similarly, we're recommending use of dh-make, and then recommending deleting all the example files that it produces: this is another case where there may be more value in having two paths: one that goes through the dh-make files, and the other that just focuses on changelog, compat, control, copyright, and rules (of which 60% are trivially generated automatically). Different folk learn differently, and as long as we're documenting things that we expect to be used not only for new packaging, but also for patching existing packages, it behooves us to ensure that we have coverage of all the different ways that packages might behave, and some guidance on how to discover when to apply any given rune from some assembled grimoire (assuming it will take some practice for folk to learn the tools well enough to remember how to do things without looking at their notes). Aside from my general belief that as long as we are careful to weave folk back into some central guide after each diversion, choose-your-own-adventure is the right model, I am *completely* certain that we should discuss .desktop files in the Packaging Guide: it's the means by which all XDG-compliant environments present applications to the user (even Unity, without XDG-menus, ends up using an index generated from collected .desktop files to fufill searches), and it's something that is often gotten wrong by upstream developers (because what makes a .desktop file work nicely on one's workstation isn't usually precisely the same as what makes a .desktop file work nicely as part of a distribution). Mind you, that discussion might just be references to the XDG spec, the relevant software centre documentation, and a pointer to the desktop-file-validate utility along with a couple paragraphs explaining why it's important to make it themeable, unique, HIGgy, etc. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Hi Emmet! On Mon, Dec 17, 2012 at 8:11 PM, Emmet Hikory per...@ubuntu.com wrote: Andrew Starr-Bochicchio wrote: On Mon, Dec 17, 2012 at 4:53 PM, Benjamin Drung bdr...@ubuntu.com wrote: Am Montag, den 17.12.2012, 16:01 -0500 schrieb Andrew Starr-Bochicchio: Will these bugs tracked and fixed before step four? We should only remove the wiki based guide if all missing pieces from it are available in the Sphinx-based packaging guide. That said, I do think it is important to point out that all missing pieces will never be completely ported to the new guide. A large part of the reason for making the new guide in the first place has been to streamline it, making opinionated decisions of what to include, and eliminate the choose your own adventure style of the old guide. For instance, do we really need to discus desktop files and POD based manpages in the Packaging Guide? While I'm all in favour of a return to a managed (and packagable) packaging guide, I think there is value in being clear that folk who wish to package have a plethora of options available: by all means, let's advocate the latest labour-saving mechanisms, but at the same time, I think we need to avoid anything that implies there is some magic one true way to package. At There are many acceptable toolchains and approaches to packaging. My understanding of the aim of the new packaging guide [1] is not to suggest that there is one correct way to do things, but to provide a much clearer point of entry than the wiki guide. least in the current text presented at developer.ubuntu.com, the suggestions on packaging new software recommend local compilation, which often hides all sorts of issues, although it significantly reduces the apparent setup required to get involved: I don't believe there is a good answer as to how folk should do this: some may prefer to set things up to match what they think most developers use, and others may just want to get something done. I'd be interested in the exact section you are referring to. Getting Set Up suggests the installation of pbuilder, and Tutorial: Fixing a bug in Ubuntu uses pbuilder-dist to compile. Am I misunderstanding what you mean by local? we're recommending use of dh-make, and then recommending deleting all the example files that it produces: this is another case where there may be more value in having two paths: one that goes through the dh-make files, and the other that just focuses on changelog, compat, control, copyright, and rules (of which 60% are trivially generated automatically). I'm not sure how this differs from the wiki-based guide where you find this, for example [2]: | Running dh_make creates the basic files needed in debian/ and many template | files (.ex) that may be needed. The Hello program is not very complicated, and | as we have seen in the section called “Packaging From Scratch”, packaging it does | not require much more than the basic files. Therefore, let us remove the .ex files: | | cd debian | rm *.ex *.EX The Sphinx-based guide also contains a knowledge base article about files found in the debian directory. I'd be happy to merge a branch that expands on the Additional Files section. [3] differently, and as long as we're documenting things that we expect to be used not only for new packaging, but also for patching existing packages, it behooves us to ensure that we have coverage of all the different ways that packages might behave, and some guidance on how to discover when to apply any given rune from some assembled grimoire (assuming it will take some practice for folk to learn the tools well enough to remember how to do things without looking at their notes). Aside from my general belief that as long as we are careful to weave folk back into some central guide after each diversion, choose-your-own-adventure is the right model, I am *completely* certain that we should discuss .desktop files in the Packaging Guide: it's the means by which all XDG-compliant environments present applications to the user (even Unity, without XDG-menus, ends up using an index generated from collected .desktop files to fufill searches), and it's something that is often gotten wrong by upstream developers (because what makes a .desktop file work nicely on one's workstation isn't usually precisely the same as what makes a .desktop file work nicely as part of a distribution). Mind you, that discussion might just be references to the XDG spec, the relevant software centre documentation, and a pointer to the desktop-file-validate utility along with a couple paragraphs explaining why it's important to make it themeable, unique, HIGgy, etc. Maybe desktop files weren't the best example. While I think it is telling that no one has mentioned the lack of a section on desktop files until I mentioned that I personally don't see the need for it in the packaging guide, I could actually imagine an article that discussed various pieces
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tuesday, December 18, 2012 03:16:13 PM Emmet Hikory wrote: There is definitely a set of tools that are currently the most popular in the Debian archive, and these integrate well with a set of tools being developed under the Ubuntu Distributed Development moniker, which combination may well likely be that which is recommended by the Ubuntu Packaging Guide under development: as such, this recommendation [0] is what ought be followed by the class of developers for whom packaging is a means to an end (as they are often focused on a specific piece of software). For folk who might focus on packaging as an end, preferring the role of distribution developer to that of application developer, there is a need for a greater understanding of the underlying policy and the massive variety of tools by which this policy may be implemented. I think UDD based packaging is a very poor recommendation for this class of packagers for several reasons: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. 2. For developers that have a significant interest in a specific package, we generally recommend that they submit that package to Debian (although it might be accepted to Ubuntu first). Debian doesn't use Ubuntu UDD (in fact the acronym UDD has a completely different meaning in a Debian context). So if developers learn UDD style packaging they have to learn a new set of tools to work with Debian. 3. Ubuntu UDD has sufficient reliability issues that it is not rare for branches to be out of date. As soon as this happens, the new developer then has to get familiar with traditional tools (which are not documented in the packaging guide - last I looked for them anyway). I know UDD is working for some Ubuntu developers, but I don't think it's mature enough to be the first set of tools we give new people to use. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Andrew Starr-Bochicchio wrote: Hi Emmet! Hi! On Mon, Dec 17, 2012 at 8:11 PM, Emmet Hikory per...@ubuntu.com wrote: While I'm all in favour of a return to a managed (and packagable) packaging guide, I think there is value in being clear that folk who wish to package have a plethora of options available: by all means, let's advocate the latest labour-saving mechanisms, but at the same time, I think we need to avoid anything that implies there is some magic one true way to package. At There are many acceptable toolchains and approaches to packaging. My understanding of the aim of the new packaging guide [1] is not to suggest that there is one correct way to do things, but to provide a much clearer point of entry than the wiki guide. Excellent. This is precisely what the old docbook packaging guide did before we moved to the wiki. My apologies for being oversensitive to the idea of streamlining. least in the current text presented at developer.ubuntu.com, the suggestions on packaging new software recommend local compilation, which often hides all sorts of issues, although it significantly reduces the apparent setup required to get involved: I don't believe there is a good answer as to how folk should do this: some may prefer to set things up to match what they think most developers use, and others may just want to get something done. I'd be interested in the exact section you are referring to. Getting Set Up suggests the installation of pbuilder, and Tutorial: Fixing a bug in Ubuntu uses pbuilder-dist to compile. Am I misunderstanding what you mean by local? I was looking at Packaging New Software http://developer.ubuntu.com/packaging/html/packaging-new-software.html The local build in question is `bzr builddeb -- -us -uc` Yes, later it recommends pbuilder and PPAs, etc.: the criticism above was not intended as blanket criticism, but rather a pointer to a possible point of variance between different ways to address the issue. Some folk would regard having performed the local build hard, painful, and bad (especially if the software in question had many build-deps that were unsatisfied locally). Others almost always start with local compilation, considering a build in a structured environment to be part of the test and deployment phase of their work. I don't believe either school of thought is inherently right or wrong, but I do believe that it is important to make clear that folk who have already set up pbuilder (as documented in the Getting Set Up) may alternately do a source-only build and run the binary build in pbuilder (No, it doesn't matter much for hello, but nearly all the cross-platform tools that provide front-ends for a variety of desktop environments can significantly impact the user experience just by having the build-deps installed). we're recommending use of dh-make, and then recommending deleting all the example files that it produces: this is another case where there may be more value in having two paths: one that goes through the dh-make files, and the other that just focuses on changelog, compat, control, copyright, and rules (of which 60% are trivially generated automatically). I'm not sure how this differs from the wiki-based guide where you find this, for example [2]: | Running dh_make creates the basic files needed in debian/ and many template | files (.ex) that may be needed. The Hello program is not very complicated, and | as we have seen in the section called “Packaging From Scratch”, packaging it does | not require much more than the basic files. Therefore, let us remove the .ex files: | | cd debian | rm *.ex *.EX It doesn't differ significantly at all. My point was only that I don't think this represents the best of what we could achieve if we attempt to streamline it, making opinionated decisions of what to include and eliminate 'choose your own adventure' style. Plus, because there are so clearly two different ways to introduce folk to all the various sorts of helper files (generally dh_*, but also some of the older ones), it seemed a good candidate to illustrate the value of multiple possible streams of documentation. The Sphinx-based guide also contains a knowledge base article about files found in the debian directory. I'd be happy to merge a branch that expands on the Additional Files section. [3] Heh. If I had such a branch, I'd be happy to propose it :) For that matter, I think we'd both prefer to review how to improve the current document from the results of a real review, rather than issues cherrypicked for the sake of a (somewhat) unrelated assertion. Aside from my general belief that as long as we are careful to weave folk back into some central guide after each diversion, choose-your-own-adventure is the right model, I am *completely* certain that we should discuss .desktop files in the Packaging Guide: it's the means by
Re: Deprecating the wiki-based Packaging Guide
On 12/17/2012 08:11 PM, Emmet Hikory wrote: Andrew Starr-Bochicchio wrote: On Mon, Dec 17, 2012 at 4:53 PM, Benjamin Drung bdr...@ubuntu.com wrote: Am Montag, den 17.12.2012, 16:01 -0500 schrieb Andrew Starr-Bochicchio: 1) Send a last-call anouncement to ubuntu-devel requesting bug reports about any missing material. Announce steps 2 and 3 will take place after one month. 2) Move the entire PackagingGuide wiki namespace en masse to PackagingGuideDeprecated. 3) Redirect wiki.ubuntu.com/PackagingGuide to developer.ubuntu.com/packaging/html/ 4) After six months (one full development cycle) PackagingGuideDeprecated will be deleted. This is the mail referred to in step 1. In one month, I will move the entire PackagingGuide wiki namespace enmass to PackagingGuideDeprecated and set up a redirect. If you feel that there are any critical pieces of information that are missing from the Sphinx-based Ubuntu Packaging Guide, now is the time to file bugs (and provide patches). [4] Will these bugs tracked and fixed before step four? We should only remove the wiki based guide if all missing pieces from it are available in the Sphinx-based packaging guide. That said, I do think it is important to point out that all missing pieces will never be completely ported to the new guide. A large part of the reason for making the new guide in the first place has been to streamline it, making opinionated decisions of what to include, and eliminate the choose your own adventure style of the old guide. For instance, do we really need to discus desktop files and POD based manpages in the Packaging Guide? While I'm all in favour of a return to a managed (and packagable) packaging guide, I think there is value in being clear that folk who wish to package have a plethora of options available: by all means, let's advocate the latest labour-saving mechanisms, but at the same time, I think we need to avoid anything that implies there is some magic one true way to package. At least in the current text presented at developer.ubuntu.com, the suggestions on packaging new software recommend local compilation, which often hides all sorts of issues, although it significantly reduces the apparent setup required to get involved: I don't believe there is a good answer as to how folk should do this: some may prefer to set things up to match what they think most developers use, and others may just want to get something done. Similarly, we're recommending use of dh-make, and then recommending deleting all the example files that it produces: this is another case where there may be more value in having two paths: one that goes through the dh-make files, and the other that just focuses on changelog, compat, control, copyright, and rules (of which 60% are trivially generated automatically). Different folk learn differently, and as long as we're documenting things that we expect to be used not only for new packaging, but also for patching existing packages, it behooves us to ensure that we have coverage of all the different ways that packages might behave, and some guidance on how to discover when to apply any given rune from some assembled grimoire (assuming it will take some practice for folk to learn the tools well enough to remember how to do things without looking at their notes). I come at this differently. Although we may take packaging seriously, I would say that many devs don't view it as the main event. They are looking for the one true way to package because its a means to an end. If there isn't one or isn't a small number of them, then maybe that's an indication of a deeper problem. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
