Re: Minutes from Developer Membership Board Meeting 2013-01-07
Le 09/01/2013 09:13, Cody A.W. Somerville a écrit : == PerPackageUploader Applications == === Bjoern Michaelsen for libreoffice === LINK: https://wiki.ubuntu.com/BjoernMichaelsen/DeveloperApplication VOTE: For: 2 Against: 1 Undecided: 2 Application was unsuccessful. Hey DMB people, I've been reading the meeting log and I'm slightly worried that the DMB is currently making too hard for contributors to be part of the project. Bjoern has been doing good and hard work on an important package (libreoffice) for over 1.5 years, he got strong endorsement from 3 coredevs and he has been getting in touch with some of the DMB member before applying again (his application got rejected already 6 months or so ago) and yet that's not enough for him to get ppu on the package he's working. The DMB members who didn't want to +1 his applications mentioned those reasons: - "-1, lack of devel release uploads, still problems with with some uploads" - "+0 lack of devel release uploads" - "+0 [I don't like the idea that we should grant PPU just because nobody wants to actually take the time to review this package..." I've asked on IRC and apparently "lack of devel release uploads" is because e.g quantal didn't get SRUs from the current versions. Since when is that a reason to not welcome somebody on board? Especially when the reason for that is "maintaining the current stable is enough for one people full time" ... how is that situation even resolvable, libreoffice is not going to be magically less work to maintain over time? The "nobody wants to actually take the time to review this package" seems misinformed, the wiki has 3 coredevs vouching for Bjoern who have sponsored work for him. I will not speak for pitti and didrocks but I've been reviewing the packages I sponsored, I probably didn't do a perfect job of it is a complex piece of packaging and I'm not familiar with its details. Could the DMB provides feedback on how to unblock that application? Since it's re-election time for part of the DMB soon, it would also be nice to know what the people, who are going to (re)apply for it, think of this situation and if they intend to bring some changes to how the board is running if they get elected Cheers, Sebastien Bacher -- 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
Patch pilot 09-01-2013
Here are the results of my shift: https://bugs.launchpad.net/unity-2d/+bug/1060262 -> done, removed from the queue https://bugs.launchpad.net/ubuntu/+source/unity/+bug/806248 -> given some guidance on the unity process for SRUs (cherry-picking from trunk so that we don't loose branches), unsuscribing the sponsoring team meanwhile. https://bugs.launchpad.net/ubuntu/+source/mozc/+bug/1097593 -> synced https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1095521 -> explained how to deal with patch system, unsuscribing the sponsoring team meanwhile. https://code.launchpad.net/~logan/ubuntu/raring/backuppc/new-merge/+merge/142027 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/cdbs/new-merge/+merge/142028 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/nbd/new-merge/+merge/142030 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/gegl/new-merge/+merge/142029 -> sponsored https://code.launchpad.net/~jelmer/ubuntu/raring/etckeeper/merge-debian/+merge/141431 -> rejected, a similar branch was already pushed https://code.launchpad.net/~fitoschido/ubuntu-manpage-repository/fix-font/+merge/141440 -> set to WIP and give guidance on how to use debchange to create a changelog. https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/1095933 -> synced https://code.launchpad.net/~logan/ubuntu/raring/w3c-dtd-xhtml/debian-merge/+merge/141507 -> added debian git to the repo, asked for cleaning up the branch https://code.launchpad.net/~logan/ubuntu/raring/proxychains/debian-merge/+merge/141479 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/gnome-ppp/debian-merge/+merge/141542 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/webkit2pdf/debian-merge/+merge/141234 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/gst-plugins-good1.0/debian-merge/+merge/141136 -> asked Laney to have a look https://code.launchpad.net/~logan/ubuntu/raring/couchdb/debian-merge/+merge/141235 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/efilinux/debian-merge/+merge/140305 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/poppler/debian-merge/+merge/141139 -> sponsored https://code.launchpad.net/~logan/ubuntu/raring/zfs-fuse/debian-merge/+merge/140320 -> sponsored Cheers, Didier -- 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
