Re: Testing/feedback wanted: Using dpkg-mergechangelogs in bzr-builddeb

[James Westby]

On Fri, 8 Jul 2011 09:16:53 +1000, Andrew Bennetts 
 wrote:
> James Westby wrote:
> […]
> > bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_not_valid_changelog
> > 
> > This is testing what happens with an invalid changelog. I'm not sure
> > what the effect of returning "not_applicable" versus "success" with the
> > invalid text would be. I don't think it's a particularly important case
> > though.
> 
> “not_applicable” gives other merge hooks, including the default one
> (which is always applicable, but might conflict), a chance to try the
> merge.  The other outcomes (“success”, “conflicted” and “deleted”) are
> final result for the merge.
> 
> So that test is saying “if it's not a valid changelog, give up and let
> the default logic (or other plugins) merge it.”  I agree that that
> doesn't seem particularly important.  The main thing I think is that
> invalid changelogs shouldn't cause tracebacks or other completely
> unreasonable output (and *perhaps* ideally also produce a gentle warning).
> If so, “success” vs. “not_applicable” are both fine, assuming the
> apparent success isn't actually total garbage.

Yeah, sounds about right, given that it only acts on files called
"debian/changelog."

> another…” line.  BASE → THIS just adds “But more is better”.  So that
> output looks like a sensible and expected combination of those changes:
> it's what I'd do if I had to merge those by hand.  But as a VCS
> developer perhaps my sense of what's expected is skewed ;)
> 
> Given that one side does discard a line, do you still find it odd that
> the merge also discards that line?

I'm not sure now. I think I read it too quickly the first time, but your
explanation about sounds pretty convincing.

Thanks,

James

-- 
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: Testing/feedback wanted: Using dpkg-mergechangelogs in bzr-builddeb

[Andrew Bennetts]

James Westby wrote:
[…]
> bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_not_valid_changelog
> 
> This is testing what happens with an invalid changelog. I'm not sure
> what the effect of returning "not_applicable" versus "success" with the
> invalid text would be. I don't think it's a particularly important case
> though.

“not_applicable” gives other merge hooks, including the default one
(which is always applicable, but might conflict), a chance to try the
merge.  The other outcomes (“success”, “conflicted” and “deleted”) are
final result for the merge.

So that test is saying “if it's not a valid changelog, give up and let
the default logic (or other plugins) merge it.”  I agree that that
doesn't seem particularly important.  The main thing I think is that
invalid changelogs shouldn't cause tracebacks or other completely
unreasonable output (and *perhaps* ideally also produce a gentle warning).
If so, “success” vs. “not_applicable” are both fine, assuming the
apparent success isn't actually total garbage.

> bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_3way_conflicted
> 
> Getting success back in this case seems wrong.

Hmm, I can see a good argument for success here, actually.  This looks
like a successful three-way merge:

> The text it returns is:
> 
>  psuedo-prog (1.1.1-2) unstable; urgency=low
> 
>* New upstream release.
>* Yet another content for 1.1.1-2
>* But more is better
> 
>   -- Joe Foo   Thu, 28 Jan 2010 10:45:44 +
> 
> and I'm not sure that's correct as it's discarding a line.
> 
> If it's the desired behaviour of dpkg-mergechangelog then it may be what
> we want, but it seems odd to me.

BASE → OTHER deletes the “Awesome bug fixes.” line, and adds the “Yet
another…” line.  BASE → THIS just adds “But more is better”.  So that
output looks like a sensible and expected combination of those changes:
it's what I'd do if I had to merge those by hand.  But as a VCS
developer perhaps my sense of what's expected is skewed ;)

Given that one side does discard a line, do you still find it odd that
the merge also discards that line?

-Andrew.


-- 
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: Testing/feedback wanted: Using dpkg-mergechangelogs in bzr-builddeb

[James Westby]

On Wed, 6 Jul 2011 17:27:34 +1000, Andrew Bennetts 
 wrote:
>  proposes replacing the
> existing changelog merge logic with dpkg-mergechangelogs' implementation.  
> I've
> done that in  (simply by
> shelling out to it), but it changes the existing output enough that the 
> existing
> tests fail.
> 
> So here's where I'd like help: tell me, is the new output better (or at least 
> no
> worse) for you?
> 
> If so, we can adjust the tests accordingly and land it.  If not, we can try to
> figure out what to do instead.

Hi,

I had three failures:

bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_unsorted

This one is asserting that it will sort the changelog, which I think is
the root of why the bug was filed, so the failure would be expected.

bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_not_valid_changelog

This is testing what happens with an invalid changelog. I'm not sure
what the effect of returning "not_applicable" versus "success" with the
invalid text would be. I don't think it's a particularly important case
though.

bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_3way_conflicted

Getting success back in this case seems wrong.

The text it returns is:

 psuedo-prog (1.1.1-2) unstable; urgency=low

   * New upstream release.
   * Yet another content for 1.1.1-2
   * But more is better

  -- Joe Foo   Thu, 28 Jan 2010 10:45:44 +

and I'm not sure that's correct as it's discarding a line.

If it's the desired behaviour of dpkg-mergechangelog then it may be what
we want, but it seems odd to me.

Thanks,

James

 

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

[John Meinel]

I think for UDD it is important to have the wt, but I think we could
do.better about making the branches subset compatible. The package importer
already uses several branches to try and match file ids. This could be
another. The history would be divergent, but you could use "bzr merge
-rx..y" rather than diff/patch.

John
=:->
On Jul 6, 2011 11:00 PM, "Barry Warsaw"  wrote:
> On Jul 06, 2011, at 04:54 PM, Scott Kitterman wrote:
>
>>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.
>
> I tried to touch on that with this bit:
>
>>On Wednesday, July 06, 2011 04:43:00 PM Barry Warsaw wrote:
>>> 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).
>
> but I agree that this needs more attention. Although I like having the
full
> source branches, I can see the appeal of packaging-only branches. Any
> solution needs to be adaptive to both styles of working.
>
> -Barry
-- 
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 meeting change

[Barry Warsaw]

Please note the following time change:

At least for the rest of the northern summer, we're bumping the UDD meetings
up by one hour.  They will now be held at 1200 UTC.

See you on 13-July.

Cheers,
-Barry


signature.asc
Description: PGP signature
-- 
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