LEP/DerivativeDistributions/UserTestingRound1

Not logged in - Log In / Register

Launchpad derived distribution mock-up testing round 1

James Westby

28th July 2010 (audio)

Creating a new derived distro series

Imagine you've come to register a new derived series, what are you first impressions of this page?

It looks pretty familiar from other Launchpad pages. Plenty of boxes. Well laid out. Tend to say what's optional and what's not, although on this page I'm not sure what is and what isn't. The explanations beneath each box, name, title and display name...

Is the distinction between those familiar to you?

It is from other parts of Launchpad. The distinction is that common on other sites but it is on Launchpad.

Do you know what the difference is?

From experience of other parts of Launchpad, yes. The “registering a project” one is pretty good because beneath it says “A short name to be used in URLs”, display name “To be used in a paragraph” … so taking those explanations from the project registration page would be a good idea.

If you were coming from one of our Linaro partners, name, display name and title wouldn't be obvious to you from this page?

No, I would appreciate more description of what they meant.

If you were to add a new series to a distro and wanted to initialise it from its parent series, would you know what that means?

No, I don't think I would.

When it says parent distro or series on this page, does that mean something to you?

I want a little bit of description. Parent distro and series would be self-explanatory but “Initialise from...” means absolutely nothing to partners. I could take a guess. I'm not even sure it should be there. I think it might want to default to on but that would require some more options, I think. I'd want to know exactly what it did before clicking it.

There's a version text box above. How does that differ from the title, display name etc?

I'm not sure. It says “The name of the derived distroseries” underneath but I think that may be a copy-paste error. A lot of our partners won't have version numbers for their things, it'll be a single-shot release and they won't want to make a version for it. There will be places where it's wanted, so I can see it's value, but it needs a description of where it's used. I don't think it's used particularly for anything.

Further down the page is a text-box asking you to define which architectures you want to work with. Is a text-box a good way of asking for that input?

I don't think it is. The comment beneath says, “The architectures in the parent that will be...” so you have a restricted set of a architectures already. Checkboxes seem more appropriate, if you can only pick architectures that are in the parent. They aren't going to know what they can put in there. So, either checkboxes or just some text saying what the valid choices are.

Does the term “packageset” mean anything to you?

It certainly means something to me. I think the name is reasonably self-description. It might warrant a little pop-up help. I think what would be useful would be a list of the available packagesets, using some sort of picker. It'd be useful to see which ones are available and what their descriptions are or what packages they contain. Most people aren't going to know which ones they want to pick, so allowing them to pick from a list is best.

There might be restrictions on which combinations of packagesets you can choose, especially those depending on another, so I'd probably want it to make those choices for me. So, if I pick one that requires another packageset, I'd want it to pick that for me. Creating an invalid distroseries would be useless.

The final part of the page gives you copy options. Is it obvious what they mean?

Yeah, I think so. After reading them a couple of times, I think the meaning is clear. A paragraph of text could help with the understanding of people who aren't quite as familiar. I think the difference is going to be fairly well understood.

Is anything missing from this page?

Not off the top my head. I think access control, privacy and who can see/modify it, might be missing but that's probably something you can configure afterwards. Maybe a privacy checkbox on this page, so there's no period of exposure, might be the right thing.

Derived distro series info portlet

Is this what you'd want to see in order to get a quick glance of what the derived distro series is about?

Yeah. This is very useful information and this is the kind of information I'd want in that box. Some graphs would be cool so you can get a picture just by glancing at it. If the diversions were increasing sharply over time, you'd be able to see that [in a graph] out of the corner of your eye and that would nag at you a bit more than these numbers.

Clearly, the current number is a lot easier to provide than a graph over time.

Maybe two graphs, perhaps a pie chart with the current proportions and then a graph over time, so you can see if they're going up over time. We want to encourage our partners not to diverge too much. Once they diverge, we want our partners to merge back into the parent because that makes it more sustainable over time.

Are there any other numbers you'd want to see here?

I'm not quite sure what the last one means. “4 missing packages in cloned packagsets”, I think that means there's four packages in the parent that we haven't got. I want to see how many packages were modified but we havne't got those modifications. So, I'd want a fourth number.

When you click on these, what would you expect to see?

Summary pages of those differences. So, if I click “8 local differences” I'd want to see the changes that we'd made for those packages and the state in the parent.

Local package differences

Does this page give you what you want?

Yes, it does. Not entirely sure if upstream version is useful to see there. Well, it's linking, so yes it is. “No local changes”, I'm not sure what that's trying to tell me. But yeah, that's what I'd want to see.

Would you want to see a graph of package differences over time?

Yeah, if you have that information, putting it here would be useful. It's the main place where people would come to see the information.

Those three buttons, “Select None”, “Select All” and “Sync”, it seems a little unusual to put them together because there's two separate things going on there. “Select All” and “Select None” belong together but “Sync” is something separate.

Missing packages

Now, this next page is similar. Is it what you'd expect to see?

Yeah, I think I'd expect to see that.

Anything missing?

Erm, so I can click though to the version in the parent, so I can find out plenty of info there. What I might want to see on this page, I'm not sure what it would be, but would be some idea of how the package would fit into our distroseries.

I'm not sure what that would be. Maybe, if you synced would it have all its dependencies? That sort of thing. Maybe if foo depends on bar, perhaps … I'm not entirely sure what I mean by this by some idea of what the result of doing that sync into my distroseries would be.

Would it be useful on these sorts of pages to be able to leave a comment to explain, for example, why foo is missing?

That's a good point. It was added to Merge-o-Matic because people found it useful to be able to say, “Don't sync this one because it won't build”, so yeah that could be useful. Also, some way to say, “Don't show me this any more, at least in the default view, because I've decided I do not want this package”, is somethiong that some people would find useful. Perhaps there should be a way to see what those packages are so you can bring them back in. Comments on the previous page would be useful. Some way to make the line disappear from that view, “We don't want this version” or two options, “We don't want this version but we might want the next one” or perhaps “We don't want any new versions of this package, we just want to stick with this one.”

Unique packages

Is this what you'd expect to see?

I'd want to see some information about how I could do something about this. It's a useful status page but there's no next action.

I think the same goes for the previous ones, where you'd want a bit of text describing what it means for a package to be in this state and what you could do about it.

So, for this one I know they've [Soyuz guys] said there's not going to be scope in this cycle for automatic submission back into the parent, but a bit of text saying that it might useful to merge these packages back into the parent.

So, there's some sort of next action on this page.

For the previous ones, you have the sync options but there's no definition of what a sync is and it's confusing to people who aren't versed in this.

Some explanation of what a sync means, especially in the first of these click-through pages … some explanation that it overwrites your changes, so some explanation of what to do if you changes are valuable to you.

People may get annoyed if they sync and then find they have to re-do all their changes, so we need some explanation of how to merge the changes. It's a bit tricky to know if there's going to use bzr for that or have to do it manually.

That's the end. Do you have any other comments about what you've seen?Looks good. Just to make it clear, there's a fourth line missing from the derived distro portlet, and I think there's a fourth page missing too.

Mathias Gug

28th July 2010 (audio)

Creating a new derived distro series

What are your thoughts on this page?

I'm not sure what “Initalise from parent” means. Does it mean that all the packages are going to be copied to the new archive or … I'm not sure. Also, I wonder why is that a checkbox? Is that an option or not. If I want to create a derived series, I want to get started with the whole packageset, all the packages and then remove them. That's the only options I'm not sure about.

Architectures it seems to be a text box, might be more interesting to have a list of the different architectures that are available. I'm not sure that, if Ubuntu created a new architecture such as armel, I'd know about that.

Packageset to copy from parent … that's also a text box so I might have the same suggestion as architecture. How do I find out about the different packagesets that are available to copy?

Is any of the terminology on the page unfamiliar to you?

No, not really. Packagesets are a new term in the ubuntu community. I'm faimilar with because I've been creating the packageset for the Ubuntu server team.

At the very bottom, the copy options. Okay. I don't exactly why I would copy source and rebuild everything because, well, in ubuntu we don't build for a new series, we just copy the binaries over. Also, what is the difference between the copy options and “Initialise series from parent”?

The initialise series from parent, I don't understand what that means or why there's a choice.

Derived distro series info portlet

Do you understand what these three bits of information are?

8 local differences, I assume these are packages that are different from the upstream. 24 local packages … that means there are 24 new packages available in the derived distro. I would probably say “24 local packages not in Lucid”. The third … 4 missing packages .... I don't understand what is a missing package in a cloned packageset. Does it mean it hasn't built or maybe it means that they've been moved from the packageset. So, are the four missing packages included in local differences? Local differences is a bit … I don't know exactly what is meant by differences.

Is anything missing from that box?

No, not that I can think of.

When I want to get derived information from a more generic perspective, I want to know what has been added, what has been changed and what has been removed.

Plus, minus and what has changed.

Also, I'm not sure … derived does it only encompass the packages that are uploaded or are there also bzr branches?

I guess because it's Soyuz it's just about the packages. I wonder if bzr branches are also included.

What would you expect to happen if you clicked one of these links?

I'd like to have a list of the differences, or the 24 packages not in the parent probably with the name of the package, the source package, the version in the derivative and also the version in Lucid.

I would expect to have a list of missing packages in the cloned packageset

Local package differences

Does this page fulfil your needs?

Upstream version, I'm not sure what it means, whether it's the Ubuntu version or the upstream-upstream version. Especially, so for foo, the package foo version is 1.1.5. I don't know if that's the upstream version or the package revision (1.15). I would expect 1.15—ubuntu1 or something like that. Same comment for upstream version, I don't if it's the upstream version or the package revision. Base version, no local changes, so foobar … I assume that “Diff available” means I can directly click it and get it, otherwise “Generate diff” would take more time.

Sync means to copy the upstream version into this version. As for the column naming, the second column might be more interesting if it was named “Derilucid version”.

Third column I'd name it “Lucid version” so it's easy to know where we're coming from. Base version is a common term, so it's understandable.

Missing packages

So, here's what you'd get if you clicked on the second link in the portlet.

Okay, so the second link was “24 local packages not in parent”.

So, I would make similar comments on the column naming. I'd call it Lucid version. As I understand it, missing packages are packages that have been pushed into Lucid but are not in Derilucid yet. So, that would only happen if I derive from the development version. I don't know what the target use case is for derived distros but one use case I have in mind is that I want to derive a distribution for a stable release, Lucid for example. Yeah, I understand what it means.

The package foo, if I click on 1.1.5 I would be linked to the upstream 1.15 changelog. It might be interested to have a small expandable arrow so I can easily review what the changelog is, so when I perform the sync I want to know what's new in the upstream package. From a workflow perspective, it'd be good to be able to stay on the same page and see the differences that I've about to import into my derived distribution.

Unique packages

So, does this make sense? Is anything missing?

So, that's something I understand. So I wonder if these packages are brand new source packages, I think so.

Yeah, so packages in Derilucid but not in parent series are the new packages I've uploaded to my derivative but that are not available in the parent distro. That sounds like a useful page.

Earlier you said the link “4 missing packages..” wasn't clear to you. Now you've seen the page it leads to, can you think of a better way to work that link?

What made me understand it was the title, “Packages in derilucid but not in lucid”. So, the link should change to “4 packages in Derilucid but not in Lucid”. Just use the page title as the link text. The titles are quite obvious what they're talking about.

8 local differences might be too long but at least for the second two links in the portlet, just use the page title.

'Would it be helpful to have tooltip on the links, if the full description was too long?

I rarely use tooltips.

The wording of the second link, “24 local packages not in parent”, I'd called it “24 local packages not Lucid”. And then “4 missing packages in Derilucid”, that might be more meaningful.

'Do you have any other comments on what you've seen?

No.

A really useful changelog entry is to have the changelog entry between the base version and the upstream version, for local package diff, so I know what has changed in Lucid so I can import it directly into Derilucid. For the missing packages page, when I want to sync the new upstream version, I want to see what has changed between the version in Derilucid and that in Lucid.

Didier Roche

2nd August 2010 (audio)

Creating a new derived distro series

Okay, let's imagine that we have a distribution that is derived from Ubuntu, called Deribuntu, and you have the task of creating a new distroseries in this derived distro and you want to derive that new series from Lucid. This is the page that you'd come to. Can you have a look over this page and tell me if it makes sense to you?

Okay, so you have the name of the series ... so, for instance, let's say Ubuntu was derived from Debian we would have as the name "Ubuntu 10.04" and the series name "Lucid", right?

Yes, if this was looking at Ubuntu being derived from Debian but, in this case, we're looking at deriving from Ubuntu.

So, it's a derivative not a new flavour?

Yes, an entirely new distribution that would be available, for example, to one of our Linaro partners.

Okay, hmm mmm. So, summary description, version... So, you choose a series for the parent. Okay. What is "Intialise series from parent"?

I can't answer your questions really. I need to find out if this makes sense without having someone there to answer questions. If it's not immediately obvious to you...

It's not.

...then there's a problem with the design. So, what would you imagine it means?

For me it will just take what we have in the parent distribution and try to rebuild in the architectures that are below and so it will rebuild everything but I think ... why I'm not sure, it was obvious that first time it would do that. You're creating a new derivative and it will build everything. So, that's why it's not obvious for me.

Let's ignore that option for a moment and come down to "architectures".

Packagesets? So I think that means that the parent has some packagesets, for isntance desktop, foundation and stuff like that, and you just want to copy some packagesets. Okay, so you have "Copy Source and Rebuild" and "Copy Source and Binaries". So, that's okay, I think that makes sense, it's like if you want to rebuild or just to copy.

Are you familiar with what packagesets are?

Yeah, hmm mmm.

Before we move onto the next mock-up, do you have any comments on that page?

No. It's only "Initalise" that I don't understand because, for me, it should, if it's what I told you first, it should be checked by default. I don't see any reason for that to be unchecked, with my definition.

Derived distro series info portlet

Okay, let's scroll down to the next mock-up, a small box, a portlet a side-box on a page. You'd find this on the overview page of a derived distro series. Does that make sense to you?

8 local differences, it makes sense. If it's patched sources package that you have changed locally and not in the parent distribution. 23 local packages not in parent, so it's new packages you have added to your derivative. 4 missing packages in cloned packagesets, so there are four packages that have appeared in the parent distro and that are not copied in your derivative.

So, I think it's pretty clear. I think that, in this case, you'd take all the mappings. For instance, if the derivative has a different name for a package, I don't know if you have some sort of mapping for that.

I don't know. Would that be useful?

That can be useful. We have that between Ubuntu and Debian so I guess ... no, no, it's pretty clear.

Local package differences

Now, if you were to click on that first link it will take you to the page below.

I'm not sure about the diff: I would think the diff is between the current version and the base version but in any case if you want to merge you need a diff between the current version on your derivative and the base version, between the upstream version and the base version, and between also the version and the upstream version. So, you need three diffs to make a proper job.

So, I think that as there is a diff available and "generate diff", it's in process and you would request a diff and then you would get it and once you get it it would not compute again. So, "sync" is a check-box. I'm not quite sure because ... so, you have a check-box and then you act on the same button, I guess. Yeah, so I think that when you load the page the sync check-box is never checked. I don't find that clear, in fact I would think you'd have one button/link on each line and then ask for each package, not a button at the end.

Any other commments before we move on?

So, you have the "No local change". You have, for Biff, version 1.5 and upstream version 1.6 and "No local change". So that will mean that it's 1.6 as well? Err, I guess that yes. No local change in the base version for Biff is that we have 1.6. If this is the case, I'd rather see 1.6 as the base version.

Missing packages

Let's move onto the next mock-up. This is what you'd get if you clicked on the second link in the portlet we saw earlier. Does this make sense to you?

It makes sense but, as for the previous one, I'd prefer the sync was an ajax link on each line, so you can click on it and sync just like that.

Unique packages

So, let's move onto unique packages. Does this seem to make sense? Is anything missing?

Everything we want that Lucid gets that package too, I don't know how it can be done. Maybe a button. Just one question, when you make a derivative, does it mean the parent is also on Launchpad?

Yes.

Okay, so, I would think that there can be a button that opens a bug report that says we have that package in that distro and maybe it would be useful for you in your distribution, with the diff and source package.

I understand there'll be some method in the second round of this feature. Okay, well, we've looked at all the mock-ups now. Do you have any general comments?

So, when you click on whatever package it is for the version, you'll get to the package page like we have today. There doesn't seem to be a lot of paperwork to do for that. Perhaps when you request sync, perhaps there could be a page that shows you the state of the packages, the ongoing transition. So, you ask for a sync and you want the sync so maybe there could a page that shows you that. Apart from that it's pretty clear. I don't think there's a lot more that can be done as an info.

LEP/DerivativeDistributions/UserTestingRound1 (last edited 2010-08-04 11:03:44 by matthew.revell)