fastimport and the scope of the hottest 100 effort

Martin Pool mbp at canonical.com
Tue Jan 12 01:12:54 GMT 2010


2010/1/11 Ian Clatworthy <ian.clatworthy at canonical.com>:
> 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
 * something's broken but it's easily fixed, like a missing
package-product link or broken branch url - just fix it and we're done
 * something's broken and it's a bzr bug - this satisfies the second
and helps us plan things for strasbourg and beyond
 * we need a different approach - mt imports are like this; again it
is giving us data

Doing mt imports through fastimport (or maybe otherwise) sounds like a
reasonable thing to do, but I'd rather get data across the whole 100
first, then pick the best cost/benefit bugs.  Obviously even just
looking at the top 10 as you have is a start.

When you are gathering data, please put it into the spreadsheet so
that we don't have a hundred little mails about it.

I'll start a branch in the udd project for this so we have a perhaps
more amenable place to collate it.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the ubuntu-distributed-devel mailing list