launchpad development
Launchpad derived distribution mock-up testing round 2
Suggestions
The following suggestions arise from comments made by the second round participants.
- Clarify what "ignore" means in the context of packages. Consider other terms.
- Clarify that it's source packages we're talking about.
- Clarify what ignored new packages means.
- Retain the last common version information -- in response to Michael's question -- but consider if there are more space-efficient ways of displaying it.
- Ignore: does it mean ignore this package forever or just this version?
- Clarify what the search searches on: package names, package descriptions or both.
- Consider which diffs are useful and should be available.
Loic Minier
20th August 2010 |
Canonical/Linaro |
(audio) |
Mock-up1
Note: this recording is somewhat unclear.
Matthew: Have a look through the first half of this page and tell me if it makes sense to you.
Loic: I don't understand the first bullet point in the pop-up help overlay.
Matthew: What confuses you there?
Loic: I'm not exactly sure if we're talking of on overlay on top of Ubuntu or a filtered view of Ubuntu.
Matthew: The secon dpart of the page, where you specify the parent distro and series, is that clear?
Loic: Yes. Would it be a one-time copy or an ongoing import? What happens if something new is uploaded if it's a development series? Saying that, it's always going to be copying because none of them is frozen. I know there is a Lucid updates and Lucid proposed so packages are going to be entering all the time.
Matthew: How you would be most comfortable specifying which architectures you want to use. So, a list with checkboxes or a search box that allows you find the architecture. Do you think there would be too many arcs to have a drop-down list?
Loic: No. I think the number of architectures is going to go lower. So, we may only have four to offer and adding a fifth one. What worries me a bit here is that it's not obvious that building i386, well, there's this need of building out all packages and I'm not sure that it's clear that it's a good idea to build i386 and AMD64 to most people. One side of it is the technical requirement and the other side is the developer workflow. Like, in most case, you want to be able to run the i386 and AMD64 packages on your desktop to confirm they work and then you generate the ARM packages for ARM derivatives. I think this might let people turn on only ARM and actually realise that it won't work. So it might be that we can build all architectures or that we will always build them on i386 and have an ARMEL compliment, but it's not clear that it's a technical requirement that the [unclear] packages are built somewhere.
Sorry, I'm giving two feedbacks at once. One is the fact that you need an architecture all buildd for keeping the i386 or derivative arch is a good idea for technical reasons. The second thing is that it's a good idea from a dev workflow perspective to keep building i386 or AMD64 as it gives you the chance to test binaries on your desktop and the build for ARM, but that's more a choice you'll make when working with a derivative archive.
And I prefer checkboxes because there's only a small number of [architectures]. This is not what I expected. I expected that you can create architectures outside of ubuntu. [unclear] will probably land in ubuntu but what happens if we can actually copy it from Debian and it has a different set of architectures, can I create another project which is like a new distribution like Linaro, or whatever, which isn't actually copied from Ubuntu but is available here as a derivative?
I expect that in the future there'll be more than six choices. Currently we have a single ARMEL archive for Ubuntu and I expect that at some point we'll have multiple ARMEL archives, that's another layer that I don't think is implemented here and will happen later.
Matthew: So, V5, V6 etc?
Loic: Yeah, or V7+Neon.
Okay, then there is a question of packagesets. I'm not very familiar with packagesets. From a practical perspective, what I care about is that I am able to copy over a seed but eventually I'll change the definition of that seed. What matters to me here is how exactly do I create my packagesets? I guess there is a help button, so there'll be instructions.
What happens if the packageset changes?
Matthew: Do the copy options make sense?
Loic: I realise now that there is the option to copy a packageset. That cannot make sense. So I can click on any of them and they get selected for copy. Would "Import" make more sense? So, the packagesets are not going to kept in sync, it'll be a one time copy and I don't know if they'll be kept in sync.
Matthew: So, you feel "import" would be a better word to use?
Loic: Yes.
Matthew: So, you think the copy options should be "Import options". Do the options make sense?
Loic: Yes. I do have one question, in the form of, there is a third mode that I propose but I don't know if it's implemented as part of that or not. Ideally, we'd be able to have like ermmm it's more like, as it goes over time, for the initial archive it's good but then if I have copied over source and binaries and I'm doing some changes in my archives, I know I'm importing packages from the current parent archive, will they be rebuilt or will the binaries be copied?
In some cases, we want to build binaries but in others it might be a good optimisation not to.
I think you need to track if those packages change a lot and it's quite hard to do. You have less storage on packages and less buildd time. I can copy all the Ubuntu development uploads and it doesn't cost me anything so long as I don't have any changes in my archive.
Matthew: Any other comments on this page?
Loic: No, I think it's good. The version thing is a bit daunting. You have to choose a version. But yes, it makes sense.
Matthew: You could type anything you wanted into the version textbox.
Loic: It would be nice if I knew which of these things I can change later on.
Mock-up 2
Matthew: Okay, this is a side-box that would appear on the overview page of your derived distroseries. It gives you an overview of the changes between the parent series and your derivative. Does this make sense to you?
Loic: Yes. Actually, I'm questioning one thing, I think the main use case is single parent distribution but very often when I think about Ubuntu I realise that Debian is not the only upstream. We have other upstreams and sometimes we have other distributions as upstreams. Maemo is a Debian-based distribution and in a way it's an Ubuntu upstream. There will be more and more derivatives. I think for now a single parent is fine.
Mock-up 3
Matthew: Does the description of this page tell you what the page is about?
Loic: Yes, I'm happy with it.
Matthew: Looking at the link "There are currently 5 updated Lucid packages that have been ignored", do you understand what that means?
Loic: I suspect they have not been imported but I don't really like the name "ignored", it's like I didn't do something. I would say, "There are 5 updated Lucid packages which have to be imported or reviewed". Perhaps it means that there are five Lucid packages that I'm blacklisting. I'm not sure. I guess if it's a blacklist I would know where to find the blacklists and I would already have blacklisted them.
Matthew: Beneath that is a table showing you some of the packages that have differences between your derivative and the parent. Do each of the columns make sense?
Loic: Why isn't the package name in a separate column? To save space? The package name is in the same column as the Lucid version. From a data perspective it makes sense to have a separate column but from a UI perspective it makes sense to save space.
So, we have to review this by hand. They are not computed all the time.
Matthew: In that you wouldn't get a notification if a difference arose?
Loic: No, we have to request the diffs. It surprised me because we generate a diff between all Ubuntu uploads so I guess you'll also do that between derivative uploads but okay I guess it make sense to avoid changing it all the time.
The sync column ... okay, ignore all, sync. I guess this is to ignore what I'm going to show in my list of packages to review in the future. They're patches I won't care about. Why not call them a blacklist?
I don't really like the selection and then "sync" and "ignore" at the bottom. I feel like it's ... I don't like it but I cannot say why. I think it would be fine if I was the one checking these options but ... when I'm reading this mock-up, I'm trying to understand what's being done. On the one hand, I'm overriding my versions with the versions from Lucid. On the other, I would keep my versions. Because these are very different actions, I feel uncomfortable redoing someone else's selections but if I was driving I would be happy to select and click.
Perhaps a drop-down on each line but that might be harder than doing it twice.
I feel ignore is a rare action and it should be kept a bit more away. You can keep this list of packages going on and on and you can always review the list of differences. It won't go away. You could just ignore them yourself. The ignore option sounds like I'm going to ignore it forever.
Matthew: The column "Last common version in Derilucid", is that necessary?
Loic: It's useful when you're doing a merge but I don't think a link is useful. Just knowing the version is useful. Probably it's visisble in the diff, so you'll see it in the changelog. Will this be a link to the patch in the librarian or will it be a nice view of the diff? I think it'd make more sense to have this information on the web UI for the diff.
One thing I think it is missing here is some sort of date stamp to filter the new stuff, the stuff to review. How long has it been pending? Last update on that. Does that make sense? If I ask comments for all these things, I'm tempted to be able to sort them. I know page views in Launchpad are painful enough so I don't want to have to click next. I want to make sure I can extract the top ones I can look at.
Perhaps I should be able to assign people to a merge, perhaps I should be able to have a bug linked to a merge or a person assigned to a merge and be able to filter by date the latest syncs or changes. So, this package was imported recently or a comment was made recently, so this package should be at the top or the bottom.
Mock-up 4
Matthew: Does the title of the page make sense?
Loic: Yes, that makes sense. One package is only in one packageset, right? I guess these are derivative packagesets and the copied over ones.
Matthew: Does the line "There are currently 6 new Lucid packages that have been ignored" make sense?
Loic: I can't help but think of a blacklist. I don't like the name "ignore". I think it's probably much easier to decide to copy a package or not than this thing. It very often requires a human to resolve the merge, the new package is probably much easier. The UI is much nicer here and it's fine to have it like that plus it makes sense to have the UI almost the same and to have the facility for sorting packages and so on, but I think the comments aren't very likely to be used here. When you see a package you can decide what to do straight away, either ignore or copy. The comment is almost superfluous but it's consistent with the other mock-up so it's fine.
Matthew: Any other comments?
Loic: A date stamp would be useful, so we can know when it showed up. Making it clear that these are source packages. Actually, it very often mentions "package" and it's very obvious to me that this is at the source package level, but the binary packages might have an impact. Sometimes you'll copy a binary source package and think it's harmless but actually there's some [unclear] going on. It's quite important to know you're copying over some binary packages so I think it should be clear that we're sticking your source packages somewhere. It might make sense to include a list of binary packages that are to be copied over.
Mock-up 5
Matthew: Again, is it clear what this page is about?
Loic: In this case you choose to include the description but not in any other case. The description is always attached to the package. So I find that weird. It's helpful to have a description. This last one [mock-up] is very simple and it's a nice report.
Matthew: Any comments in general?
Loic: I don't know if the people doing merges is actually recorded. I think it's helpful to track who is doing merges. Linking people to packages. Both in the case of new packages on the derivative side, this person uploaded it, I'd like to be able to know who changed a package. I think it's helpful to know who did the last merge. I don't know how we could relate it to the person. The person who uploaded to Lucid is probably the person I'd like to poke to do the merge. Like on merges.ubuntu.com where you see the last uploader and the maintainer.That's useful to me. The reason I use ... it might be useful to have a report for that person on the things they should be working on. On merges.ubuntu.com I search for my name so to make sure I address my own merges. It's like your pending merge request. I think it'd be useful to narrow who's supposed to work on something and have it show up.
As a first iteration, I think it's great. I'm really happy with the simplicity. I didn't see a way to, there's no explanation of what would be copied over in the future. So, as soon as you create a derivative we never copy sources over. [When syncing, do we copy packages and binaries?] It would be a really cheap way of having a dervied distribution. I think it's a complex thing, it's not easy.
Peter Pearse
20th August 2010 |
ARM/Linaro |
Mock-up 1
Matthew: How much experience of Launchpa do you have already?
Peter: I've been using it over the past couple of months since I started with Linaro.
Matthew: Let's have a look at the first mock-up. This is the page you see when you're coming to create a derived distribution series. Does this page make sense to you?
Peter: Yes, once I know what a series is and I understand the concepts I'm dealing with.
Matthew: Let's imagine we're replicating an existing version of Ubuntu and then replicating it by taking away certain packages or adding others, to create a Linaro release. What's the best way to select the architectures that you want to prepare this distroseries for? If there are many flavours of ARM, perhaps a list of architectures with checkboxes next to them could be overly long. Do you imagine that you'd know all the architectures you'll want to work with by name?
Peter: I would but I don't know that all these architectures are going to go back into Ubuntu. I think they're sticking with ARMEL. I don't think they'll do a distinct distribution for each flavour. You can have various versions of the ARM architecture -- V5, V6, V7 -- and I don't think any of those are going back into the main distribution. I think that anyone at this stage would know quite clearly what architectures they're dealing with.
Matthew: It wouldn't be too much of a burden to ask them to type it in.
Peter: Oh no, I disagree. At the moment we've got six entries. I don't think there are many more architectures in the bag. I can't see the drop-down being longer than about ten entries and I much prefer to select from a list than type, because I can't type.
Matthew: So, you may using a version that's hosted locally.
Peter: So you may be using an archive that's hosted locally. I still believe that the person doing the task will be familiar with the architectures, otherwise there's not much point in them doing the task. It may possibly be that their local archives have dropped several of these, so I don't think you'll ever have a very long list to pick from, so I think a drop-down will be much better.
Matthew: Does the term packageset mean anything to you?
Peter: No but it a good concept that I'd like to have, in the sense that this is one of the tasks that we're interested in that there would be a considerably reduced distro that we're picking from, because it's of a smaller size. I'm assuming that a packageset would be something a bit like a seed, which I'm not quite yet familiar with, a list of packages.
Matthew:' What is the best way to choose those packagsets? It'd be too long to have a list with checkboxes. At the moment, we're looking at having a search box.
Peter: Yes. It'd also be handy if somewhere you can access the complete list because you don't anything to type into the search box.
Matthew: Coming to the end of this mock-up, copy options.
Peter: Typical user question here: would it be possible to have a drop-down list of your last choices or something like that? That saves it from being tedious to keep a repeated action going.
Matthew: Do those copy options make sense to you?
Peter: Here's my take on what the difference is: in one you copy the source and the you rebuild and you add those binaries that you've just produced to that source and you get a distribution and in the other you just copy the source and binaries. I would say "copy source and rebuild" and "copy all", or something different, that doesn't say "source", would make more sense.
Mock-up 2
Matthew: This is a side box that would appear on the overview page of the derived distroseries. It's a summary of how the derivative is moving away from the parent. Do those three phrases make sense to you?
Peter: I always have this trouble that a package can either be a source package, that ends up with several binaries, or a binary package. We're talking about source packages probably here all the way through. I'm selecting source packages and although I get the binaries I don't know anything about what the binary packages are called. So long as we're talking about source packages I can follow [mock-up 2].
Mock-up 3
Matthew: When you read the heading here, is that straightforward?
Peter: Yes, I think that's nice. It identifies the parent, which is useful.
Matthew: Now, "there are currently 5 update Lucid packages that are being ignored". That implies that you or someone else has previously chosen to ignore some differences. Is that clear?
Peter: I'm beginning to get to it now, I think. I suspect that what you want is something ... "There are 5 updated packages that you have chosen to ignore". Something that implies that it's something that's under my control or that is under control from this site [Launchpad]. Perhaps just saying "that have been purposefully ignored". There might be a better term than "ignored", perhaps. "Not incorporated" or something like that.
It's the instrumentality, the intention, the fact that someone's done it as part of this process that we're doing, that's what... Anyway, you get it.
Matthew: There's a table of packages that have differences between the two. Could you look at each of the columns and let me know if they make sense.
Peter: What's the difference between request and view?
Matthew: The diffs are produced asynchronously.
Peter: I'm getting upset that I can't ... how do I know which packages I chose to ignore?
Matthew: Clicking the link above will show those packages only.
Peter: Can I assume that, because I can't see any difference between those than I can see, that none of those are the ignored ones? Would the ignored ones have a highlight or would they not show up at all? I'd rather that they showed up and were highlighted in some way and that there was an option to hide ignored packages. A facility to have them in the list while you're looking at the other ones would be helpful. Or some clue as to whether to ignore the next ones because you've ignored the ones before.
Matthew: "No local changes", does that make sense to you?
Peter: Yes. I think that means that the Ubuntu one has been updated, we haven't found any reason to change it here, so I would sync it almost automatically.
Mock-up 4
Matthew: Is the description at the top clear?
Peter: So long as it means that I haven't chosen them in the past, not that they're new, then yes that's quite clear.
Matthew: "There are currently six new Lucid packages..."
Peter: I'm a bit confused there. If they're new packages, how can I have ignored them? If they're new packages I haven't had a chance to ignore them. I create a derivative, then I ignore some packages, when I come back they've added some packages to the parent series that I'm not aware of but I haven't ignored them because they're new. That could just read "There are six new Lucid packages".
It's all clear otherwise.
Mock-up 5
Matthew: Is this page clear to you?
Peter: That's all clear.
Matthew: I understand Linaro will, as often as possible, merge back into the parent.
Peter: Yes, we want to diverge as little as possible.
Matthew: Would this page help you track that?
Peter: Yes, it's helpful. I presume if click the link I'll get a process guide.
Matthew: That's the end of the mock-ups. Any further comments?
Peter: No, so long as you send me some links about series.
Colin Watson
25th August 2010 |
Canonical |
(audio) |
Mock-up 1
Colin: So the first thing that comes to mind is, let's say you're creating a new Linaro series, called Nasturtium, this is going to be derived from ... it counts as two parents, there's Linaro M and Ubuntu Natty. There's a note here saying that if there's already series for the derivative distribution then you don't get to pick a parent distribution and series. It would sort of make sense the other way round, in that the parent Ubuntu series was something you got to merge from, with something like merge-o-matic. We don't reconstruct Ubuntu from scratch on top of a new Debian series, even though we have that general goal. Different derivatives may vary in how much they want to enforce that goal.
That's one thing that seems a little odd. It would be nice, informationally, to say what your parent is, even if you have a previous series. I don't know what the mechanics of the back-end would be.
If we're going to provide facilities for people in Launchpad to merge from Ubuntu, then it seems it'd be useful to know where you're going to merge from. Although, in the process of creating the new series your immediate parent is the one you're going to copy all the packages from.
Matthew: Are you familiar with the term "packageset"?
Colin: Yeah. I was part of the design of that. I'm interested in that because I drive the process of managing packagesets in Ubuntu at the moment.
I'm not quite clear what ... I think there's an ambiguous meaning of packageset here. What I suspect it actually means is that you copy the data structure and database fields that let you list sets of packages. What some people might think it means, and maybe what it does mean, is that you only copy a limited set of packages and the set of packages that you copy are listed in those packagesets. I don't know which it means.
Matthew: Are the copy options clear to you?
Colin: They're clear to me but I know which operations that correspond to. Let me try to put aside that previous knowledge. I guess what's missing is why you might want to do either.
Matthew: Would a pop-up help link be okay?
Colin: Yes. I think the terms are as concise as the can reasonably be.
Mock-up 2
Colin: Is mock-up 2 a portlet?
Matthew: Yes, on the overview page for the derived distroseries. Do those three bullets offer you the information you need to monitor how far it's deriving from the parent?
Colin: Yes I suppose so. Let me just pull up something else for comparison. There's something on merges.ubuntu.com that's kinda similar. merges.ubuntu.com gives a graph of how it's changed over time (https://merges.ubuntu.com/main.html). Down at the bottom of that page we have the graph and that might be a useful visualisation. The Ubuntu graph isn't quite as informative as it could be, particularly as it splits the graphs into components, which isn't quite as ideal in some ways. But also because there's also that great big local slice, which corresponds to language packs. The other slices of the chart correspond to ... you need to know a certain amount about the versions scheme. It's a three-way merge essentially.
So, that's perhaps one thing that'd be useful. You want to know, as well as "is this package the same or not?", it's useful to know if s the next upstream version has changed.
Colin: There are three categories. Among my categories we have the packages which have been changed in derilucid, but lucid hasn't changed. You just have a straight branch off derilucid but you don't have anything else to do. The second category is something's been changed in derilucid but there is a divergence from the changes in lucid and someone needs to decide what to do with it. The third presumably are things that would show up in local pacakge diffs. No, not quite.
Okay, there are two sets of things that you are showing in mock-up three here. The things that are changed in Derilucid that have been changed in Lucid and the things that have not been changed in Derilucid which are changed in Lucid.
In the graph on merges.ubuntu.com these correspond to merge and sync. So, maybe that terminology ... I think you probably want something more explicit than merge and sync.
I think sync is a verbatim copy, whereas merge is manual.
You have three categories, packages that are changed in the derivative but there are no changes in the parent. There are packages with divergent differences. And you've got packages that have changed in the parent and need to be reviewed for syncing into the derivative.
It would also be interesting to know if packages have been removed. That would be a little complicated.
Mock-up 3
Colin: Bit of a wall of text. One thing that we put on the Ubuntu merges page is the last uploader. It's quite useful for visual scanning because brains seem to be optomised for reading named and it's very easy to spot your own name as the last uploader. We also use it as an informal locking mechanism, if a person's name is listed as the last uploader they have first refusal on doing a merge, which helps when there are a lot of merges to be done. I don't know if you could fit this in here.
Matthew: Could we free space by removing the "Last common version in..." column?
Colin: I think that's a very useful field, actually. Partly because, well ... I said that because I was going to ask where it was until I saw that it was in fact there. Strictly, it is derived information: you can work it out from inspecting the other versions. The point where you can't work it out so well is where both have uploaded a new upstream version. Let's take the first row in the table: if the Derilucid version was intead 1.16-0derilucid1 or something, which would correspond with the derivative distribution having gone ahead with an upstream change in advance of Lucid, then Lucid catching up later, then that would be quite a complicated thing to merge, so it's useful to see that. You might be able to represent it more compactly, though, than that.
Matthew: Do you need to see it all the time or could it be a mouseover?
Colin: Yeah, I think a mouseover might be okay. Or possibly a "more information" toggle. I can imagine it working okay either way.
Matthew: Above that there's a line of text saying, "There are currently 5 updated packages..." What does that mean?
Colin: I've absolutely no idea. Is it explained in a later mock-up? I don't see it. I can guess. You often want to say, "No, we never want to merge this from the parent." We have a bunch of things in Ubuntu that we never want to merge from Debian because we're handling them completely ourselves. The kernel is a good example. It's not really useful to show those [ignored packages] on this page.
So, the difference between "Ignore this version of this package", i.e. we don't want to merge this right now, and "Ignore this package forever more Amen." That difference isn't clearly on this page.
The other thing that strikes me as odd is that it says, "Clicking on this link will filter to show only ignored packages", which sort of implies that ignored packages are shown normally as well. Is that just that the Post-it is odd? I guess you wouldn't want to show ignored ones.
Matthew: Is "ignored" the right word?
Colin: Yeah. We tend to use the word "blacklist". That's for an entire package, all versions. I think "ignore" is okay but some nouns would help, like "Ignore this version".
In Ubuntu, we sync lots of things from Debian automatically and we mark them as "can't sync automatically" if they have the string "ubuntu" in their version. The only technical effect of seeing "ubuntu" in the version string is that it inhibits automatic syncing from Debian. I wonder if this is a useful facility to provide to derivatives. It's very useful during development to be able to say, "Just keep us up to date with our parent unless things require merging."
Matthew: So you'd be able to specify what string to look out for in the package name.
Colin: Exactly. That would of course require some back-end facility to do the automatic sync every so often. If that's not being provided, fine. I think it may be helpful to offer that, to think about that facility in respect to mock-up 1.
Mock-up 4
Matthew: This is relates to the second link in mock-up 2's portlet. Is it obvious what this page is for?
Colin: [Express concern that the title doesn't easily tie up with the portlet link text.] This could be a result of trying to cram it down into as few words as possible.
It does make sense but I found I had to think about it a bit to get it to make sense. It might be okay since the heading clarifies.
It's good to have it match up with the URL, which means it would be best if it didn't have "In Lucid but not..." in the title, otherwise the URL would change with every release. I suppose you could have something like "Missing packages from parent" and "Unique packages here" or something similar.
Matthew: On this mock-up, we have "There are six new Lucid packages that have been ignored". That has caused confusion to other people.
Colin: It's the same as the one in mock-up three, really. Again it could do with some nouns. Well, there are nouns but you know what I mean. [Reads text aloud]. "That have been ignored and will not be synced" or "will not be synced unless you take some kind of affirmative action". I think it could do with leading into a paragraph on what ignoring is.
Matthew: I think the word "new" has confused people previously.
Colin: I don't find that confusing. I took it as meaning things that are new in Lucid relative to Derilucid.
Matthew: How could someone ignore something that is new? That implies you haven't seen it in order to ignore it.
Colin: I see. I didn't suffer from that confusion myself. You might reasonably say there are currently six Lucid packages that have been ignored for inclusion in Derilucid, or something. It seems clear to me that it's referring to the paragraph above. I can sympathise with the confusion.
I think the need for comments is less in mock-up four than in mock-up three. It's not something that tends to involve terribly expensive thought, so if you find that you're running out of space on that page then the comments probably ought to be the first to go. In mock-up three it's very useful, though.
One other question: I'm confused on both mock-up 3 and 4 I'm confused about the purpose of the tick-mark next to the sync and include buttons.
Matthew: I believe it's to enable you to select all, assuming the table's rather longer than three entries.
Colin: I understand, yes. I'll pass on that it's not clear in the mock-ups. I've seen that on other Launchpad pages and not been confused.
Mock-up 5
Colin: So, mock-up five is purely informative and gives you no actions to take. That makes sense.
Matthew: Although it does give you a link to help.
Colin: What's the link there, "getting packages included"?
Matthew: It's to something that we haven't written yet.
Colin: A help page.
Matthew: At this stage, yes. I believe a longer term goal is to offer some way of requesting a merge back into Ubuntu.
Colin: The "Show packages containing" fields. Do those filter by name or by description or both? Looking at this, I would expect that mock-up 5 would be both for 3 and 4 wouldn't because they don't show the description in the UI. I think it might be better to search only on the package name.
Matthew: Do you have any general comments or questions?
Colin: My questions would be more about the back-end. For example, does the process of creating a new series do all the UCA [?] you have to do to the previous series to mark it as released or is that something we don't want. For example, when we create a series of Ubuntu we change the release manager of the previous series to Ubuntu Core Dev, we make sure that the previous series is marked as current stable release, we create a milestone in it ... there are a bunch of little things that we need to do. I'll just give you the link:
https://wiki.ubuntu.com/NewReleaseCycleProcess
I think we'd automate this if it happened more than once every six months.
We have to do thinks like shut down Soyuz when we initialise the new series. There are lots of "Notify person" to-dos. It would be worth someone looking through that to make sure than anything that can be automated is for Linaro.
One thing mock-up 3 doesn't give you ... you have a diff from Lucid to Derilucid. It strikes me that that's not very useful. You want ... there are three diffs that you potentially want. You never really want a diff from the current version in Lucid to the current version in Derilucid unless one of those is also the common version. Otherwise you have this unreadable diff. The things you do want are the diff from last common version to Lucid, last common version to Derilucid and potentially a suggestion on what the merged diff might look like. You might not need the third because maybe everyone should be using Bazaar.
If you're going to have a column of diffs, it should be diffs from each side from the common version.
The mock-ups
Mock-up 1
Mock-up 2
Mock-up 3
Mock-up 4
Mock-up 5
