Re: Raring package importer breakage

[Scott Kitterman]

The updated distro-info-data is in quantal-updates.

Scott K

Martin Packman  wrote:

>Currently every[1] package import is failing[2] because the new
>'raring' 
>series is not present in the list of releases obtainted from
>distro-info.
>
>The package importer is using version 0.10 which is the latest in
>quantal[3], 
>so we probably need an updated version of that before any of these
>imports 
>will work. Manually hacking /usr/share/distro-info/ubuntu.csv would do,
>but 
>is exactly the kind of thing we're not meant to mess around with any
>more. 
>Note, there is an old distro-info branch on jubany, but what's actually
>being 
>used is the installed package.
>
>As a related issue, the only people currently subscribed to package
>importer 
>failures in /home/pkg_import/.forward are James Westby and Vincent
>Ladeuil, 
>as the Launchpad maintenance squad nominally has responsibility for
>this now, 
>they really need access to jubany and alerts when things break.
>
>Martin
>
>
>[1] Full list of failing packages, warning, big page currently:
>
>
>[2]: Failures all along the lines of:
>
>   Traceback (most recent call last):
> File ".../bin/import-package", line 5, in 
>   sys.exit(main(sys.argv))
> File ".../udd/scripts/import_package.py", line 1178, in main
>   only_before=options.only_before)
>File ".../udd/scripts/import_package.py", line 1051, in _import_package
>   versions = get_versions(lp, package, extra_debian=extra_debian)
>File ".../udd/scripts/import_package.py", line 257, in get_versions
>   vlist.sort()
> File ".../udd/icommon.py", line 275, in sort
>   self.plist.sort(cmp=PackageToImport.import_order_comparator)
> File ".../udd/icommon.py", line 250, in import_order_comparator
> b_release = import_sequence_distro_releases[b.distro].index(b.release)
>   ValueError: u'raring' is not in list
>
>[3] Versions of distro-info-data in ubuntu:
>


-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: What to do when a packaging branch is out of date

[Scott Kitterman]

On Tuesday, March 20, 2012 10:56:27 AM Andreas Hasenack wrote:
> So apparently a package update can be prepared using udd, released
> into the archive, and the packaging branch still be out of date:
> 
> """
> $ bzr branch
> ubuntu:landscape-client landscape-client-12.04-0ubuntu1
> Most recent Ubuntu version: 12.04-0ubuntu1
> 
> 
> Packaging branch version: 11.07.1.1-0ubuntu2
> Packaging branch status: OUT-OF-DATE
> Branched 40 revisions.
> $
> """
> 
> It's like it was released before being committed.
> 
> What should I do if I want to prepare another fix? Wait? Ping someone
> to commit and then branch again? Do it with debdiffs and not worry
> about branches anymore?
> 
> I emailed ubuntu-devel-discuss and someone told me that somebody has
> to manually commit to the udd branch, and that this is normal.

It's normal for there to be some delay.  It will (normally) be automatically 
updated from what was uploaded.  The only way there isn't some delay is if 
someone manually commits the branch.

I'm not sure how much delay is considered normal these days.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: ubuntu: branches lacking history with upstream branches

[Scott Kitterman]

On Thursday, September 22, 2011 06:42:48 PM Jelmer Vernooij wrote:
> >   This would more closely mirror how
> >
> > packages are managed in Debian.  However, I'd still want
> > `bzr branch ubuntu:gtimelog` to give me the full source.  I wonder if
> > nested branches are the answer here.  One trick would be that I'd only
> > want the source from the upstream branch based on a particular
> > tag.  E.g. I might have unreleased changes in lp:gtimelog, but I want to
> > base ubuntu:gtimelog (and the source package built from it) to work off
> > the 0.7.0 tag or some such.
> 
> The practice of versioning debian/ only mostly seems to happen if the 
> VCS used is SVN. Even then, there are a couple of teams that import the 
> full upstream source into SVN.
> 
> I think I've seen more Git repositories that include the full source 
> than repositories that don't.

For Kubuntu we use /debian only bzr repositories.  No one seems interested in 
going to full source.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: building the package to alter the packaging

[Scott Kitterman]

Jonathan Riddell  wrote:

>In traditional packaging I would often build the package with debuild
>then make some changes based on the compile (edit .install files, add
>.symbols files etc) then check it works with debuild -nc then tidy up
>with debuild -S.
>
>Is there an equivalent in UDD with bzr-builddeb?  If I run bzr
>builddeb it will finish the compile and clean the build tree so I
>don't get a chance to look at the resulting tree.  One messy way is to
>alter the changelog so it doesn't have my e-mail in it then it will
>complain that it can't sign the result and keep the build tree around.
>I can then edit that, use debuild -nc, clean it with debuild -S and
>copy the result back, but it's not very elegant.
>
See https://bugs.launchpad.net/bzr-builddeb/+bug/499684 . What you want, I 
think, is -- -nc

Scott K


-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Package branch freshness

[Scott Kitterman]

On Tuesday, July 19, 2011 10:34:09 pm Martin Pool wrote:
> On 20 July 2011 12:21, Scott Kitterman  wrote:
> > On Tuesday, July 19, 2011 08:00:00 PM Martin Pool wrote:
> >> It would be good to get that rmadison into lptools or ubuntu-dev-tools
> >> - even a moderately hacky state would be useful.
> >> 
> >> In general any feature that might conceivably have bad consequences or
> >> not be what people want probably ought to be behind a configuration
> >> option, and I think this is in that class.
> > 
> > We already have an rmadison in devscripts that supports both Debian and
> > Ubuntu.  Please, if you're going to add another script, call it something
> > else.
> 
> I was imprecise: I meant "that rmadison-like-tool".  If it's
> technically feasible and will not break existing uses perhaps this
> could be merged into rmadison itself, otherwise perhaps it could be
> 'urmadison' or some other name.

Integrated into rmadison as -u lp or something would be reasonable.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Package branch freshness

[Scott Kitterman]

On Tuesday, July 19, 2011 08:00:00 PM Martin Pool wrote:
> It would be good to get that rmadison into lptools or ubuntu-dev-tools
> - even a moderately hacky state would be useful.
> 
> In general any feature that might conceivably have bad consequences or
> not be what people want probably ought to be behind a configuration
> option, and I think this is in that class.

We already have an rmadison in devscripts that supports both Debian and 
Ubuntu.  Please, if you're going to add another script, call it something 
else.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Vcs branches, debcheckout, and UDD

[Scott Kitterman]

On Wednesday, July 06, 2011 04:43:00 PM Barry Warsaw wrote:
> There was a discussion today on #ubuntu-devel about some changes I'd made
> to a few packages for bug 788514 (switch to dh_python2).  gedit is a good
> representative example of the basic issue.
> 
> What I did was to `bzr branch ubuntu:gedit`, then make the changes to that
> branch, `bzr bd -S`, and dput the resulting .dsc file.  All well and good I
> thought, but actually this caused some trouble because gedit has a Vcs-Bzr
> branch:
> 
> $ debcheckout -p gedit
> bzr   https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu
> 
> which is *not* the UDD branch, even if we substitute bzr+ssh for http.
> 
> I just spent an hour manually copying the diff from several UDD branches to
> their Vcs branches, because 1) I'd already uploaded the change, and 2) the
> branches share no history so you can't merge between them.
> 
> I think this is somewhat related to the native package discussion we've had
> w.r.t. software-center, but it's also somewhat different.  Or maybe not:
> 
> $ debcheckout -p software-center
> bzr   https://code.launchpad.net/~software-store-developers/software-
center/t
> runk
> 
> A couple of things bother me here:
> 
> * We shouldn't be suggesting to people to use the UDD branch if the Vcs
> branch is preferred.
> * We probably don't want to suggest that any Vcs branch, or even any
> Vcs-Bzr branch should automatically use the Vcs branch instead of the UDD
> branch, since Debian packages can specify either, and for those, the UDD
> branch would still be appropriate.
> * Should debcheckout be taught about UDD branches and rules, or should bzr
> be taught about Vcs-Bzr branches?
> * Using an unmodified Vcs-Bzr url isn't ideal, since we'd almost always
> prefer the bzr+ssh version (i.e. `debcheckout -a`) over the https version.
> * tumbleweed, seb128 and others suggested some mungification of Vcs-* into
> an XS-$Vendor-Vcs-* field, possibly by update-maintainer, but I don't grok
> all the details of what that would mean.
> * I can see how `debcheckout` is pretty useful, but I don't much like it
>   better than normal UDD workflows.
> * There's no foolproof rule to know when to use the Vcs branch over the UDD
>   branch.
> 
> Maybe, a heuristic would be, look for a Vcs-Bzr header matched with a
> -0ubuntuX version number and/or "ubuntu" in the branch url.  In those cases
> maybe `bzr branch ubuntu:foo` would complain, or just do the moral
> equivalent of `debcheckout -a foo`.
> 
> Or maybe, what we've talked about for software-center applies here.  E.g.
> ask Launchpad to essentially make the UDD branch and the Vcs-Bzr branch
> one and the same, so either approach will work.  This seems trickier since
> the UDD branch has the full source code, while the Vcs-Bzr branch has only
> the debian/ directory (and apt-gets the source).
> 
> You guys are way smarter about this stuff than me, so I hope you'll have
> some awesome suggestions. :) Even if it's not solvable right now, I think
> it's important to get it on the UDD radar since debcheckout is how a lot
> of folks work, and I'd like to save future developers the wasted effort of
> changing the wrong branch.

One of the big questions I don't see addressed is packaging versus full source 
branches.  In Kubuntu (and I'm pretty sure Ubuntu Desktop) we use packaging 
branches that only have the debian dir in them.  We've discussed this and 
there wasn't a lot of interest in switching to full source branches.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

"Ubuntu Packaging Guide"

[Scott Kitterman]

I just took my first look at the so called Ubuntu Packaging Guide and it's 
clear that a lot of work has gone into developing a useful guide for new 
contributors.  It does concern me that the name "Ubuntu Packaging Guide" is 
really misleading.

If you look at http://people.canonical.com/~dholbach/packaging-guide you'll 
find no mention of the 'normal' tools and processes that I (and I believe most) 
Ubuntu developers use.  This is not really an Ubuntu Packaging Guide.  It's 
really Ubuntu Packaging using UDD tools.

I do not believe that this toolset is mature enough for general use and it's a 
mistake to present this to potential new developers as "the" way Ubuntu does 
things.  If this document is going to be presented as an Ubuntu Packaging 
Guide the primary focus ought to be on normal packaging tools.  Alternately, 
the guide ought to be renamed to reflect it's focus.

Just to pick one example, as soon as you want to work on a package with an out 
of date branch, you need to move from the UDD toolset.  

I've filed a bug to track this:

https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/792381

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Breaking up the importer's huge icommon.py file

[Scott Kitterman]

Max Bowsher <_...@maxb.eu> wrote:

>> Max Bowsher wrote:
>>> "package_importer" is a bit long. "udd" works for me, especially as
>the
>>> project lives in lp:udd.
>
>On 23/05/11 12:19, Scott Kitterman wrote:
>> The term udd is, unfortunately, overloaded. It's also 'Ultimate
>> Debian Database'. I suggest something that avoids that. Maybe
>> ubuntudd or uddev?
>
>The conflict is unfortunate. The importer's Launchpad project ID is
>udd,
>though. Given these Python modules are not going to be packaged or even
>used other than by files in the same tree, renaming them at a later
>date
>is trivial - therefore, I am in favour of matching the Python module
>name to the Launchpad project ID - and if we change both of them at the
>same time at some later date, that's fine.
>
To the extent Launchpad is the world, I think that's fine.

Scott K-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Breaking up the importer's huge icommon.py file

[Scott Kitterman]

Max Bowsher <_...@maxb.eu> wrote:

>On 23/05/11 07:42, Andrew Bennetts wrote:
>> Max Bowsher wrote:
>>> A huge amount of the UDD importer's interesting code is in one file,
>>> icommon.py.
>>>
>>> I'd like to submit a series of changes to break it up such that only
>the
>>> most common bits of code remain there.
>> 
>> This all sounds pretty reasonable to me.
>> 
>> However I don't much care for the “ifoo” module naming convention.  I
>> assume the “i” stands for “importer” but it always makes me think
>> “interface” first.  
>> 
>> If we want a namespace for these modules (and I think we do;
>namespaces
>> are a good idea[1]) then let's do that the standard Python way: with
>a
>> package.  Because I'm uncreative with names I suggest calling it
>> “package_importer”, or perhaps “udd”.  So rather than “idatabase” I
>> propose “package_importer.database”.  What do you think?
>> 
>> This would have the advantage of keeping the directory of scripts
>that
>> are interesting for a person to run mostly separate from the
>libraries
>> used to implement them.  At the moment they're jumbled together.
>> 
>> -Andrew.
>> 
>> [1] Actually, not just good, honking great: python -c 'import this'
>
>"package_importer" is a bit long. "udd" works for me, especially as the
>project lives in lp:udd.

The term udd is, unfortunately, overloaded. It's also 'Ultimate Debian 
Database'. I suggest something that avoids that. Maybe ubuntudd or uddev?

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: UDD with new upstream version

[Scott Kitterman]

On Friday, April 15, 2011 12:44:04 AM Micah Gersten wrote:
> On 04/14/2011 02:00 PM, Scott Kitterman wrote:
> > I decided to try UDD again for a new upstream version that was just
> > released.
> > 
> > I was following the documentation here:
> > 
> > https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamV
> > ersion
> > 
> > I got to this step:
> > 
> > bzr merge-upstream --version 1.2
> > http://example.org/releases/foo-1.2.tar.gz
> > 
> > and after considering this would require me to look up the exact download
> > address on sourceforge, decided to back up and do:
> > 
> > apt-get source opendkim
> > cd opendkim-2.3.1
> > uscan
> > 
> > instead.
> > 
> > I don't know if this is a documentation shortfall or it's really that
> > much more complicated, but documenting/updating so this works easily
> > with watch files would be a big win.
> > 
> > Scott K
> 
> Why can't you just run uscan on the bzr branch?
> 
> Micah

I probably could, but I'm not so experience with UDD stuff I'm going to diverge 
from the documentation.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: UDD with new upstream version

[Scott Kitterman]

On Thursday, April 14, 2011 03:16:14 PM Jelmer Vernooij wrote:
> On Thu, 2011-04-14 at 15:00 -0400, Scott Kitterman wrote:
> > I decided to try UDD again for a new upstream version that was just
> > released.
> > 
> > I was following the documentation here:
> > 
> > https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamV
> > ersion
> > 
> > I got to this step:
> > 
> > bzr merge-upstream --version 1.2
> > http://example.org/releases/foo-1.2.tar.gz
> > 
> > and after considering this would require me to look up the exact download
> > address on sourceforge, decided to back up and do:
> > 
> > apt-get source opendkim
> > cd opendkim-2.3.1
> > uscan
> > 
> > instead.
> > 
> > I don't know if this is a documentation shortfall or it's really that
> > much more complicated, but documenting/updating so this works easily
> > with watch files would be a big win.
> 
> the bzr-builddeb in natty can use the watch file. If you have a watch
> file it will use the watch file to download the upstream release.
> 
> The --version argument is also optional if you have a watch file; it
> will default to the latest upstream version.

That sounds good.  Could you update the wiki page then so it's documented?

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: UDD with new upstream version

[Scott Kitterman]

On Thursday, April 14, 2011 03:00:23 PM Scott Kitterman wrote:
> I decided to try UDD again for a new upstream version that was just
> released.
> 
> I was following the documentation here:
> 
> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamVer
> sion
> 
> I got to this step:
> 
> bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz
> 
> and after considering this would require me to look up the exact download
> address on sourceforge, decided to back up and do:
> 
> apt-get source opendkim
> cd opendkim-2.3.1
> uscan
> 
> instead.
> 
> I don't know if this is a documentation shortfall or it's really that much
> more complicated, but documenting/updating so this works easily with watch
> files would be a big win.
> 
> Scott K

In fairness, it turned out the watch file didn't work because I guess 
sourceforge changed their file layout again, but it generally does, so the 
point still stands.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

UDD with new upstream version

[Scott Kitterman]

I decided to try UDD again for a new upstream version that was just released.

I was following the documentation here:

https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamVersion

I got to this step:

bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz

and after considering this would require me to look up the exact download 
address on sourceforge, decided to back up and do:

apt-get source opendkim
cd opendkim-2.3.1
uscan

instead.

I don't know if this is a documentation shortfall or it's really that much 
more complicated, but documenting/updating so this works easily with watch 
files would be a big win.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Summary from UDD meeting 2011-03-23

[Scott Kitterman]

On Friday, March 25, 2011 04:10:06 pm Robert Collins wrote:
> On Sat, Mar 26, 2011 at 9:00 AM, Barry Warsaw  wrote:
> > I do agree with Scott that import reliability is really critical to
> > adoption. You can't use UDD if the branch is out of date!  BFBIP seems
> > like a step after getting wide adoption of 'bzr branch' instead of
> > 'apt-get source'.
> 
> They seem pretty complementary to me: I mean, if you can push(*) to
> build, thats removes a manual step from the pipeline : its a pretty
> significant change.
> 
> We have in the past fallen into a trap of aiming for 100% in each step
> *before* we move onto the next one. That means we're well past the
> point of getting a net benefit (think 80-20 rule) by the time we start
> moving on. These import problems have a viciously long tail : isn't it
> better to be making things a lot better *most* of the time?
> 
> I acknowledge the psychological impact of 'if it doesn't work always
> its hard to remember' - but we're already well past the common working
> set of any one developer, and Martin isn't suggesting that imports be
> abandoned, just that closing the loop is *as* important as improving
> the import story.
> 
> -Rob
> 
> (*) By which I mean some command that generates a validator, signs it,
> does $whatever with it.

I'd add that I don't see build from branch is the killer feature that will 
make this all take off.  My recollection from when I've used UDD is that 
things took longer, felt awkward, and had extra steps in comparison to apt-get 
source, dpkg-buildpackage, dput.  Build from branch helps that a bit, but it 
doesn't really fundamentally change the 'is it ready for me' equation.

My view of the 80/20 rule on UDD is that getting at least per-upload 
granularity revision data into a $VCS so we have sufficient data for post-
mortum autopsies and just trying to figure out when and maybe why things were 
done hits at least the 80% mark on the long term value of UDD (I recognize 
that full time developers who regularly touch the same source packages will 
likely have a different assessment of where the value proposition lies in 
UDD).  This may be part of why I consider import reliabilty more important 
than new functionality.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Summary from UDD meeting 2011-03-23

[Scott Kitterman]

On Thursday, March 24, 2011 09:50:26 pm Martin Pool wrote:
> On 25 March 2011 01:44, Francis J. Lacoste
> 
>  wrote:
> > On March 23, 2011, Barry Warsaw wrote:
> >> * The build-from-branch-into-primary LEP is awaiting assignment to an LP
> >> squad for implementation.  Martin and Francis are hopeful that it will
> >> be scheduled and live by UDS-O.
> > 
> > Actually, that doesn't look so rosy anymore. Initial reviews found that
> > finishing subscriptions and derived distros will take longer than
> > initially thought. And we also have push back from some stakeholders on
> > making this item jump the queue.
> > 
> > Today, it looks very unlikely that a Launchpad squad could be assigned to
> > this and finish it before UDS-O :-/
> 
> Software taking longer than expected!  :)
> 
> So it seems like our choices now are: wait until it gets to the front
> of the Launchpad queue, which may be a very long time, or do it in the
> Bazaar team.
> 
> Doing it in Bazaar will reduce the rate at which we do general Bazaar
> work, and the rate at which we can fix package-importer failures.  But
> it doesn't look impossibly big, and if we get reasonable help from
> Launchpad developers during development and landing we can probably do
> it.
> 
> I'd like to see it happen.  How do UDD community members feel about
> this vs bug fixing and import reliability?

I'm not sure what bugs this would be traded off for, but I think import 
reliability is paramount for broader acceptance of UDD.  Unless people are 
confident enough the branch will be current not to worry about double 
checking, the need to double check things are up to date will be  a barrier to 
adoption.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: rfc: permissions on package branches

[Scott Kitterman]

On Tuesday, February 15, 2011 12:34:28 am Martin Pool wrote:
> We have a question in  about
> what the permissions on official package branches ought to be, and how
> they should be explained to the user.
> 
> The basic thing is that Launchpad knows who is allowed to write to a
> package, and it already has special code that gives those people
> read/write access to the package branch.  In the common case where the
> package branch is owned by a bot/celebrity that will never do anything
> itself, this is fine.  However, it is perhaps a problem if an existing
> branch owned by a human is marked as official for a particular
> package.
> 
> At the moment the permissions are unioned: the nominal owner of the
> branch keeps write access, and the package uploaders get right access
> too.
> 
> There are a few options here and we'd appreciate hearing from Ubuntu
> people how they think it should work:
> 
> 0- No change: the nominal owner keeps write access.
> 
> 1- Don't allow branches owned by non-celebrities to become the
> official branch for a package.  Instead, you need to push from that
> branch into the real official branch.
> 
> 2- When the branch becomes an official package branch, the owner loses
> write access (unless they're also an uploader.)  That's what
>  ranch-516709/+merge/29446> would do.  It seems potentially confusing.
> 
> 3- Something else?
> 
> Let us know what you think either here or on that bug.  Also if you
> think we ought to ask eg the TB, please tell me.

Now that I know what a celebrity is in this context, I think #2 is reasonable.  
#1 would be achieved by not turning a particular branch into a packaging 
branch and using the default official branch (we have that now).

Official Ubuntu branches are supposed, in some way, to relate to the code in 
the distro, so I think it makes sense to keep the upload and branch 
permissions aligned.  If someone doesn't like losing write permissions to a 
branch for a package they can't upload, then they shouldn't have it made the 
official branch.

It doesn't seem confusing to me, but then maybe I don't understand it well 
enough to be confused.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: rfc: permissions on package branches

[Scott Kitterman]

On Thursday, February 17, 2011 07:19:29 pm Martin Pool wrote:
> On 18 February 2011 10:43, Scott Kitterman  wrote:
> > On Thursday, February 17, 2011 06:33:35 pm John Arbash Meinel wrote:
> >> On 2/17/2011 4:59 PM, Scott Kitterman wrote:
> >> > On Thursday, February 17, 2011 05:20:07 pm John Arbash Meinel wrote:
> >> >> On 2/14/2011 11:34 PM, Martin Pool wrote:
> >> >>> We have a question in <https://bugs.launchpad.net/bugs/516709> about
> >> >>> what the permissions on official package branches ought to be, and
> >> >>> how they should be explained to the user.
> >> >> 
> >> >> Obviously people feel very passionate about this subject, given the
> >> >> intense discussion. 
> >> > 
> >> > So far I asked what a "celebrity" is in this context and no one
> >> > answered.
> >> 
> >> Hmmm. I don't see your other message.
> >> 
> >> As I understand it, things like ~ubuntu-branches. But I could be wrong.
> > 
> > I don't understand it either, that's why I ask.  In the original message
> > option 1 started, "Don't allow branches owned by non-celebrities to
> > become the official branch for a package."  Without knowing what a
> > celebrity is in this context it's a bit difficult to commenton the
> > proposal.
> 
> As jml said, it's a user specially known to the Launchpad codebase.
> For instance, ~admins is in that category because they have some
> permissions that you cannot obtain other than by becoming a member of
> that team.
> 
> In this case, it would be that Launchpad would have some code to say
> ~ubuntu-branches or similar must be the only owner of official package
> branches.  (Or perhaps it's not even strictly necessary to make it
> exactly a celebrity, as long as there are other limits on changing
> official branches.)
> 
> Anyhow, the gist of it would be that it would still have a nominal
> owner, but an owner that no human can access.  The only access would
> be through Ubuntu package access control rules.

Thanks,

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: rfc: permissions on package branches

[Scott Kitterman]

On Thursday, February 17, 2011 06:33:35 pm John Arbash Meinel wrote:
> On 2/17/2011 4:59 PM, Scott Kitterman wrote:
> > On Thursday, February 17, 2011 05:20:07 pm John Arbash Meinel wrote:
> >> On 2/14/2011 11:34 PM, Martin Pool wrote:
> >>> We have a question in <https://bugs.launchpad.net/bugs/516709> about
> >>> what the permissions on official package branches ought to be, and how
> >>> they should be explained to the user.
> >> 
> >> Obviously people feel very passionate about this subject, given the
> >> intense discussion. 
> > 
> > So far I asked what a "celebrity" is in this context and no one answered.
> 
> Hmmm. I don't see your other message.
> 
> As I understand it, things like ~ubuntu-branches. But I could be wrong.
> 
I don't understand it either, that's why I ask.  In the original message 
option 1 started, "Don't allow branches owned by non-celebrities to become the
official branch for a package."  Without knowing what a celebrity is in this 
context it's a bit difficult to commenton the proposal.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: rfc: permissions on package branches

[Scott Kitterman]

On Thursday, February 17, 2011 05:20:07 pm John Arbash Meinel wrote:
> On 2/14/2011 11:34 PM, Martin Pool wrote:
> > We have a question in  about
> > what the permissions on official package branches ought to be, and how
> > they should be explained to the user.
> 
> Obviously people feel very passionate about this subject, given the
> intense discussion. 

So far I asked what a "celebrity" is in this context and no one answered.

> > The basic thing is that Launchpad knows who is allowed to write to a
> > package, and it already has special code that gives those people
> > read/write access to the package branch.  In the common case where the
> > package branch is owned by a bot/celebrity that will never do anything
> > itself, this is fine.  However, it is perhaps a problem if an existing
> > branch owned by a human is marked as official for a particular
> > package.
> 
> So that means that if I have upload rights to 'bzr', then I can push to
> lp:ubuntu/natty/bzr regardless of who the actual owner is?
> 
> > At the moment the permissions are unioned: the nominal owner of the
> > branch keeps write access, and the package uploaders get right access
> > too.
> > 
> > There are a few options here and we'd appreciate hearing from Ubuntu
> > people how they think it should work:
> > 
> > 0- No change: the nominal owner keeps write access.
> > 
> > 1- Don't allow branches owned by non-celebrities to become the
> > official branch for a package.  Instead, you need to push from that
> > branch into the real official branch.
> 
> I'm in favor of this one myself. ~ubuntu-foo can own all of the official
> packaging branches, and the users have rights to upload to the
> appropriate branches.
> 
> > 2- When the branch becomes an official package branch, the owner loses
> > write access (unless they're also an uploader.)  That's what
> >  > -branch-516709/+merge/29446> would do.  It seems potentially confusing.
> > 
> > 3- Something else?
> > 
> > Let us know what you think either here or on that bug.  Also if you
> > think we ought to ask eg the TB, please tell me.
> > 
> > Martin
> 
> John
> =:->

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Fw: [ubuntu/natty] pythonmagick 0.9.1-3ubuntu5 (Accepted)

[Scott Kitterman]

"Michael Bienia"  wrote:

>On 2010-12-11 09:24:37 -0500, Barry Warsaw wrote:
>> So, I actually find these notifications less helpful than they could
>be.  I'm
>> used to being on various "-checkins" mailing lists where every change
>to a
>> tree is included in the notification in unidiff format.  This is a
>great, low
>> impact way, to monitor what's happening to code you care about.  It's
>also a
>> cheap way to propagate post-commit review of changes.  It's not
>uncommon for
>> example to see a Python commit be questioned and adjusted after the
>fact
>> (that's why we have a vcs, right? :).
>> 
>> I would love to see the same thing in these -changes notifications.
>
>I could live with a link to the generated LP diff or a link to the
>commit in the packaging branch for easier access but please don't
>include the whole diff in the -changes mail as I prefer to have them
>small.
>For an ubuntuX → ubuntuX+1 upload the diff will most likely be only a
>few kB but for an upload of a new upstream version the diff can be
>several hundred kB or even some MB. I don't want to have such huge
>diffs
>attached to the -changes email as I certainly won't read such big diffs
>(and especially won't read diffs of generated files like configure or
>updates of line numbers in translation templates).
>
I'd go a bit further and suggest that while interesting, what's proposed here 
is a different thing than the current changes mail.  I don't think sending 
diffs to -changes would be well received, but I think a new list with (maybe 
just packaging) diffs would be a great idea.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: [braindump] ppa update discontents

[Scott Kitterman]

On Friday, August 20, 2010 04:47:11 am Martin Pool wrote:
> It can be a bit hard to work out which packaging branch is used for
> the version in our ppa.  Launchpad has a concept of series branches
> for We can have a convention for plugins that we package, but it's
> just a convention and because it's evolved over time it's not always
> consistent.  For instance if Gary has uploaded bzr-gtk -
> 0.99.0-1~hardy4 but it's failing, I can get the source for that
> package and try to fix it, but I can't easily work out what branch
> contains that source.  (Well, I can guess it's one of the recently
> updated branches in  but it's
> not great.)

I have to deal with some similar problems with the 
https://launchpad.net/~ubuntu-clamav/+archive/ppa - it's relatively empty at 
the moment, but when testing, we provide clamav (and often it's rdepends) all 
the way back to Dapper.

I have a non-UDD workflow that seems like it is worth sharing because if UDD 
could make this easier, it would be a motivator for me to use it.

When I start to backport, I:

grab the source package from the development release (maverick in this 
example)
add a new ~lucid1~ppa1 debian/changelog entry
debuild -S
cd ../
dput clamav-ppa clamav_0.96.1+dfsg-3ubuntu5~lucid1~ppa1_source.changes

Then start the next one.

cd clamav-0.96.1+dfsg
edit debian/changelog to ~karmic1~ppa1
debuild -S
cd ../
dput clamav-ppa clamav_0.96.1+dfsg-3ubuntu5~karmic1~ppa1_source.changes

Then move on to the next.

Jaunty needs a small change in debian/control, so I repeat the above process 
with the addition of changing debian/control and documenting this in the 
changelog.

Hardy gets interesting as there are more changes in debian/control needed as 
well as maintainer script adjustments.  I follow the above process, but I also 
have a patch of the non-changelog diff for Hardy that I apply using patch and a 
standard Hardy changelog entry that I add documenting the changes.  The first 
hunk of the patch for debian/control always fails, so I do that manually.
Then I follow the process and upload.

Dapper is yet another layer of fun for which I have another patch for 
Hardy/Dapper changes and a standard debian/changelog entry.

Eventually, all those build and I (if needed) do the rdepends updates).

Sometimes there are release specific problems that I need to go back and 
address.  To do this, I:

cd to the top of my clamav packaging directory
rm -rf clamav-0.96.1+dfsg (the unpacked source package)
dpkg-source -x clamav_0.96.1+dfsg-3ubuntu5~hardy1~ppa1.dsc (unpack the exact 
version I want)
make additional changes
increment the version in debian/changelog to ~ppa2
debuild -S
cd ../
dput clamav-ppa clamav_0.96.1+dfsg-3ubuntu5~hardy1~ppa2_source.changes

I'm sure it's reasonably clear that this a lot like switching branches, just 
with no VCS in the picture.

If there was a really logical way to keep track of which branch I wanted and 
switch between them intuitively as well as to easily integrate the per-release 
packaging diff when I move to a new version to base the backporting work on, 
then it would be really useful to me as the current method is not precisely 
pain free.

So here's another example use case for you 

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: [braindump] ppa update discontents

[Scott Kitterman]

On Friday, August 20, 2010 04:47:11 am Martin Pool wrote:
> Maverick's bzr has its copy of python-configobj cut out, but that
> library is not shipped on hardy.  Dealing with things like this make
> me wonder a lot whether it's a good use of time to keep supporting
> many old platforms.

A non-UDD solution to this particular problem is to ask to have the package 
backported and then use backports in the PPA.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Growth of Ubuntu Distributed Development

[Scott Kitterman]

On Tuesday, July 20, 2010 06:50:23 am Martin Pool wrote:
> On 20 July 2010 00:09, Scott Kitterman  wrote:
> > On Monday, July 19, 2010 05:59:22 pm Francis J. Lacoste wrote:
> > 
> > It's not apparent to me that enough has changed since I wrote this:
> > 
> > https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-
> > January/000373.html
> > 
> > to warrant giving it another try.
> 
> Fair enough, there are some things that are not fixed there.  Some are
> fixed:
> 
>  * changelogs should now autoresolve conflicts:
> <https://bugs.edge.launchpad.net/bzr-builddeb/+bug/516060> and
> friends, but perhaps more can be done
>  * needing to bzr commit as well as editing the changelog: you can
> either use 'debcommit' or bzr will use the changes to the
> debian/changelog as the suggested message
> <https://bugs.edge.launchpad.net/bugs/331993>; this might need to be
> better documented
>  * merge-upstream should automatically populate debian/changelog with
> "new upstream" etc
> <https://bugs.edge.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/296516>
> 
> Some still need to be done:
> 
>  * https://bugs.edge.launchpad.net/bzr-builddeb/+bug/607682 - better
> workflow for getting all the relevant branches
>  * https://bugs.edge.launchpad.net/bzr-builddeb/+bug/607684 - single
> command to push and upload
> 
> Both require some design work.
> 
> You also had the issue that the documentation needs to be better,
> which is probably still true but not a very good bug to file.
> 
> I believe Barry also has a bunch of UDD bugs to file, including about
> giving warnings when things are out of date.

Specifically for merging, I think an equivalent of grab-merge (I'll go so far 
as to suggest implementing something in grab-merge and then people can grab-
merge --bzr or something) and an easy way to diff just the non-upstream changes 
are essential to broader adoption.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Growth of Ubuntu Distributed Development

[Scott Kitterman]

On Tuesday, July 20, 2010 05:07:11 am Barry Warsaw wrote:
> On Jul 19, 2010, at 05:59 PM, Francis J. Lacoste wrote:
> >My theory is that usage is increasing but among a core group of
> >people. So a few more people try it out, but haven't persisted in
> >making the switch. But the ~15-25 people how are really using it are
> >using it more.
> >
> >Does that seem consistent with your views of the current usage? What
> >is blocking more users from jumping on the UDD bandwagon?
> 
> I'm trying to use UDD as much as possible, so here are my thoughts.
> 
> For someone like Scott, who is a very experienced and knowledgeable
> developer, UDD might be promising but isn't yet compelling enough to
> replace the tools and processes they've built up over the years.  I don't
> want to put words in his mouth, but I suspect that UDD seems like just
> another of the many options for doing packaging.

For me the major benefit of UDD is the finer grained history when I'm trying to 
understand when a change was introduced (and maybe why).  Fortunately, I can 
get that without every using UDD, since tracing changes down to a particular 
upload to the archive has, as far as I can recall, always been sufficient.

Currently, I see a lot of negatives to using the UDD tool set (as described in 
my January message) that cause me not to bother.  I'm glad to see some 
progress has been made, but, for example, until merging is easier/faster with 
UDD than MoM, I'm unlikely to make much use of it.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Growth of Ubuntu Distributed Development

[Scott Kitterman]

On Monday, July 19, 2010 05:59:22 pm Francis J. Lacoste wrote:
> Hi,
> 
> I'm interested in getting an understanding whether the usage of UDD is
> growing or not.
> 
> According to the stats I get from LP usage, we are seeing more and more
> package branches being created, but not necessarily many more people using
> it.
> 
> Reviewing the last four months, specifically we went from
> 
> ~600 to ~900 package branches (non-official)
> ~100 to ~150 registrants
> ~300 to ~500 source packages with branches
> 
> So roughly a 50% increase across all dimensions.
> 
> But the average number of people registering new branches within the last
> month is kind of stable at ~40 evenly split between Canonical and non-
> Canonical folks.
> 
> My theory is that usage is increasing but among a core group of people. So
> a few more people try it out, but haven't persisted in making the switch.
> But the ~15-25 people how are really using it are using it more.
> 
> Does that seem consistent with your views of the current usage? What is
> blocking more users from jumping on the UDD bandwagon?
> 
> Let me know your thoughts.

It's not apparent to me that enough has changed since I wrote this:

https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-
January/000373.html

to warrant giving it another try.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Feedback on merging via bzr

[Scott Kitterman]

> On 28 January 2010 12:04, Scott Kitterman  wrote:
>>> On 28 January 2010 06:14, Reinhard Tartler  wrote:
>> ...
>>>> Â - download the orig.tar.gz/orig.tar.bz2 files from debian
>>>>
>>>
>>> The branches are pristine-tar enabled you can just
>>> "$ bzr bd" them and a tarball will appear in your tarball's directory.
>>
>> Right, but which tarball? Â It's not always obvious. Â It's important
>> that
>> we md5sum match Debian [1]. Â In cases where we don't we end up having
>> to
>> do fake syncs once the differences between Debian and Ubuntu are
>> resolved.
>>
>
> Well just pick your favorite package branch and inspect it with $bzr
> visualise or the kde equivalent. The import is quite good.
>
> Original tarballs are taken from debian and are imported using
> pristine-tar into the "upstream" branch nick. Then the debian
> packaging is done on the "debian" branch nick which has upstream as
> ancestor and then the ubuntu is another branch nick which is diverging
> from the "debian" one again.
>
> So from the resulting lp:ubuntu/package you can branch off any
> upstream release, debian or ubuntu package release. And each revision
> has the corresponding pristine-tarball delta, such that all tarballs
> can be regenerated with identical checksums as in the debian archive.
>
> So the branch import has been engineered really well in this respect
> and we should not have fake syncs anymore.
>
> This even scales to when the branches will get rebased ontop of the
> upstream releases, cause the pristine-tarball delta will be committed
> into a new branch nick based off upstream branch adding all the
> Makefile.in's and etc with the tarball delta.
>
> Can't remember either Karmic or Jaunty UDS had a video on this UDD
> master plan with all the explanations.

Then maybe the description of what is happening just needs to be improved
because as I said in the bug, it sure appears to be looking upstream and
getting the tarball from there before it checks Debian.  I understand the
theory, it isn't clear to me that's what's happening.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Feedback on merging via bzr

[Scott Kitterman]

> On 28 January 2010 06:14, Reinhard Tartler  wrote:
...
>> Â - download the orig.tar.gz/orig.tar.bz2 files from debian
>>
>
> The branches are pristine-tar enabled you can just
> "$ bzr bd" them and a tarball will appear in your tarball's directory.

Right, but which tarball?  It's not always obvious.  It's important that
we md5sum match Debian [1].  In cases where we don't we end up having to
do fake syncs once the differences between Debian and Ubuntu are resolved.

Scott K

[1] https://bugs.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/510312

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Feedback on merging via bzr

[Scott Kitterman]

> 

So then you get to read the reply twice.  ;-)
>
> -- Forwarded message --
> From: Dmitrijs Ledkovs 
> Date: 2010/1/18
> Subject: Re: Feedback on merging via bzr
> To: Scott Kitterman 
>
>
> 2010/1/18 Scott Kitterman :
>>> Ubuntu patch compared to the common base version:
>>>
>>> ~/src/pkg-name/lucid/ $ bzr diff -rancestor:../squeeze/
>>>
>>> Debian patch compared to the common base version:
>>>
>>> ~/src/pkg-name/squeeze/ $ bzr diff -rancestor:../lucid/
>>>
>>> These two commands should generate the equivalent of the .patch files
>>> from
>>> MoM.
>>>
>> That doesn't solve the issue with the data being local versus remote,
>> but
>> it definitely looks very helpful. Â Would you add that to the wiki page
>> on
>> merging?
>>
>> Scott K
>>
>
> What do you mean? These commands _do not_ require access to remote
> branches at all! It's all local no trips to launchpad.

I'd missed that he was working from local checkouts when I read the message.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Feedback on merging via bzr

[Scott Kitterman]

> On Mon, Jan 18, 2010 at 12:21 PM, Scott Kitterman 
> wrote:
>>>
>>> I usually use the ancestor revision shortcut for selecting the revision
>>> to
>>> diff:
>>>
>>> Ubuntu patch compared to the common base version:
>>>
>>> ~/src/pkg-name/lucid/ $ bzr diff -rancestor:../squeeze/
>>>
>>> Debian patch compared to the common base version:
>>>
>>> ~/src/pkg-name/squeeze/ $ bzr diff -rancestor:../lucid/
>>>
>>> These two commands should generate the equivalent of the .patch files
>>> from
>>> MoM.
>>>
>> That doesn't solve the issue with the data being local versus remote,
>> but
>> it definitely looks very helpful.
>
> As mentioned earlier in the thread, it makes sense to always work from
> local branches with a local repository:
>
>  1. Create a local repository:
> ~/src/$ bzr init-repo src-pkg-name
>  2. Checkout latest Ubuntu version:
> ~/src/pkg-name/$ bzr co lp:ubuntu/pkg-name/ lucid
>  3. Checkout latest Debian version:
> ~/src/pkg-name/$ bzr co lp:debian/pkg-name/ squeeze
>  4. Create a local branch to work on the merge:
> ~/src/pkg-name/$ bzr branch lucid l-merge
>
>> Would you add that to the wiki page on merging?
>
> Done (it's a wiki page - anyone can edit it ;) ).

Certainly, but I think wiki edits should generally be done by people who
understand what they are talking about.  In this area, I don't
particularly qualify yet.

Thanks,

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Re: Feedback on merging via bzr

[Scott Kitterman]

> Hi,
>
> On Mon, Jan 18, 2010 at 9:24 AM, Dmitrijs Ledkovs
>  wrote:
>>
>> $bzr init-repo package
>> $cd package
>> $bzr branch lp:ubuntu/package lucid
>> $bzr branch lp:debian/package squeeze
>>
> [...]
>>>
>>> At this point I want to check the package against the previous Debian
>>> and
>>> Ubuntu packages to make sure I have it correct.  Traditionally, I would
>>> locally debdiff the proposed merge with both the previous Debian and
>>> Ubuntu
>>> packages to make sure I had documented all of the Ubuntu diff and not
>>> lost any
>>> needed changes in the merge.  To do it the new way, I did:
>>>
>>> $bzr diff --old lp:debian/squeeze/regina-normal | less
>>> ssh key
>>> (repeat, including redownloading each time the diff is done)
>>>
>>
>> At this point in the package/lucid branch you have all package
>> revisions and tags so you can do this :
>>
>> $bzr diff -r tag:0.1-3ubuntu5  #debdiff against old ubuntu
>> $bzr diff -r tag:0.1-6 #debdiff against debian
>>
>> Or any package release for that matter. see $bzr tags
>>
>
> I usually use the ancestor revision shortcut for selecting the revision to
> diff:
>
> Ubuntu patch compared to the common base version:
>
> ~/src/pkg-name/lucid/ $ bzr diff -rancestor:../squeeze/
>
> Debian patch compared to the common base version:
>
> ~/src/pkg-name/squeeze/ $ bzr diff -rancestor:../lucid/
>
> These two commands should generate the equivalent of the .patch files from
> MoM.
>
That doesn't solve the issue with the data being local versus remote, but
it definitely looks very helpful.  Would you add that to the wiki page on
merging?

Scott K


-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Feedback on merging via bzr

[Scott Kitterman]

I spent some time over the holidays giving merging via bzr and the UDD tools.  
I understand that development of the tools to support this is still a work in 
progress and the much of this feedback probably represents work that you 
already know needs doing.  This mail is based on notes I took recently while 
doing a merge of regina-normal.  As merges go, it was not a complex one.

I'm writing this from the perspective of someone who is reasonably familiar 
with merging using merge-o-matic (~3 years of experience), but relatively knew 
to bzr.  I would have been dead almost immediately if not for the w.u.c 
documentation [1].

Step 1: Getting the source:

Using MoM, I would have grab-merge.sh regina-normal and then had local copies 
of the common ancestor package, the current Debian package, the current Ubuntu 
package, and a proposed merge with any conflicting files listed.

The UDD equivalent seems to be:

$bzr branch lp:ubuntu/regina-normal regina-normal
$password for ssh key
$cd regina-normal
$bzr merge-package lp:debian/squeeze/regina-normal

Text conflict in debian/changelog
1 conflicts encountered.
The merge resulted in 1 conflicts. Please resolve these and commit the changes 
with "bzr commit".

This gives me the proposed merge.  The conflict in this case seems to occur 
with every merge I try.  The most recent Debian and Ubuntu debian/changelog 
entries conflict with each other and the file has to be edited to move the most 
recent Debian entry above the most recent Ubuntu entry.  Additionally, MoM 
would create a stub changelog entry for the new merged package which was quite 
convenient.  None of this additional work is difficult, but it is tedious and 
seems ripe for automation.

Additionally, I still don't have the previous packages available (Debian, 
Ubuntu, and common ancestor).

To get ready to start to work on the actual merge, I need to also do:

$ vim debian/changelog (re-arrange as described)
$ bzr resolve
All conflicts resolved.
$ bzr ci -m "Fix debian/changelog conflict."
$ dch -i (manually add the new changelog entry)

Step 2 working on the package:

I needed to update the build-depends for this package (why I was doing the 
merge right now) and so that was pretty easy:

$ vim debian/control
$ bzr ci -m "* Add new debian/changelog entry
> * Build-depend on libboost-python1.40-dev instead of libboost-python1.38-
dev"
Committing to: ~/devel/boost/merge/regina-normal/
modified debian/changelog
modified debian/control
Committed revision 19.

Step 3 checking the package:

At this point I want to check the package against the previous Debian and 
Ubuntu packages to make sure I have it correct.  Traditionally, I would 
locally debdiff the proposed merge with both the previous Debian and Ubuntu 
packages to make sure I had documented all of the Ubuntu diff and not lost any 
needed changes in the merge.  To do it the new way, I did:

$bzr diff --old lp:debian/squeeze/regina-normal | less
ssh key
(repeat, including redownloading each time the diff is done)

I assume "bzr diff --old lp:ubuntu/regina-normal" would have worked for the 
diff 
from the previous Ubuntu package, but it isn't documented and I didn't think 
to try it at the time.

Then commit the result:

$ bzr ci -m "* Update debian/changelog to include undocumented differences from 
Debian
> * Remove extraneous whitespace changes"
Committing to: ~/devel/boost/merge/regina-normal/
modified debian/changelog
modified python/testsuite/trigeneral.test
Committed revision 20.

This method of diffing works fine, except that the previous branch has to be re-
downloaded each time the diff is done.  In this case I was trying to remove 
extraneous white space changes that had crept into the packages so it took 
several tries to get them all.  For larger packages or people with a slow 
internet connection, the need to re-download the diff will have a substantial 
negative impact.  Additionally, I miss a way to diff just the debian 
directories.  For new upstream releases (which this wasn't, so I didn't hit 
it) I find this a critical way to review the packaging differences between the 
old and new packages.

Step 4: Building the package:

In the old method, I would debuild -S (-sa if needed) -v and have a package 
ready for uploading. 

bzr builddeb -S -- -v4.6-1ubuntu1

Now this one looks easy, but has the hidden trap of bzr builddeb providing 
only -S from dpkg-buildpackage and requiring an extra flag to pass other 
options to dpkg-buildpackage ("--").  I think this needs a rethink [2].  

Step 5: Testing the package:

This is orthogonal to UDD, so I won't cover it.

Step 6: Uploading the package:

$ dput ubuntu regina-normal_4.6-1.1ubuntu1_source.changes

At this point, I'd be done under the old method (and I could have stopped here 
now and let the branch be created from the uploaded package, but I decided to 
persevere).

$ bzr mark-uploaded

$ bzr push lp:ubuntu/regina-normal
ssh key ...

Now we are done and have both an updated package in

Re: fastimport and the scope of the hottest 100 effort

[Scott Kitterman]

> 2010/1/11 Ian Clatworthy :
>> James raised the question recently about whether some of the packages in
>> the hottest 100 ought to excluded or not, e.g. pidgin's upstream is in
>> monotone and we don't have a bzr-monotone plugin.
>>
>> My answer is yes, we'll need to exclude some things. The import
>> breakdown analysis I did last Friday showed some packages don't have
>> publicly available source code, e.g. the HP printer drivers and various
>> X drivers.
>>
>> In terms of strategy, I think we should focus on getting as many imports
>>  in the top 100 as possible working via bzr-svn, bzr-git and bzr-hg. We
>> should also take a moment to confirm imports of these packages are into
>> 2a branches, *not* earlier or development formats.
>
> hottest100 really has two points:
>
>  * get some useful packages working to enable daily builds - they'll
> ship in Launchpad by April and need fodder
>  * get some clearer data on what kind of thing needs to be fixed
>
> both are useful.
>
> Outcomes for various packages may be
>
>  * there just is no public source tree (hplip, maybe
> kde-blah-workspace) - while this is true, daily builds aren't
> possible; this is worth tracking but not realy our problem

All the KDE upstream code is publically available in svn.  See
http://techbase.kde.org/Getting_Started/Sources/Anonymous_SVN for details.

One point that may be a bit confusing is that kdebase upstream is in three
subdirectories: apps, runtime, and workspace and our naming doesn't
exactly align.  These correspond to our kdebase, kdebase-runtime, and
kdebase-workspace source packages.  See
http://websvn.kde.org/trunk/KDE/kdebase/

The above path is for KDE Trunk, but KDE 4.4 (the release for Lucid has
already been branched).  The branch to track that's aimed at Lucid is
http://websvn.kde.org/branches/KDE/4.4/kdebase/.  I'm not sure, given your
goals what you should be tracking.  Let me know if you need anymore help
finding KDE stuff.

Scott K

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel