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

2010-12-12 Thread Michael Bienia
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).

> How hard would it be to do that?

As the -changes mail gets generated when the upload gets accepted that
would probably delay them if they need to wait on the diff.
How long does it take till the diff between two uploads is available in
LP?

Michael

-- 
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

2010-07-20 Thread Michael Bienia
On 2010-07-20 11:21:36 +0200, Martin Pool wrote:
> On 20 July 2010 09:59, Michael Bienia  wrote:
> > My last attempt (yesterday) to use packaging branches to prepare a
> > change (to get it sponsored) stopped early because the branch was
> > out-of-date (package: mutt).  I had to fall back to create a debdiff.
> 
> Do you mean the Ubuntu packaging branch, or the upstream branch, or
> something else?

The Ubuntu packaging branch for maverick:
https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/mutt/maverick

I wanted to branch lp:ubuntu/mutt to have the current version of the
source package in maverick. But the branch is still at 1.5.20-7ubuntu1
while the most recent upload is 1.5.20-9ubuntu1 (uploaded nine days
ago).

Michael

-- 
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

2010-07-20 Thread Michael Bienia
On 2010-07-19 17:59:22 -0400, Francis J. Lacoste wrote:
Hi,

> Does that seem consistent with your views of the current usage? What is 
> blocking more users from jumping on the UDD bandwagon?

My last attempt (yesterday) to use packaging branches to prepare a
change (to get it sponsored) stopped early because the branch was
out-of-date (package: mutt).  I had to fall back to create a debdiff.

Michael

-- 
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: Where to see the list of merges/uploads that need review?

2010-01-28 Thread Michael Bienia
On 2010-01-28 17:17:06 -0500, Elliot Murphy wrote:
Hello,

> I'm feeling worried and mildly demotivated that my merge proposal has
> been sitting here for 10 days:
> https://code.edge.launchpad.net/~statik/ubuntu/lucid/protobuf/merge-bug502654/+merge/17571

I can feel with you.

> I asked about this the other day in #ubuntu-devel, and ScottK
> mentioned that it's normal to have delays at this stage in the cycle,
> so I waited a bit longer.

I'm also currently waiting on two merges getting sponsored (currently 6
days and 3 days old). My last merge got sponsored after 10 days. But
I've also had merges that were sponsored pretty fast. Probably depends
on who looks on the queue and if they need the merged package themself to
move on.

> Is there anything similar for ubuntu distributed development merges, a
> particular queue to look at to see what is pending?

I know of
https://code.edge.launchpad.net/~ubuntu-branches/+activereviews
https://code.edge.launchpad.net/~ubuntu-main-sponsors/+activereviews
https://code.edge.launchpad.net/~ubuntu-universe-sponsors/+activereviews

> Before starting to use ubuntu-distributed-development, I would have
> filed a bug, attached some sort of debdiff, and subscribed the
> appropriate -sponsors team, but I thought merge proposals were the hot
> new way to do things. The first time, I tried to find someone directly
> to review my merge and that worked ok - my first udd merge was for
> erlang, and I saw pitti had touched it last so I just asked him
> directly, and he uploaded right away. But that doesn't seem scalable
> or efficient compared to having a pool of things that need reviewing.

Until all get used to the new bzr merges, I still file bugs for my merge
proposals to be on the safe side. As
http://qa.ubuntu.com/reports/sponsoring/index.html lists only bugs
awaiting sponsoring, a merge proposal without a matching bug might get
lost.

> Any advice for me?

No real advice, just wait. I try to avoid looking for sponsors as I
don't want to pester the other devs too much.

Michael

-- 
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

2010-01-27 Thread Michael Bienia
On 2010-01-27 05:00:15 -0600, John Arbash Meinel wrote:
> I'm looking into working on this bug:
> https://bugs.edge.launchpad.net/bzr/+bug/160521
> 
> Which describes adding a changelog-specific per-file merge for
> bzr-builddeb. (if you have the plugin, and do 'bzr merge' that contains
> a merge of a file that looks like 'changelog', then the custom merge
> algorithm gets invoked for that file.)
> 
> I'm wondering if you have a link towards where this "Bryce's
> merge_changelog script" might exist and how I might get ahold of it as a
> reference.

https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20100114/6936c7d4/attachment.obj
(it was attached to an other mail on this list:
https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-January/000357.html)

As this script does its own version comparison and changelog parsing,
you might also want to look at the "python-debian" package which has a
python module for handling changelogs (parsing) and also a python module
for Debian version strings.

Michael

-- 
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

2010-01-18 Thread Michael Bienia
On 2010-01-17 22:45:53 -0500, Scott Kitterman wrote:

Currently I often insert a step 0 before starting on merging with bzr:
- Check if the Debian branch is uptodate.

Perhaps I got unlucky when picking a package to merge but several of the
packages I wanted to merge had outdated Debian branches so I had to do
it by hand (download the Debian .dsc and the Ubuntu delta from PTS and
merge it).

> 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

I usually do a "bzr init-repo" before and branch both the Ubuntu and
Debian branch and use the local Debian branch for merging and diffing.

It would be really nice if bzr warned one if the format of local branch
and the remote repository differ *before* I start working on something.

I merged "fuse" the usual way (and used "bzr init-repo" for storing the
branches) and when I was about to push the branch towards my LP account
for sponsoring, I got told that bzr can't push it because the LP branch
uses a different format.
I branched the Ubuntu branch once again (this time without "bzr
init-repo" so it keeps its format) and kind of redid the merge (I copied
the changed files from the other branch into this one). This time the
pushing worked. But it cost me unnecessary time.

Michael

-- 
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

2010-01-18 Thread Michael Bienia
On 2010-01-18 16:18:44 +1100, Andrew Bennetts wrote:
> That's right.  If you're interested, bug 491711
>  is tracking progress on this,
> and there's a branch at adds the hook point going through code review at the
> moment.  Perhaps there should be a bzr-builddeb bug (or bug task on 491711?)
> too?  

I've filed a bug against bzr-builddeb about this before I knew about the
ongoing work on hooks:
https://bugs.launchpad.net/bugs/501754 (Better support for merging
debian/changelog)

Michael

-- 
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: Per-file merge hook for bzr

2010-01-14 Thread Michael Bienia
On 2010-01-14 11:20:00 +1100, Andrew Bennetts wrote:
> Judging from , the next step
> for udd is to implement a hook to merge debian/changelog in bzr-builddeb.  Is
> there some code already written for merging or at least parsing 
> debian/changelog
> files?

"from debian_bundle import changelog" (package is python-debian)

It contains a class for parsing debian/changelog and also a class for
versions (including policy-compliant comparison as it uses python-apt
for it).

You might perhaps also want to look at the code for MoM (Merge-o-Matic;
https://code.edge.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk) to
see how it prepared its merges (including debian/changelog).

Michael

-- 
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