Re: your thoughts wanted on bzr team UDD focus

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dmitrijs Ledkovs wrote:
> (Sorry aaron didn't reply all first time around)
> 
> 2009/12/8 Aaron Bentley :
>> However, we can ignore svn issues because we're switching to bzr-svn.
>> (We hope that will solve many of our problems, but whichever problems
>> remain will be *different*)
>>
> 
> Is there a bug I can subscribe to witch tracks switching to bzr-svn
> for imports? Cause I am currently pushing bzr-svn branch myself.

Yes: https://bugs.edge.launchpad.net/launchpad-code/+bug/359791

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksepywACgkQ0F+nu1YWqI3QOgCfZMscXwrKAmt98T+Vyc/jHiOZ
fOwAnAtaPRSDaHUDI+bBEewLO68WH++m
=CGOW
-END 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

Re: your thoughts wanted on bzr team UDD focus

[Dmitrijs Ledkovs]

(Sorry aaron didn't reply all first time around)

2009/12/8 Aaron Bentley :
>
> However, we can ignore svn issues because we're switching to bzr-svn.
> (We hope that will solve many of our problems, but whichever problems
> remain will be *different*)
>

Is there a bug I can subscribe to witch tracks switching to bzr-svn
for imports? Cause I am currently pushing bzr-svn branch myself.


-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

-- 
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: your thoughts wanted on bzr team UDD focus

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tim Penhey wrote:
> Well, bzr-svn can't support svn:externals properly until bzr has nested trees 
> as well.
> 
> Personally I'd like to see externals of some form supported natively in bzr.

I'd like to see nested trees in bzr.  But I think that would be a lot of
work, and probably not justified on the basis of fixing a few imports.
So I'd imagine we'd do something else, like traversing the external and
making its contents part of the tree.  (i.e. by-value nesting)  I'm less
keen on that sort of solution, though I can see the pragmatism.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksdvWsACgkQ0F+nu1YWqI0hiACfXwG2qXqqXTjTD8IWCe4PAiwU
atIAnAuELSfdkQeQr4TITQK5B3hWLR10
=JcxG
-END 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

Re: your thoughts wanted on bzr team UDD focus

[Tim Penhey]

On Tue, 08 Dec 2009 14:49:32 Aaron Bentley wrote:
> Martin Pool wrote:
> > What I'm trying to get at here is the next level of detail of what we
> > can be doing to help with bzr builder, imports and bugs?  If a major
> > cause of failing imports is lack of git submodule support, that would
> > be a strategic thing for us to resolve.
> 
> If you look at mwhudson's research:
> 
> https://devpad.canonical.com/~mwh/values-sorted.txt
> 
> Only five failures are due to the lack of submodule support.
> 
> However, we can ignore svn issues because we're switching to bzr-svn.
> (We hope that will solve many of our problems, but whichever problems
> remain will be *different*)

Well, bzr-svn can't support svn:externals properly until bzr has nested trees 
as well.

Personally I'd like to see externals of some form supported natively in bzr.

Tim

-- 
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: your thoughts wanted on bzr team UDD focus

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Pool wrote:
> What I'm trying to get at here is the next level of detail of what we
> can be doing to help with bzr builder, imports and bugs?  If a major
> cause of failing imports is lack of git submodule support, that would
> be a strategic thing for us to resolve.

If you look at mwhudson's research:

https://devpad.canonical.com/~mwh/values-sorted.txt

Only five failures are due to the lack of submodule support.

However, we can ignore svn issues because we're switching to bzr-svn.
(We hope that will solve many of our problems, but whichever problems
remain will be *different*)

So there are a lot of failures on that scale, and any of them would be
worth solving.  Some of the errors are pretty unclear, like this one:

OSError: [Errno 17] File exists:
'/srv/importd.launchpad.net/data/worker-for-branch-25632/bzr_working_tree/.bzr'
 pypi-mirror-trunk-logtail.txt

> What do you think is most
> useful to help with daily builds or imports?

For bzr-builder
 - Support for recipe inheritance
 - Support for copying just the debian directory out of an existing
   package branch
 - Support for copying just the debian directory, without any of the
   patches out of an existing package branch, to enable upstreams to
   package their exact code.

For imports
 - I would just pick a problem off the list and investigate.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksdsKgACgkQ0F+nu1YWqI00ogCgiVFRzVQHlJriyOV+U738Lywj
6pQAn3pfoFzttvR5EI6vF52MVAmc3u3l
=tAhH
-END 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

Re: your thoughts wanted on bzr team UDD focus

[Martin Pool]

2009/12/8 Aaron Bentley :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Pool wrote:
>> From the previous threads, it seems that the main large things we need
>> to do are:
>>
>>  * get more code imports working -- investigation of failure causes is
>> continuing
>>  * support imports of git submodules or svn externals -- this is not moving 
>> yet
>
> At the sprint, my impression was that the goals were:
> 1. Work on daily-builds, especially bzr-builder
> 2. Work on the code imports that feed daily builds
> 3. In slack time, try to focus on bugs affecting Ubuntu.

What I'm trying to get at here is the next level of detail of what we
can be doing to help with bzr builder, imports and bugs?  If a major
cause of failing imports is lack of git submodule support, that would
be a strategic thing for us to resolve.  What do you think is most
useful to help with daily builds or imports?

-- 
Martin 

-- 
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: your thoughts wanted on bzr team UDD focus

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Pool wrote:
> From the previous threads, it seems that the main large things we need
> to do are:
> 
>  * get more code imports working -- investigation of failure causes is
> continuing
>  * support imports of git submodules or svn externals -- this is not moving 
> yet

At the sprint, my impression was that the goals were:
1. Work on daily-builds, especially bzr-builder
2. Work on the code imports that feed daily builds
3. In slack time, try to focus on bugs affecting Ubuntu.

I'm a bit surprised to see externals front-and-centre in your list.  I
don't remember serious discussion of them at the sprint.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksdn88ACgkQ0F+nu1YWqI2PJgCeP0JdTkxY9k5K53q32ey7xwV6
Jl0AnRNtbUILZpNL3altzhxP60k5ciXa
=t2v7
-END 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

Re: your thoughts wanted on bzr team UDD focus

[Max Bowsher]

Martin Pool wrote:
> 2009/12/5 Max Bowsher :
>> John's question is then:
>>  So how did Ubuntu find "1.1" such that it isn't an ancestor of "2.1"?
>>  Are they using different upstreams? Or are these tarball imports such
>>  that 2.1 secretly should be a descendant of 1.1, but nobody recorded
>>  that fact?
>>
>> Thus phrased, the answer is rather clearer.
> 
> But perhaps not quite so clear it's not worth spelling out... :-)
> 
> I think maxb is saying: we should retrospectively insert that edge
> into the graph, or something equivalent?

Oh :-)

No, all I was saying was: Now I've inserted actual version numbers into
the graph, you can see that the reason for the divergence is that Ubuntu
imported an upstream version that Debian skipped.

Max.



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

Re: your thoughts wanted on bzr team UDD focus

[Martin Pool]

2009/12/5 Max Bowsher :
> John's question is then:
>  So how did Ubuntu find "1.1" such that it isn't an ancestor of "2.1"?
>  Are they using different upstreams? Or are these tarball imports such
>  that 2.1 secretly should be a descendant of 1.1, but nobody recorded
>  that fact?
>
> Thus phrased, the answer is rather clearer.

But perhaps not quite so clear it's not worth spelling out... :-)

I think maxb is saying: we should retrospectively insert that edge
into the graph, or something equivalent?

-- 
Martin 

-- 
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: your thoughts wanted on bzr team UDD focus

[James Westby]

On Fri Dec 04 16:24:31 -0500 2009 Max Bowsher wrote:
> Thus phrased, the answer is rather clearer.

Indeed it is, thanks Max.


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: your thoughts wanted on bzr team UDD focus

[Max Bowsher]

James Westby wrote:
> On Thu Dec 03 16:05:18 -0500 2009 John Arbash Meinel wrote:
>> So how did Ubuntu find "C" such that it isn't an ancestor of "G"? Are
>> they using different upstreams? Or are these tarball imports such that G
>> secretly should be a descendant of C, but nobody recorded that fact?
> 
> The latter.
> 
> Debian and Ubuntu worked independently at that time, so we can't add a
> bzr parent, however, there is a logical relationship there. This discrepancy
> is the cause of the issue.
> 
> The problem is aggravated by the fact that we don't currently have complete
> history for Debian.

The situation is more understandable if the diagram is redrawn thusly:

 debian upstream .--2.0---2.1
   1.0\ \
 ubuntu upstream `-+-1.1 \
  \ \  \  \
 debian\   2.0-1+-2.1-1
  1.0-1-`\
 ubuntu  `---1.1-0ubuntu1


John's question is then:
  So how did Ubuntu find "1.1" such that it isn't an ancestor of "2.1"?
  Are they using different upstreams? Or are these tarball imports such
  that 2.1 secretly should be a descendant of 1.1, but nobody recorded
  that fact?

Thus phrased, the answer is rather clearer.


Max.




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

Re: your thoughts wanted on bzr team UDD focus

[Max Bowsher]

Martin Pool wrote:
> 2009/12/3 James Westby :
> 
>> merge-package
> 
> thanks, that was very clear.
> 
>> To get rid of this we need something that knows to first merge G->C, and
>> then that in to H->F. This will still require the user to resolve conflicts
>> on the G->C merge, but a simple "revert" invocation can be used at that 
>> stage,
>> and we have the possibility to automate that for packaging (possibly still
>> called merge-package).
> 
> So, where should this something be hooked in?  Is it a hook that runs
> code similar to merge-package when you're in a packaging branch? (wag)

I don't like the idea that "bzr merge" would make commits if it happens
to be a packaging branch. That seems a little too magical to me. I think
it might be better to keep it as "bzr merge-package". Perhaps with an
"explanatory message and abort" hook in "bzr merge".

Max.



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

Re: your thoughts wanted on bzr team UDD focus

[James Westby]

On Thu Dec 03 16:05:18 -0500 2009 John Arbash Meinel wrote:
> So how did Ubuntu find "C" such that it isn't an ancestor of "G"? Are
> they using different upstreams? Or are these tarball imports such that G
> secretly should be a descendant of C, but nobody recorded that fact?

The latter.

Debian and Ubuntu worked independently at that time, so we can't add a
bzr parent, however, there is a logical relationship there. This discrepancy
is the cause of the issue.

The problem is aggravated by the fact that we don't currently have complete
history for Debian.

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: your thoughts wanted on bzr team UDD focus

[Martin Pool]

2009/12/4 Francis J. Lacoste :
> On December 3, 2009, Martin Pool wrote:
>> If there are existing bugs relevant to udd, or you know of
>> appropriately concrete and self-contained things that can be filed as
>> bugs, then tagging them and/or mentioning them here would be helpful.
>> It would give us something to be getting on with.  But I agree the
>> larger issues are too broad to make useful bugs now.  (One could have
>> placeholder bugs like "work out what to do about X" but I doubt that
>> helps.)
>>
>
> Actually, given the workflow you guys seem to favour, I think it might be
> sense. Otherwise, how to do you track and make sure that somebody drives the
> requirements process on these larger issues?

Momentum on the udd list, plus James's specs?  Or maybe we should do
it, at least as bugs against the udd project.

So I'll refine that position a bit to: those bugs are ok as long as
they're things we've agreed are reasonably in scope and things we're
actively working on.  If they're not being worked on, they just seems
like clutter that causes confusion later on.  (It's not quite the same
thing but Brian's confusion to do with finding old Launchpad
blueprints about communication which are half-implemented or obsolete
or generally detached from reality is the kind of thing I'd like to
avoid.)  Bugs which are not clearly falsifiable and not moving towards
being clear are a drag.

-- 
Martin 

-- 
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: your thoughts wanted on bzr team UDD focus

[Francis J. Lacoste]

On December 3, 2009, Martin Pool wrote:
> If there are existing bugs relevant to udd, or you know of
> appropriately concrete and self-contained things that can be filed as
> bugs, then tagging them and/or mentioning them here would be helpful.
> It would give us something to be getting on with.  But I agree the
> larger issues are too broad to make useful bugs now.  (One could have
> placeholder bugs like "work out what to do about X" but I doubt that
> helps.)
> 

Actually, given the workflow you guys seem to favour, I think it might be 
sense. Otherwise, how to do you track and make sure that somebody drives the 
requirements process on these larger issues?

-- 
Francis J. Lacoste
francis.laco...@canonical.com


signature.asc
Description: This is a digitally signed message part.
-- 
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: your thoughts wanted on bzr team UDD focus

[Martin Pool]

2009/12/4 James Westby :
> On Thu Dec 03 01:05:00 -0500 2009 Andrew Bennetts wrote:
>> Are there any other UDD-related bugs that should be filed (or existing ones
>> tagged)?
>
> Is the Bazaar team looking for all issues to be filed as bugs. I'm happy
> to do that, but a lot of things we have been discussing would currently
> considered to be too imprecise for a good bug report.

No, at least not at this stage.

If there are existing bugs relevant to udd, or you know of
appropriately concrete and self-contained things that can be filed as
bugs, then tagging them and/or mentioning them here would be helpful.
It would give us something to be getting on with.  But I agree the
larger issues are too broad to make useful bugs now.  (One could have
placeholder bugs like "work out what to do about X" but I doubt that
helps.)

As John said in another thread, I think people are having trouble
spanning from the big picture into what we can actually do to help.
We'll know we've reached that level when we do have a queue of bugs.
But I don't want to shortcircuit that process, or put all the work of
it onto you.

-- 
Martin 

-- 
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: your thoughts wanted on bzr team UDD focus

[John Arbash Meinel]

James Westby wrote:
> On Wed Dec 02 23:01:01 -0500 2009 Robert Collins wrote:
>> https://bugs.edge.launchpad.net/udd/+bug/491711 is a bug I've filed
>> about merging specific files better; please provide feedback about
>> whether you think it might work for you.
>
> Thanks, sounds about right. We don't need much information to do this
> particular merge, just THIS and OTHER in the script I posted.
>
> I wonder about performance, for this we could register for any basename
> of "changelog", but other things may want to do some fairly intensive
> checking of whether they can handle the file in question based on its
> contents.
>
>> I've marked it high, because things that make bzr-builddeb etc easier
>> and simpler will help in maintenance of that code and its
>> understandability.
>
> Yes.
>
>> What do you need to be able to drop merge-package?
>
> Something that can merge two strands of development contained in one
> branch. merge-package is there because of this case you can get in to
>
>
> debian upstream .B--G
>A  \  \
> ubuntu upstream `--+---C  \
>  \  \   \  \
> debian\  E---+--H
>D` \
> ubuntu  `--F
>
> (Apologies to anyone using a screenreader)
>
> In words:
>
>   * Debian and Ubuntu ship the same upstream release (A) packaged
> in the same version (D).
>
>   * Debian updates to a new upstream release (B), packaged as E.
>
>   * Ubuntu leap-frogs Debian to an even newer upstream release (C),
> packaged as F.
>
>   * Debian then packages the latest upstream release (G) as H.
>
> Ubuntu now wishes to merge H in to F.

So how did Ubuntu find "C" such that it isn't an ancestor of "G"? Are
they using different upstreams? Or are these tarball imports such that G
secretly should be a descendant of C, but nobody recorded that fact?

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: your thoughts wanted on bzr team UDD focus

[James Westby]

On Thu Dec 03 01:05:00 -0500 2009 Andrew Bennetts wrote:
> Are there any other UDD-related bugs that should be filed (or existing ones
> tagged)?

Is the Bazaar team looking for all issues to be filed as bugs. I'm happy
to do that, but a lot of things we have been discussing would currently
considered to be too imprecise for a good bug report.

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: your thoughts wanted on bzr team UDD focus

[Robert Collins]

On Thu, 2009-12-03 at 17:05 +1100, Andrew Bennetts wrote:

> Are there any other UDD-related bugs that should be filed (or existing
> ones
> tagged)? 

I suspect there are many, but we'll need to find them as we join dots
up. I haven't read James' latest email, but I suspect it is relevant.

-Rob


signature.asc
Description: This is a digitally signed message part
-- 
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: your thoughts wanted on bzr team UDD focus

[Andrew Bennetts]

Martin Pool wrote:
[...]
> I'd like that bug work to be guided by UDD requirements.  So feel free
> to either ask here, or put the 'affects-udd' tag onto our bugs, or ask
> on irc or the Bazaar list.  I'd say that tag should count as about a
> +3 to hit, or in other words an upgrade of one Importance level.

No bzr bugs are tagged 'affects-udd' yet, but 2 are tagged 'udd', so I've
marked that tag as official in Launchpad.  If you'd rather it was
'affects-udd' you should change that sooner rather than later ;)

The two 'udd' bugs are:

 - 488724: commands updating working tree should provide the same
   modification time for all modified files
 - 491711: hook to permit per file merges

Or see  for the
current list ;)

I've just assigned 491711 to myself, it doesn't look particularly hard from
the outside.  I'll probably look at 488724 after that if no-one else gets to
it first.

Are there any other UDD-related bugs that should be filed (or existing ones
tagged)?

-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: your thoughts wanted on bzr team UDD focus

[Martin Pool]

2009/12/3 James Westby :

> merge-package

thanks, that was very clear.

> To get rid of this we need something that knows to first merge G->C, and
> then that in to H->F. This will still require the user to resolve conflicts
> on the G->C merge, but a simple "revert" invocation can be used at that stage,
> and we have the possibility to automate that for packaging (possibly still
> called merge-package).

So, where should this something be hooked in?  Is it a hook that runs
code similar to merge-package when you're in a packaging branch? (wag)

-- 
Martin 

-- 
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: your thoughts wanted on bzr team UDD focus

[James Westby]

On Wed Dec 02 23:01:01 -0500 2009 Robert Collins wrote:
> https://bugs.edge.launchpad.net/udd/+bug/491711 is a bug I've filed
> about merging specific files better; please provide feedback about
> whether you think it might work for you.

Thanks, sounds about right. We don't need much information to do this
particular merge, just THIS and OTHER in the script I posted.

I wonder about performance, for this we could register for any basename
of "changelog", but other things may want to do some fairly intensive
checking of whether they can handle the file in question based on its
contents.

> I've marked it high, because things that make bzr-builddeb etc easier
> and simpler will help in maintenance of that code and its
> understandability.

Yes.

> What do you need to be able to drop merge-package?

Something that can merge two strands of development contained in one
branch. merge-package is there because of this case you can get in to


debian upstream .B--G
   A  \  \
ubuntu upstream `--+---C  \
 \  \   \  \
debian\  E---+--H
   D` \
ubuntu  `--F

(Apologies to anyone using a screenreader)

In words:

  * Debian and Ubuntu ship the same upstream release (A) packaged
in the same version (D).

  * Debian updates to a new upstream release (B), packaged as E.

  * Ubuntu leap-frogs Debian to an even newer upstream release (C),
packaged as F.

  * Debian then packages the latest upstream release (G) as H.

Ubuntu now wishes to merge H in to F.

To bzr it seems as if it needs to merge (B, E, G, H) in to (C, D, F),
so this is what it will do. However, this means that it will try and
merge the changes in C and (B, G). This does not go well, as it dutifully
gives what it sees as legitimate conflicts, but what you see is all the
upstream changes conflicting.

The issue is that there are missing arcs (B, C) and (C, G), which would
tell bzr that this is one line of development.

merge-package works around this. It knows that the links should be there,
and it can't put them in, so it creates a new node, I, that is the tree
of G, but with (G, C) as parents. It then merges this to H, and then
finally in to F. This means the final merge is approximately (E, G, H) in
to (D, F) as we want.

It does have some issues of its own (such as how to explain what has gone
wrong if the I->H merge fails, and simply not being "bzr merge" as it should
be), but it is better than the conflicts with plain merge.

I would really like it to go away, for many reasons, including so that I am
no longer asked what it does, and either have to try and explain the
above, or to just tell people they are better off not knowing.

To get rid of this we need something that knows to first merge G->C, and
then that in to H->F. This will still require the user to resolve conflicts
on the G->C merge, but a simple "revert" invocation can be used at that stage,
and we have the possibility to automate that for packaging (possibly still
called merge-package).

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: your thoughts wanted on bzr team UDD focus

[Martin Pool]

2009/12/3 James Westby :
> On Mon Nov 30 20:19:13 -0500 2009 Martin Pool wrote:
>> I'd like to get a sanity check from UDD people on what the Bazaar team
>> is going to do for our 2.1 release, which will have a feature freeze
>> in February and go into Karmic.
>>
>> From the previous threads, it seems that the main large things we need
>> to do are:
>
> Hi,
>
> Thanks for requesting feedback.
>
> There were a bunch of other things discussed, and scenarios considered,
> and these two items are the only things that came out the other end. You
> are obviously the one that should decide how much work to take on given
> the developer time available, so I'm not complaining that the list is
> short. I do however wonder about the other features that were discussed.
> Did you decide that these gave the best return on investment, or was
> it just that these were the items most discussed?

Well, what I posted was more of a strawman of where we want to end up,
limiting it to the things that seemed concrete and short-term
feasible, and it's true somewhat impatiently shortcircuiting the
discussion.  But I would be very very happy to hear from you, or from
others, different nominations for that list and something about why.
I suppose this will come out of your UDS specs.

>>  * get more code imports working -- investigation of failure causes is
>> continuing
>
> Are you setting any sort of targets, or is it too early to know
> how varied the causes are and so know what a sensible target would
> be?

Let me point you to the thread "Yo code team -- how do you want your
stats?" on canonical-launchpad (for no very good reason; I think
generally it should be public.)  There is some triage and conversion
into bugs.  We haven't yet targeted them.

-- 
Martin 

-- 
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: your thoughts wanted on bzr team UDD focus

[Robert Collins]

On Tue, 2009-12-01 at 11:29 -0500, James Westby wrote:
> 
> http://people.canonical.com/~jamesw/merge_changelog
> 
> is one, there are other versions around.
> 
> Note that with the merge-package command we don't need the hooks to
> be able to do this (though it would be nice to have anyway). I don't
> see anything on this list that would move us towards being able
> to drop merge-package. 

https://bugs.edge.launchpad.net/udd/+bug/491711 is a bug I've filed
about merging specific files better; please provide feedback about
whether you think it might work for you.

I've marked it high, because things that make bzr-builddeb etc easier
and simpler will help in maintenance of that code and its
understandability.

What do you need to be able to drop merge-package?

-Rob


signature.asc
Description: This is a digitally signed message part
-- 
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: your thoughts wanted on bzr team UDD focus

[James Westby]

On Mon Nov 30 20:19:13 -0500 2009 Martin Pool wrote:
> I'd like to get a sanity check from UDD people on what the Bazaar team
> is going to do for our 2.1 release, which will have a feature freeze
> in February and go into Karmic.
> 
> From the previous threads, it seems that the main large things we need
> to do are:

Hi,

Thanks for requesting feedback.

There were a bunch of other things discussed, and scenarios considered,
and these two items are the only things that came out the other end. You
are obviously the one that should decide how much work to take on given
the developer time available, so I'm not complaining that the list is
short. I do however wonder about the other features that were discussed.
Did you decide that these gave the best return on investment, or was
it just that these were the items most discussed?

>  * get more code imports working -- investigation of failure causes is
> continuing

Are you setting any sort of targets, or is it too early to know
how varied the causes are and so know what a sensible target would
be?


I am currently distilling UDS discussions in to specs, so I will be sending
them to the list shortly, this may inspire some discussion of needed
features. There are a couple of items that I will highlight for discussion.

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: your thoughts wanted on bzr team UDD focus

[Jonathan Lange]

On Wed, Dec 2, 2009 at 5:01 PM, Vincent Ladeuil  wrote:
>> "jml" == Jonathan Lange  writes:
>
>    jml> On Tue, Dec 1, 2009 at 7:02 PM, Max Bowsher  wrote:
>    >> Vincent Ladeuil wrote:
>    >>
>    >>> * import all branches defined in a git repo instead of only HEAD
>    >>>
>    >>> The later may not be the bzr team direct responsibility, but all
>    >>> parties involved in the discussion at UDS (Keybuk, jelmer, jml,
>    >>> kiko ?) agreed about its importance
>    >>
>    >> bzr-git can already import all branches - what it can't do is import a
>    >> specific branch, which is presumably what prevents its use in Launchpad
>    >> code imports.
>    >>
>
> Err, I said and repeat: import *all* branches. bzr-git can do it,
> launchpad can do it, all we need it connecting the dots.
>
>
>    jml> Say "hinders", not "prevents". Right now, the Launchpad code import
>    jml> system (and indeed everything about Launchpad code) is very, very
>    jml> branch-oriented.
>
>    jml> Perhaps Launchpad could import all the branches in a git-repo?
>
>    jml> Probably easier for all concerned to allow us to import a single
>    jml> branch, at least to start with.
>
> No. The point is that there is not a *single* interesting branch
> to import, most of the time there are several distinct heads (so
> you can't import the most advanced one and indirectly get the
> others for free).
>

What I meant is that changing Launchpad to import all branches is a lot of work.

Changing it to allow importing of arbitrary git branches:
significantly less work, and approximates automatically importing all
branches.

jml

-- 
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: your thoughts wanted on bzr team UDD focus

[Vincent Ladeuil]

> "James" == James Westby  writes:

James> On Tue Dec 01 03:04:30 -0500 2009 Vincent Ladeuil wrote:
>> Things we can safely add to this list:
>> 
>> * add hooks allowing james_w to plug a customized merge for
>> changelog (by the way James, you never recover from your failed
>> demo in the Grand Ball Room, so I've yet to see that script you
>> mentioned ;-)

James> http://people.canonical.com/~jamesw/merge_changelog

James> is one, there are other versions around.

I see.

James> Note that with the merge-package command we don't need the hooks to
James> be able to do this (though it would be nice to have anyway).

James> I don't see anything on this list that would move us
James> towards being able to drop merge-package.

Then, please, update it :)

We may want to add http://bazaar-vcs.org/DraftSpecs/PathTokens
here, or at least a limited form that could allow us to say: from
this point these two files are really the same (with no
possibility to revert that association to keep things simple).

 Vincent

-- 
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: your thoughts wanted on bzr team UDD focus

[Vincent Ladeuil]

> "jml" == Jonathan Lange  writes:

jml> On Tue, Dec 1, 2009 at 7:02 PM, Max Bowsher  wrote:
>> Vincent Ladeuil wrote:
>> 
>>> * import all branches defined in a git repo instead of only HEAD
>>> 
>>> The later may not be the bzr team direct responsibility, but all
>>> parties involved in the discussion at UDS (Keybuk, jelmer, jml,
>>> kiko ?) agreed about its importance
>> 
>> bzr-git can already import all branches - what it can't do is import a
>> specific branch, which is presumably what prevents its use in Launchpad
>> code imports.
>> 

Err, I said and repeat: import *all* branches. bzr-git can do it,
launchpad can do it, all we need it connecting the dots.


jml> Say "hinders", not "prevents". Right now, the Launchpad code import
jml> system (and indeed everything about Launchpad code) is very, very
jml> branch-oriented.

jml> Perhaps Launchpad could import all the branches in a git-repo?

jml> Probably easier for all concerned to allow us to import a single
jml> branch, at least to start with.

No. The point is that there is not a *single* interesting branch
to import, most of the time there are several distinct heads (so
you can't import the most advanced one and indirectly get the
others for free).

>> I happened to be playing with this last night and it
>> appears to require only about 7 lines of code in
>> bzr-git. The outstanding problem is apparently that no one
>> has managed to agree on an URL form to refer to "colocated
>> branches", so the actual implementation is blocked.
>> 

What may be needed is to a bit of polish to delete branches
created by previous imports and not present anymore in the repo,
but I think everybody can live without that.

jml> Well, Launchpad doesn't _need_ a URL. We could change
jml> the import form to have an optional "branch" field, and
jml> pass that as some secondary option to bzr-git.

jml> AIUI, the only thing blocking us on that is round
jml> tuits.

Yes.

jml> Michael Hudson, who has done the vast bulk of the code
jml> import work, is busy doing build-from-recipe stuff right
jml> now, but the code is there for the hacking. Maybe
jml> someone from the Bazaar world?

I'd like to help (if only by creating a launchpad dedicated VM
locally), but I don't know when I'll get there :-/

  Vincent

-- 
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: your thoughts wanted on bzr team UDD focus

[Jonathan Lange]

On Tue, Dec 1, 2009 at 7:02 PM, Max Bowsher  wrote:
> Vincent Ladeuil wrote:
>
>> * import all branches defined in a git repo instead of only HEAD
>>
>> The later may not be the bzr team direct responsibility, but all
>> parties involved in the discussion at UDS (Keybuk, jelmer, jml,
>> kiko ?) agreed about its importance
>
> bzr-git can already import all branches - what it can't do is import a
> specific branch, which is presumably what prevents its use in Launchpad
> code imports.
>

Say "hinders", not "prevents". Right now, the Launchpad code import
system (and indeed everything about Launchpad code) is very, very
branch-oriented.

Perhaps Launchpad could import all the branches in a git-repo?

Probably easier for all concerned to allow us to import a single
branch, at least to start with.

> I happened to be playing with this last night and it appears to require
> only about 7 lines of code in bzr-git. The outstanding problem is
> apparently that no one has managed to agree on an URL form to refer to
> "colocated branches", so the actual implementation is blocked.
>

Well, Launchpad doesn't _need_ a URL. We could change the import form
to have an optional "branch" field, and pass that as some secondary
option to bzr-git.

AIUI, the only thing blocking us on that is round tuits. Michael
Hudson, who has done the vast bulk of the code import work, is busy
doing build-from-recipe stuff right now, but the code is there for the
hacking. Maybe someone from the Bazaar world?

jml

-- 
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: your thoughts wanted on bzr team UDD focus

[Max Bowsher]

Vincent Ladeuil wrote:

> * import all branches defined in a git repo instead of only HEAD
>
> The later may not be the bzr team direct responsibility, but all
> parties involved in the discussion at UDS (Keybuk, jelmer, jml,
> kiko ?) agreed about its importance

bzr-git can already import all branches - what it can't do is import a
specific branch, which is presumably what prevents its use in Launchpad
code imports.

I happened to be playing with this last night and it appears to require
only about 7 lines of code in bzr-git. The outstanding problem is
apparently that no one has managed to agree on an URL form to refer to
"colocated branches", so the actual implementation is blocked.

It would be great if someone familiar with the past discussion on this
matter could summarize the status and/or revive the discussion.

Max.



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

Re: your thoughts wanted on bzr team UDD focus

[James Westby]

On Tue Dec 01 03:04:30 -0500 2009 Vincent Ladeuil wrote:
> Things we can safely add to this list:
> 
> * add hooks allowing james_w to plug a customized merge for
>   changelog (by the way James, you never recover from your failed
>   demo in the Grand Ball Room, so I've yet to see that script you
>   mentioned ;-)

http://people.canonical.com/~jamesw/merge_changelog

is one, there are other versions around.

Note that with the merge-package command we don't need the hooks to
be able to do this (though it would be nice to have anyway). I don't
see anything on this list that would move us towards being able
to drop merge-package.

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: your thoughts wanted on bzr team UDD focus

[Vincent Ladeuil]

> "martin" == Martin Pool  writes:

martin> I'd like to get a sanity check from UDD people on
martin> what the Bazaar team is going to do for our 2.1
martin> release, which will have a feature freeze in February
martin> and go into Karmic.

>> From the previous threads, it seems that the main large things we need
martin> to do are:

martin>  * get more code imports working -- investigation of
martin>failure causes is continuing
martin>  * support imports of git submodules or svn externals
martin> -- this is not moving yet

Things we can safely add to this list:

* add hooks allowing james_w to plug a customized merge for
  changelog (by the way James, you never recover from your failed
  demo in the Grand Ball Room, so I've yet to see that script you
  mentioned ;-)
* import all branches defined in a git repo instead of only HEAD

The later may not be the bzr team direct responsibility, but all
parties involved in the discussion at UDS (Keybuk, jelmer, jml,
kiko ?) agreed about its importance

A brief explanation: 

git users always exchange repos, never branches, because they
consider the repo as the container and provide references inside
that container.

Importing only the HEAD branch when importing a git repo is
therefore almost useless for people that want to track upstream
because HEAD is rarely relevant for them: any bugfix or release
*is* in the repo, but not in HEAD ancestry.

 Vincent

-- 
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: your thoughts wanted on bzr team UDD focus

[Robert Collins]

On Tue, 2009-12-01 at 04:16 +0100, Jelmer Vernooij wrote:
> 
> These three all require additional "magic" versioned files, which are
> a
> pain when roundtripping. 
> 
> Also, supporting any of these alternatives now means we'll have to
> bump
> the bzr-git mapping when nested trees land and we do want to create
> proper nested trees. 

Well, we'll probably have to do that anyway, unless no changes are made
to the nested trees design before it becomes stable.

-Rob


signature.asc
Description: This is a digitally signed message part
-- 
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: your thoughts wanted on bzr team UDD focus

[Jelmer Vernooij]

On Tue, 2009-12-01 at 13:41 +1100, Robert Collins wrote: 
> On Tue, 2009-12-01 at 02:39 +0100, Jelmer Vernooij wrote:
> > Hi Martin,
> > 
> > On Tue, 2009-12-01 at 12:19 +1100, Martin Pool wrote: 
> > > I'd like to get a sanity check from UDD people on what the Bazaar team
> > > is going to do for our 2.1 release, which will have a feature freeze
> > > in February and go into Karmic.
> > > 
> > > From the previous threads, it seems that the main large things we need
> > > to do are:
> > > 
> > >  * get more code imports working -- investigation of failure causes is
> > > continuing
> > >  * support imports of git submodules or svn externals -- this is not 
> > > moving yet
> > As for bzr-git/bzr-svn support for git submodules / svn externals:
> > 
> > fwiw git submodules can (as of UDS when I discussed this with Dustin and
> > Vincent) now be imported with newer versions of bzr-git, and are
> > converted to by-reference nested trees. This will of course only work if
> > the target repository supports storing nested trees (e.g. the
> > experimental development-subtree format). 
> 
> This makes me extremely nervous. The last time a plugin did something
> the core didn't /support/, it took us 4 and a half years or so to fix
> it, because we were constrained by having lots of data around, and we
> didn't get to do the fix that would have been best (and been maybe 10%
> smaller on the converted data).
Last time this happened we required a particular format for all  
 bzr-svn/bzr-git imports, without a particularly good reason. Now it's
 just for repositories that require submodules, there's no proper way  
 to support those with a non-experimental format. bzr-git doesn't
  create development-subtree branches by itself, not even if it sees a
 submodule.

I understand that development-subtree is experimental - this implies
 imports with bzr-git of submodules are experimental too. I don't see
 how bzr-git creating revisions with by-reference nested trees is any
 worse than users doing so manually using "bzr join --reference". Users
 have to manually initialise a development-subtree branch before in either 
case. 

> _please please please please_ contribute to bzr's support first, and
> only enable this in bzr-git when there is a supported format that does
> nested trees.
While I would love to see proper by-reference nested trees support in
bzr core, I'm very hesitant to contribute given the history of nested
trees in bzr. 

If the current development-subtree format (while clearly marked as
experimental) is bad even for experimentation, can we please remove it? 

> Until then, I suggest outputting one of:
>  - a bzr-builder recipe
>  - scm-proj
>  - config-manager
These three all require additional "magic" versioned files, which are a
pain when roundtripping. 

Also, supporting any of these alternatives now means we'll have to bump
the bzr-git mapping when nested trees land and we do want to create
proper nested trees.

Cheers,

Jelmer


signature.asc
Description: This is a digitally signed message part
-- 
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: your thoughts wanted on bzr team UDD focus

[Robert Collins]

On Tue, 2009-12-01 at 02:39 +0100, Jelmer Vernooij wrote:
> Hi Martin,
> 
> On Tue, 2009-12-01 at 12:19 +1100, Martin Pool wrote: 
> > I'd like to get a sanity check from UDD people on what the Bazaar team
> > is going to do for our 2.1 release, which will have a feature freeze
> > in February and go into Karmic.
> > 
> > From the previous threads, it seems that the main large things we need
> > to do are:
> > 
> >  * get more code imports working -- investigation of failure causes is
> > continuing
> >  * support imports of git submodules or svn externals -- this is not moving 
> > yet
> As for bzr-git/bzr-svn support for git submodules / svn externals:
> 
> fwiw git submodules can (as of UDS when I discussed this with Dustin and
> Vincent) now be imported with newer versions of bzr-git, and are
> converted to by-reference nested trees. This will of course only work if
> the target repository supports storing nested trees (e.g. the
> experimental development-subtree format). 

This makes me extremely nervous. The last time a plugin did something
the core didn't /support/, it took us 4 and a half years or so to fix
it, because we were constrained by having lots of data around, and we
didn't get to do the fix that would have been best (and been maybe 10%
smaller on the converted data).

_please please please please_ contribute to bzr's support first, and
only enable this in bzr-git when there is a supported format that does
nested trees.

Until then, I suggest outputting one of:
 - a bzr-builder recipe
 - scm-proj
 - config-manager
 - by-value nested tree.

-Rob


signature.asc
Description: This is a digitally signed message part
-- 
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: your thoughts wanted on bzr team UDD focus

[Jelmer Vernooij]

Hi Martin,

On Tue, 2009-12-01 at 12:19 +1100, Martin Pool wrote: 
> I'd like to get a sanity check from UDD people on what the Bazaar team
> is going to do for our 2.1 release, which will have a feature freeze
> in February and go into Karmic.
> 
> From the previous threads, it seems that the main large things we need
> to do are:
> 
>  * get more code imports working -- investigation of failure causes is
> continuing
>  * support imports of git submodules or svn externals -- this is not moving 
> yet
As for bzr-git/bzr-svn support for git submodules / svn externals:

fwiw git submodules can (as of UDS when I discussed this with Dustin and
Vincent) now be imported with newer versions of bzr-git, and are
converted to by-reference nested trees. This will of course only work if
the target repository supports storing nested trees (e.g. the
experimental development-subtree format). 

This should at least allow imports of repositories with nested trees to
work. Of course - since bzr only stores nested trees at the moment and
doesn't have working tree support for them - this doesn't really allow
submodules to be used yet as they were intended. Launchpad will also
need some fixes to be able to import repositories with submodules, as
its current default target format (2a) doesn't support subtrees. 

svn externals are ignored at the moment, and we will need a bzr-svn
mapping bump (generating different revision ids) to start supporting
them. Some initial work on this is available here:
http://people.samba.org/bzr/jelmer/bzr-svn/nestedtrees/

Cheers,

Jelmer


signature.asc
Description: This is a digitally signed message part
-- 
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: your thoughts wanted on bzr team UDD focus

[Tim Penhey]

On Tue, 01 Dec 2009 14:19:13 Martin Pool wrote:
> I'd like to get a sanity check from UDD people on what the Bazaar team
> is going to do for our 2.1 release, which will have a feature freeze
> in February and go into Karmic.
> 
> From the previous threads, it seems that the main large things we need
> to do are:
> 
>  * get more code imports working -- investigation of failure causes is
> continuing
>  * support imports of git submodules or svn externals -- this is not moving
>  yet

This makes me very happy.

Tim

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

your thoughts wanted on bzr team UDD focus

[Martin Pool]

I'd like to get a sanity check from UDD people on what the Bazaar team
is going to do for our 2.1 release, which will have a feature freeze
in February and go into Karmic.

>From the previous threads, it seems that the main large things we need
to do are:

 * get more code imports working -- investigation of failure causes is
continuing
 * support imports of git submodules or svn externals -- this is not moving yet

At the moment we're mostly doing consolidation work after 2.0:
continuing to pull on performance threads (2.1 should be substantially
faster and use less memory), fixing bugs, improving documentation, and
making community contribution more fun.  This is very satisfying and
going well, but we may need to shift focus to more specifically
strategic things.

I'd like that bug work to be guided by UDD requirements.  So feel free
to either ask here, or put the 'affects-udd' tag onto our bugs, or ask
on irc or the Bazaar list.  I'd say that tag should count as about a
+3 to hit, or in other words an upgrade of one Importance level.

My sense is that getting submodule/external imports going by February
is not out of the question but might be a stretch to do it safely.
(More data welcome.)  And it seems also that for the initial rollout
of UDD it would be ok to do it on trees that don't use
submodules/externals, but it will of course block widespread use.

So, UDDers:

 * are there other things that should be on this map, either bugs or features?
 * how do you feel about the relative importance of those features vs
bugs or performance?
 * how crucial is it to get submodule/external support in 2.1?

Thanks
-- 
Martin 

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