udd at uds-n

2010-11-17 Thread Martin Pool
Just a few brief notes about UDD discussions at UDS-N.  A lot of this
is captured to various degrees in gobby documents and IRC logs at
http://ubottu.com/uds-logs/, but they're pretty long:

http://ubottu.com/uds-logs/%23ubuntu-uds-bonaire2.log
* There was a lot of interest in adopting something like the bzr patch
pilot process  in Ubuntu; it's worked well for us and I'm pleased Rick
is willing to give it a go in the different situation of Ubuntu.  I
hope it goes well.

http://ubottu.com/uds-logs/%23ubuntu-uds-curacao1+2.log
The main discussion about UDD is here, starting about
2010-10-27T16:08, and there are a lot of good things for us to work
on, including:

 * speed of getting source through UDD, considered holistically
(including outright speed, needing to fetch from the UK rather than a
closer mirror, shallow checkouts, proactive mirroring)
 * various merge cases that could be better
 * problems with packages with complex history already in bzr,
creating multiple histories

Some other observations:
 * currently used by very much early-adopters
 * build from recipe quite successful, though still quite young
 * focus on eliminating tedium
 * check out grab-udd-merge

At the end of that discussion we picked two specific items for the bzr team:
 * speed
 * loom support, on lp and within bzr, and connecting them to packaging patches

and for Launchpad
 * build from branch into the main archive
 * actually execute a merge from a merge proposal
 * through launchpad. merge from a debian branch into an ubuntu udd branch

We did not get around to doing interactive user testing; I'm trying to
reschedule that with mrevell.

We did get survey responses, and I will send a summary of them soon.

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


UDD survey results

2010-11-17 Thread Martin Pool
TLDR? Mixed but generally positive feedback.  Top issues to fix are
speed of branching/merging from Launchpad; keeping import branches
reliably up to date; getting branches where possible to current
formats; removing various small-medium roadblocks; supporting v3
packages and being smarter about merging.

We did a survey before UDS asking people if they had tried using
Bazaar to deal with packaging branches for Ubuntu.   The results are
quite interesting.  Obviously like any opt-in survey there is going to
be some sampling bias, but nevertheless this gives us something to
steer our future efforts.

Most were quite positive, some with constructive criticism; some do
not like the idea at all.

I've put a detailed view survey results up here:

  http://people.canonical.com/~mbp/udd-survey-201011/SurveySummary.html or
  http://people.canonical.com/~mbp/udd-survey-201011/SurveySummary.pdf
(all on one page but unfortunately a bit mangled)

This doesn't have individual sheets, personally identifiable
information and I don't think it has any sensitive information.  It
does have the email addresses for people who chose to leave them, but
not connected to their responses.  Since all of those people have used
their addresses on public lists, I'm going to assume they are ok with
having them on the web.  (If you hear of any problems please let me
know and we'll take it down.)  If anyone wants to drill into
particular responses I will give you access.

85 people answered in all.  I'm grateful to all of them for giving their time.

75 have already used bzr branches for Ubuntu development to some extent.

There is a good even mix of core devs, motus, contributing developers,
casual developers, and new developers.

Net promoter score: 22 would recommend overall Ubuntu development
using Bazaar at least fairly strongly (net promoter score 7..10); 6
would recommend avoiding it (0..3).  However, 50 people skipped this
question, perhaps suggesting they have mixed feelings, or the question
was poorly stated (eg they don't see it as a thing they recommend to
others.)

Overall speed: 32 fast enough, 12 not fast enough, 41 no answer.
Despite those numbers I think many of the no answers actually do see
speed as a major issue, taking the survey as a whole.  The great
majority of comments about speed are to do with fetching from
Launchpad.

Reliability:
Similarly 34 reliable, 10 unreliable, 41 no comment, but here my
interpretation is that improving reliability is important, but it is
not at the moment a showstopper the way speed can be.  Some people see
bzr as reliable and lp as flaky; others just the opposite.  lp
downtime is hated, so I'm happy to know this is moving very fast
towards being reduced.  Getting bugfixes in bzr rolled out into the
distro packages is important.  The biggest issue is making sure that
branches are reliably up to date.

The strongest cluster of criticism was essentially it's not git,
with those respondents saying: they and their potential contributors
are already familiar with git; upstreams and Debian use git for the
package; there are features they like in it; they like git-style
collocated branches; it is faster.  Some of these people would
generally rather we switch to using git, some want Launchpad to
support git alongside bzr, and some want to continue along the line of
interoperation but to do it better.  Some specific features they miss
are mentioned below.  People only made this argument about git: nobody
said we should use support hg or svn alongside or instead of bzr.

Contra this, some people reported bzr easier to set up, learn and use
than git; better error messages.  There were mixed opinions on the
quality of git imports.

Positive things (for at least some people):
* Getting the code, branching and committing reported to be easy.
* bzr itself is nice.
* Having bzr-level log for changes.
* Easily being able to get old release sources.
* Pulling commit messages from changelogs.
* merge-upstream is nice.
* Familiarity of commands from cvs, svn or darcs.
* When Launchpad is obvious, it works well.
* Pipelines are cool.
* Bugs are generally fixed fast.
* Supportive community.

Criticisms mostly of Launchpad:
* Slow, in various ways, especially from APAC.
* Hard to navigate: finding specific branches; understanding what to
do; hard to find the cool features.
* Confusion/annoyance from old branch formats.
* Bad that the launchpad-side setup of stacked branches is
inconsistent with the client side repository directory.
* When something goes wrong, errors can be confusing.
* My biggest gripes are with the lp:ubuntu/pkgname full source
branches. They have some nice features and traits, but a lot of
problems still: - They are way too easy to break for new upstream
versions from maintainers who aren't used to it yet. - It's impossible
(at least for me) to convert an already existing branch (derived from
upstream bzr) into the official lp:ubuntu/pkgname branch (ask me
(pitti) for details) - Because of