Re: [Launchpad-dev] RFC on build from branch UI
On 3 February 2010 20:58, Aaron Bentley aa...@canonical.com wrote: Michael Nelson wrote: The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. So are we sure that building from a recipe should be a user-level thing at all? It seems like a major use case will be build this branch using this packaging branch. If we had a UI that just provided that, what percentage of our users would still need more? Aaron IMHO it would be 50/50 split cause I'm still thinking in terms of packaging branch as the starting point and which branches do I want to build using it. For example as an upstream project maintainer I will strive to minimize amount of packaging branches / recipes cause that's not usually upstream expertise. So I would have one packaging branch possibly pinched of ubuntu and then I will go to it and start thinking which of my project branches I want to build eg. stable release, supported release and this wacky hack I'm working on. And ooops hardy has different lib sonames so i need to use this other packaging branch cause it has build time patch. So again I would go to hardy packaging branch and say oh yeah do just the stable branch cause I really don't want anyone to develop latest features with out-of-date libs for example. This feature will be a popular both from Ubuntu development side and the upstream projects using launchpad for project management, QA / ubuntu experience enhancement. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Tue, 02 Feb 2010 23:01:49 Michael Nelson wrote: https://dev.launchpad.net/BuildBranchToArchiveUI Hi Michael, Firstly I think you have done an awesome job with the UI mock-ups. I talked with Michael Hudson today, and here is the summary of what came up. I'm not expecting you to answer all of these, but to give us notes to work from. We agreed that it is important to focus on the initial workflow of creating a new daily build of a branch into a PPA. We realised that we are missing the schedule information for the recipe itself in order to support daily builds properly. We are missing any form of UI mock-ups for the branch page itself. What changes on the branch page when a new build has been requested? How are we going to show builds in progress? What if the user wants to remove a daily build? Or just disable it? Is it really feasible to share recipes? When wanting to build into a PPA, what are we really accomplishing by choosing someone else's recipe? We are likely to have multiple recipes for each branch that is being built daily as we are going to target multiple distroseries. Am I right on this assumption? We will want some general recipe oriented views later, but what we have is a good start. Tim ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
Tim Penhey wrote: On Tue, 02 Feb 2010 23:01:49 Michael Nelson wrote: https://dev.launchpad.net/BuildBranchToArchiveUI Hi Michael, Firstly I think you have done an awesome job with the UI mock-ups. I talked with Michael Hudson today, and here is the summary of what came up. I'm not expecting you to answer all of these, but to give us notes to work from. We agreed that it is important to focus on the initial workflow of creating a new daily build of a branch into a PPA. One part of the mock up I was a bit uncomfortable with was the view details section of selecting a recipe. It seems as if this allowed editing the recipe -- if this is the case, I think it's a bit wrong. The dialog that lets you edit a recipe should have a button labelled Save at the bottom of it, not build, to emphasise that one is editing a shared resource, not something specific to this build. So perhaps the workflow should be select recipe, edit recipe, this pops up another dialog, save, goes back to selection screen with edited recipe selected, then click build. I think James already said something like this. Cheers, mwh ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Sat, 06 Feb 2010 06:58:27 Aaron Bentley wrote: Michael Nelson wrote: Oh, I was under the impression that wasn't possible/allowed from an LP app server. Not directly, no. We don't allow it right now, but there may well be some cases where we allow it, like setting a branch to be append only. We don't really want the app-servers being tied up with slow branch access, especially when the current page load times are absurdly long already. Tim ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
So yes, I agree that it'd be great to send manifests to the buildd rather than recipes (as it guarantees what will be produced), and I assume we can do this as the only missing information would be the tip revision which we have in the db (IBranch.last_mirrored_id?), although, are other calculated revisionspec's allowed for branches in a recipe? (ie. last:3) If so, then I guess we can't calculate the manifest to send to the buildd? Maybe Michael H. can confirm? If it is something we can do, I'll create a bug for it too. It would be hard to do it in the appserver, though there are always ways, but doing it in the buildd-manager seems possible. I guess by specifying dotted revnos and so on you can make generating the manifest fairly expensive and so risk slowing things down... but not much more than everything else in this system (I mean OO.org is almost DoS in itself :-p) Cheers, mwh ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Thu, Feb 4, 2010 at 7:06 PM, Aaron Bentley aa...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Nelson wrote:
On Wed, Feb 3, 2010 at 9:58 PM, Aaron Bentley aa...@canonical.com wrote:
It seems like a major use case will be build this branch using this
packaging branch. If we had a UI that just provided that, what
percentage of our users would still need more?
I think people need (and want) more than just the packaging branch.
For example, they'd want to specify the distroseries as well
Doesn't a user actually want to specify a list of distroseries you want
to build for? And don't you need a recipe per distroseries as currently
formulated?
Yes, that would be great, and given that we've got a distroseries
field on the SPRBuild as well, we *could* actually create separate
SPRBuilds from the one SPRecipe (bug 513201). As James noted, it's not
the most efficient way - it would be better if soyuz could do some
magic and build the source once and tweak it for multiple
distroseries.
I haven't yet added any mockups showing this. I'll try to do this today.
If so, our UI should let them choose a list of distroseries
and create as many recipes as necessary behind the scenes.
by which
time, the concept of a recipe for your build makes sense (ie. you've
got a few ingredients).
I don't think that follows. Recipes are only somewhat specific to
packaging. Providing a UI that was less generic and more
domain-specific could be quite helpful.
I don't think I understand. As far as I can see, everything (except
the recipe name) that we're asking for on these mockups:
http://people.canonical.com/~michaeln/bfb/build_now_overlay_without_recipe_structure.png
is required to create a build (whether you mention recipes or not)
(See below about the package name). That is, distroseries selection,
deb version and the packaging branch.
And I would have thought it would be useful to be able to re-use that
information next time I want to do a build, and the most obvious way
to do that is to save it as a recipe with a name that makes sense to
me (foo_branch_with_my_packaging).
Of course, we could instead just present by default the last
information entered by the user, but this would obviously not always
work.
Aside from that, it would mean that other people couldn't benefit from
being able to see what recipes are available for a branch and re-use
them (especially if we flooded the recipe table with new recipes for
each build).
On top of that, I don't see how we can guess a
valid deb version (as it depends on what's been uploaded to the PPA
before etc.
Surely we know what's been uploaded to a PPA before? Anyhow, that's a
domain-specific thing, not necessarily a recipe thing.
Yes we know what's been uploaded before (sorry, I should have
qualified that), but that doesn't help us to specify a *re-usable* deb
version string like 1.0+{revno}-{revno:packaging} (which we can't
necessarily evaluate)
Now I'm guessing your point would be, if we instead got rid of the
recipe interface and just allowed the user to specify a build, we
don't need to support re-usable deb versions strings and that's true
as long as we don't want the same interface to support daily builds.
I might try to organise a time to call and talk more about that. I'm
still not sure how that would allow us to guess a valid deb_version
for a single build (that is, incrementing the latest version published
in the PPA might not be what you want). But maybe there is a way to do
this in a sane way?
And we can't always know the package name from the branch
either [1].)
I thought the debian control directory specified the package name.
Yes they do, hence the bug Recipe requires sourcepackagename before upload
https://bugs.edge.launchpad.net/launchpad-code/+bug/515581
It would be nice if the sourcepackage name wasn't required when a
recipe is created, but as I understand it, the URL traversal that was
previously decided on requires it:
(code?) ~owner/distro/distroseries/sourcepackagename/recipename The
canonical traversal for displaying/editing a recipe.
Maybe that needs to be re-thought? Or those who made that decision
might be able to comment. As currently this could lead to users
unintentionally changing the sourcepackagename from what's specified
in the packaging branches changelog.
Without this, we could certainly drop the *requirement* for the
sourcepackage name when creating a build/recipe. At the moment the
best we can do is hide the field when we already know the source
package name (via the product series packaging entry?).
(Of course, although it doesn't need to be required, it should still
be available as it is an option that we can pass through to dailydeb
to *override* the value in the changes file.)
And even if the above was feasible, we'd still need to create a recipe
to do the build
Absolutely. I never meant to suggest otherwise.
and so when the same user comes back next time
Re: [Launchpad-dev] RFC on build from branch UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Nelson wrote: On Thu, Feb 4, 2010 at 7:06 PM, Aaron Bentley aa...@canonical.com wrote: Doesn't a user actually want to specify a list of distroseries you want to build for? And don't you need a recipe per distroseries as currently formulated? Yes, that would be great, and given that we've got a distroseries field on the SPRBuild as well, we *could* actually create separate SPRBuilds from the one SPRecipe (bug 513201). As James noted, it's not the most efficient way - it would be better if soyuz could do some magic and build the source once and tweak it for multiple distroseries. I guess I fear that source packages built from the same recipe on multiple distroseries can legitimately have other differences, and that this could be lost. But this is not my domain. I don't think that follows. Recipes are only somewhat specific to packaging. Providing a UI that was less generic and more domain-specific could be quite helpful. I don't think I understand. As far as I can see, everything (except the recipe name) that we're asking for on these mockups: http://people.canonical.com/~michaeln/bfb/build_now_overlay_without_recipe_structure.png is required to create a build (whether you mention recipes or not) (See below about the package name). That is, distroseries selection, deb version and the packaging branch. Right, and we may be in furious agreement. Bear in mind that I was looking at these mockups: http://people.canonical.com/~michaeln/bfb/build_now_overlay.png I haven't seen your new mockups 'till now. Your new mockups hide the recipe, showing only domain-specific fields. Your old ones showed a generic interface where a packaging branch was only implied, not specified. In the new interface, the user doesn't see any recipe commands, and the packaging branch is referred to as a packaging branch, not as an arbitrary branch to be merged. That's very much the sort of thing I was proposing. So the difference remaining is that you still have users editing recipes, though usually indirectly, while I would generate the recipes dynamically from settings like the ones you show. And I would have thought it would be useful to be able to re-use that information next time I want to do a build Sure, and I was already saying that would be a good idea. and the most obvious way to do that is to save it as a recipe with a name that makes sense to me (foo_branch_with_my_packaging). I remain uncertain that recipes are as flexible as we would want for this. Your bug https://bugs.launchpad.net/bugs/516496 suggests that as currently formulated, they specify too much by having revision specs. If we were to look at your build this revision scenario with a UI that didn't directly edit recipes, launchpad would generate the necessary recipe behind the scenes and use that to do the build. Aside from that, it would mean that other people couldn't benefit from being able to see what recipes are available for a branch and re-use them (especially if we flooded the recipe table with new recipes for each build). I was proposing storing the domain-specific values, rather than the recipes, and that would be something others could reuse. Now I'm guessing your point would be, if we instead got rid of the recipe interface and just allowed the user to specify a build, we don't need to support re-usable deb versions strings and that's true as long as we don't want the same interface to support daily builds. No, I definitely want our solution to work for daily builds. I actually think specifying a template deb version is fine. And we can't always know the package name from the branch either [1].) I thought the debian control directory specified the package name. Yes they do, hence the bug Recipe requires sourcepackagename before upload https://bugs.edge.launchpad.net/launchpad-code/+bug/515581 Okay, but doesn't that still contradict your statement that we can't always know the package name from the branch? It would be nice if the sourcepackage name wasn't required when a recipe is created, but as I understand it, the URL traversal that was previously decided on requires it: (code?) ~owner/distro/distroseries/sourcepackagename/recipename TheSo canonical traversal for displaying/editing a recipe. There are probably ways we could get around it, e.g. by looking at the contents of the package branch while creating the recipe. Not sure there's value in that. If we're not exposing recipes, why should the user care about duplication? Yes, it would be nice to remember past settings, but again, that doesn't require recipes per se. As above, I'm not sure how it wouldn't require saving the set of build inputs with a user-specified name so they can re-use it (which is what we've got with a recipe). It would require that, but instead of a recipe, it would be entirely domain specific, and would fit our needs exactly.
Re: [Launchpad-dev] RFC on build from branch UI
On Fri, Feb 5, 2010 at 3:58 PM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Nelson wrote: I don't think I understand. As far as I can see, everything (except the recipe name) that we're asking for on these mockups: http://people.canonical.com/~michaeln/bfb/build_now_overlay_without_recipe_structure.png is required to create a build (whether you mention recipes or not) (See below about the package name). That is, distroseries selection, deb version and the packaging branch. Right, and we may be in furious agreement. Bear in mind that I was looking at these mockups: http://people.canonical.com/~michaeln/bfb/build_now_overlay.png I haven't seen your new mockups 'till now. Your new mockups hide the recipe, showing only domain-specific fields. Your old ones showed a generic interface where a packaging branch was only implied, not specified. They're just a few alternatives to discuss atm.,, I added that one after Martin's email earlier (you can see them all on the wiki page). I remain uncertain that recipes are as flexible as we would want for this. Your bug https://bugs.launchpad.net/bugs/516496 suggests that as currently formulated, they specify too much by having revision specs. Yes, I'm guessing we'll be tweaking the backend implementation as we start trying to use these. MichaelH did a great job getting all the model code into trunk, but it'll take time to settle (IMO). Aside from that, it would mean that other people couldn't benefit from being able to see what recipes are available for a branch and re-use them (especially if we flooded the recipe table with new recipes for each build). I was proposing storing the domain-specific values, rather than the recipes, and that would be something others could reuse. I see, like *storing* a 'packaging_branch' attribute, rather than the parsed SPRDataInstruction that contains the merge instruction. That might be worthwhile bringing up in your team. Now I'm guessing your point would be, if we instead got rid of the recipe interface and just allowed the user to specify a build, we don't need to support re-usable deb versions strings and that's true as long as we don't want the same interface to support daily builds. No, I definitely want our solution to work for daily builds. I actually think specifying a template deb version is fine. I thought the debian control directory specified the package name. Yes they do, hence the bug Recipe requires sourcepackagename before upload https://bugs.edge.launchpad.net/launchpad-code/+bug/515581 Okay, but doesn't that still contradict your statement that we can't always know the package name from the branch? Not that I'm aware of... when we create the SPRecipe, we need to supply a sourcepackagename, and at that point-in-time, the only guaranteed place where I can get that information is the changes file, which I *thought* I didn't have access to from LP (until it's uploaded after the recipe build succeeds). But let me know if I've mis-understood something. It would be nice if the sourcepackage name wasn't required when a recipe is created, but as I understand it, the URL traversal that was previously decided on requires it: (code?) ~owner/distro/distroseries/sourcepackagename/recipename TheSo canonical traversal for displaying/editing a recipe. There are probably ways we could get around it, e.g. by looking at the contents of the package branch while creating the recipe. Not sure there's value in that. Oh, I was under the impression that wasn't possible/allowed from an LP app server. If we're not exposing recipes, why should the user care about duplication? Yes, it would be nice to remember past settings, but again, that doesn't require recipes per se. As above, I'm not sure how it wouldn't require saving the set of build inputs with a user-specified name so they can re-use it (which is what we've got with a recipe). It would require that, but instead of a recipe, it would be entirely domain specific, and would fit our needs exactly. OK, I guess that's a great point to pick up on a phone conversation on Monday (so I can understand exactly what would be different from what we're currently displaying). Thanks Aaron! ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Nelson wrote: On Fri, Feb 5, 2010 at 3:58 PM, Aaron Bentley aa...@canonical.com wrote: I thought the debian control directory specified the package name. Yes they do, hence the bug Recipe requires sourcepackagename before upload https://bugs.edge.launchpad.net/launchpad-code/+bug/515581 Okay, but doesn't that still contradict your statement that we can't always know the package name from the branch? Not that I'm aware of... when we create the SPRecipe, we need to supply a sourcepackagename, and at that point-in-time, the only guaranteed place where I can get that information is the changes file, which I *thought* I didn't have access to from LP (until it's uploaded after the recipe build succeeds). But let me know if I've mis-understood something. We can always run things in scripts that do have access to the branches, or we might be able to add something to the branch scanner that identified package branches, including their sourcepackagename. It would be nice if the sourcepackage name wasn't required when a recipe is created, but as I understand it, the URL traversal that was previously decided on requires it: (code?) ~owner/distro/distroseries/sourcepackagename/recipename TheSo canonical traversal for displaying/editing a recipe. There are probably ways we could get around it, e.g. by looking at the contents of the package branch while creating the recipe. Not sure there's value in that. Oh, I was under the impression that wasn't possible/allowed from an LP app server. Not directly, no. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktsXD8ACgkQ0F+nu1YWqI0eOACeK3gn2YHWdbGr9ljKQyBFt01L dAAAn2hqEQUH+IHuRLyDQkKkocNZz3ZH =YfHY -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Wed, Feb 3, 2010 at 12:38 PM, Michael Nelson michael.nel...@canonical.com wrote: On Tue, Feb 2, 2010 at 3:15 PM, Martin Albisetti argent...@gmail.com wrote: [snip] - I wonder why the packaging branch isn't something you can search for and change. IIRC, there are some advanced use cases where you use more voodoo, but the common case would be marvelously simple if you would just select a packaging branch to create a recipe I'm not sure how we could establish that link in the general case (eg., I have a packaging branch in my +junk area?) But assuming that it is possible, yes, the packaging branch could be a(n optional) selector or inline branch picker. This would mean that the text area would only be required for specific recipes that merge multiple packaging/fix branches. Which leaves me wondering whether we even should/need to convey the structure of the actual recipe (ie. we could remove the uneditable header, and just have a normal form with fields, rather than trying to emulate the recipe text). We headed down this direction because there is no standard way to construct a recipe and so I thought we'd need to expose the recipe for what it was. But all of the above fields are applicable to the various types of recipes (as long as the packaging branch option is optional). As long as we always enable the text area at the end so power users can add custom merge directives etc., we should be able to cover the most common use-cases without exposing the recipe? I'll have a play with other layouts (after thinking more about James' points). I've put an example of the overlay that doesn't try to display the structure of a recipe, but uses normal form fields (and hence potentially a branch picker for the packaging branch) on the wiki at: https://dev.launchpad.net/BuildBranchToArchiveUI#New%20Questions As you'll see there, I'm not quite sure how to best include the text-area for custom recipe text (it needs to be available there, but it'd be nice to only display it when requested. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Wed, Feb 3, 2010 at 9:58 PM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Nelson wrote: The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. So are we sure that building from a recipe should be a user-level thing at all? It seems like a major use case will be build this branch using this packaging branch. If we had a UI that just provided that, what percentage of our users would still need more? I think people need (and want) more than just the packaging branch. For example, they'd want to specify the distroseries as well, by which time, the concept of a recipe for your build makes sense (ie. you've got a few ingredients). On top of that, I don't see how we can guess a valid deb version (as it depends on what's been uploaded to the PPA before etc. And we can't always know the package name from the branch either [1].) And even if the above was feasible, we'd still need to create a recipe to do the build, and so when the same user comes back next time to build that branch again, we'd want to give them the option of selecting their previous recipe rather than silently creating another one. So I (personally) think that even new users need to be aware of recipes (not only that they need to be aware, but that it's helpful for them to be aware), but the simpler we can make the first experience, the better. Let me know if you can see any holes in the above argument. -Michael [1] But we could only display the package name field when we can't determine it from the branch, that would reduce clutter too. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Nelson wrote: On Wed, Feb 3, 2010 at 9:58 PM, Aaron Bentley aa...@canonical.com wrote: It seems like a major use case will be build this branch using this packaging branch. If we had a UI that just provided that, what percentage of our users would still need more? I think people need (and want) more than just the packaging branch. For example, they'd want to specify the distroseries as well Doesn't a user actually want to specify a list of distroseries you want to build for? And don't you need a recipe per distroseries as currently formulated? If so, our UI should let them choose a list of distroseries and create as many recipes as necessary behind the scenes. by which time, the concept of a recipe for your build makes sense (ie. you've got a few ingredients). I don't think that follows. Recipes are only somewhat specific to packaging. Providing a UI that was less generic and more domain-specific could be quite helpful. On top of that, I don't see how we can guess a valid deb version (as it depends on what's been uploaded to the PPA before etc. Surely we know what's been uploaded to a PPA before? Anyhow, that's a domain-specific thing, not necessarily a recipe thing. And we can't always know the package name from the branch either [1].) I thought the debian control directory specified the package name. And even if the above was feasible, we'd still need to create a recipe to do the build Absolutely. I never meant to suggest otherwise. and so when the same user comes back next time to build that branch again, we'd want to give them the option of selecting their previous recipe rather than silently creating another one. If we're not exposing recipes, why should the user care about duplication? Yes, it would be nice to remember past settings, but again, that doesn't require recipes per se. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktrDKUACgkQ0F+nu1YWqI0YUwCeOBhCp7lvQdHE4W/0zHFCUjKx XqQAn1Kp8GZJfJmkvo5s26S49kw5Y4th =ggkb -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Tue, Feb 2, 2010 at 3:15 PM, Martin Albisetti argent...@gmail.com wrote: On Tue, Feb 2, 2010 at 10:01 AM, Michael Nelson michael.nel...@canonical.com wrote: You can see the details at: https://dev.launchpad.net/BuildBranchToArchiveUI Hi Michael, this looks great. I've gone through the document and have a few questions to raise. Great! Thanks for taking the time... General impressions: - In target user audiences, I wonder why you left out Project maintainers. It seemed like one of the primary users for this. I replaced QA leads.. with Project maintainers. I'm also a bit confused as to whether the target audience is for people who will use the feature (the ones who will interact with the UI) or people who will benefit from this feature (this would just be people installing PPAs) Yes, this work is primarily for the people who will be building branches to archives. The UI for people just installing from targeted PPAs won't change (although I'd *love* to take the opportunity to update the PPA index to display installable binaries instead of a 'simplified' version of the list of source packages). I'm not sure what the cause of confusion was? - Reading through this document ah brought back the itching need to link PPAs to projects. Many things would be much easier! - It seems to me from the UI, that I won't be able to easily say build this every day in Lucid, Karmic, Jaunty and Hardy. I feel that's the way many people are using it today Yes - it would be great to support this (with the improvements suggested by James), but the current db schema and builder implementation do not support multiple distroseries for a recipe or multiple distroseries for a single build. I've created the following bug to capture this: https://bugs.edge.launchpad.net/launchpad-code/+bug/516448 On the other hand, the current schema and implementation *would* support us creating four separate sourcepackagerecipebuilds for one recipe (each with a different distroseries). So, it might be worth weighing up the extra cost (building the same source package 4 times) versus the benefit of supporting this straight away. Updated the following bug with this info: https://bugs.edge.launchpad.net/launchpad-code/+bug/513201 Manual build of the latest branch revision: - I understand it as as a one-off action, I think we should show what specific revision you're building, Yes, I've added a selector that defaults to (tip) - see if this is what you had in mind. and maybe a link to it Hrm, I think we should definitely link to the other branches mentioned in the recipe - when not editing (I'd forgotten to do that), but the base-branch is the current branch that you're viewing. Or did you mean link to the specific version of the branch (ui-wise, that could be tricky - perhaps a link next to the version selector? but it's already very crowded.) - I wonder why the packaging branch isn't something you can search for and change. IIRC, there are some advanced use cases where you use more voodoo, but the common case would be marvelously simple if you would just select a packaging branch to create a recipe I'm not sure how we could establish that link in the general case (eg., I have a packaging branch in my +junk area?) But assuming that it is possible, yes, the packaging branch could be a(n optional) selector or inline branch picker. This would mean that the text area would only be required for specific recipes that merge multiple packaging/fix branches. Which leaves me wondering whether we even should/need to convey the structure of the actual recipe (ie. we could remove the uneditable header, and just have a normal form with fields, rather than trying to emulate the recipe text). We headed down this direction because there is no standard way to construct a recipe and so I thought we'd need to expose the recipe for what it was. But all of the above fields are applicable to the various types of recipes (as long as the packaging branch option is optional). As long as we always enable the text area at the end so power users can add custom merge directives etc., we should be able to cover the most common use-cases without exposing the recipe? I'll have a play with other layouts (after thinking more about James' points). - I'm not sure if start build is the right wording, as it may take hours to build :) Maybe just Build? I've updated this as well. - When you expand the recipe, it seems as though you can edit it right there. There's may be some confusion involved in whether you're just editing it for that build, or editing the recipe all together Sorry, that's my laziness in not creating a separate mockup. There was never any intention that you would edit recipes on this form, only use current recipes, or create a new recipe (as the focus is on building the branch). I've updated the mockup to display three states (collapsed, expanded to see recipe details, after clicking create new recipe). - I'm
Re: [Launchpad-dev] RFC on build from branch UI
On Tue, Feb 2, 2010 at 8:52 PM, James Westby jw+deb...@jameswestby.net wrote: On Tue, 2 Feb 2010 11:01:49 +0100, Michael Nelson michael.nel...@canonical.com wrote: Hi all, I've been putting together some mockups for the build-from-branch UI work (with the help of jml, wgrant and mwhudson), and would love to hear ideas on how they could be improved or re-worked etc. You can see the details at: https://dev.launchpad.net/BuildBranchToArchiveUI Thanks for working on this Michael, it's great to be able to review it as a whole at this time, rather than making comments as the changes arrive. It's a pleasure... and it's great finding lots of issues before any UI code has been written too :), so thanks for all your input! I have some comments that are quite fundamental, but let me say first that I like the design for interaction, and I'm confident that whatever you end up going with will be a pleasure to use. The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. I think that it is important to have something on a branch page to get started, but I'm not sure that driving everything from the point of view of the branch is the right thing to do. Yes, I agree that the (base?) branch shoudn't be the starting point for every recipe-related action, but I'm not sure if I'm understanding all of what you're saying. For example, there are urls along the lines of (from the wiki page): (code?) ~owner/distro/distroseries/sourcepackagename/recipename (code?) ~owner/+recipes: all recipes owned/created by a person as points for viewing/editing and dealing with recipes directly. For instance, I might go to the branch page for the packaging branch, and want to do a build from there, Why wouldn't this be possible? Given that if you click Build this branch (or whatever it'll be), the overlay will allow you to select the recipe you want (ie. including those recipes that just refer to this branch). but for daily builds that won't be the base branch. Yes, so if, from the packaging branch, you click on Build this branch and non of the available recipes meet your requirements, so you need to create a new recipe - then if you do want a base-branch different from the current one you're stuck at this point (with the current design, as the base-branch is non-editable). So I talked with jml about this the other day when thinking through the workflow, and from memory there were three thoughts: 1. The base-branch seems like the logical place to build your base-branch (and specifying the packaging branch from there). That's not to say it is the only way, just the most natural way for the 90% case. Do you have other thoughts? 2. we couldn't see how we could have a consistent UI if users specified the base-branch (as you could create a recipe that has nothing to do with the current branch at all. [1]) 3. The case where it *does* make sense to initiate the recipe creation from a packaging branch is when the packaging branch contains the source already, and hence it is the base_branch (ie. no other merges required to have both the debian directory and the source code toghether). I guess you are saying that there are other cases? [1] That's not to say that the base-branch shouldn't be editable when you edit the recipe itself, as the recipe's traversal is not restricted by the branch: ~owner/distro/distroseries/sourcepackagename/recipename/+edit Given that you understand the workflows much better than anyone, I'd be keen to have a call sometime to clarify the above :) If I were to make a suggestion it may be for the following: * A branch page has a list of recipes that mention the branch, and a link to add a new one. This is exactly what's displayed in the overlay isn't it (or the non-js version)? It would be difficult to display this information (the recipes) on the branch page itself, as there is no single bit of the recipe that helps users identify whether it's the one they're after. You'd need the recipe name, owner, (distroseries?), at the very least (hence that's what's displayed in the overlay dropdown, but even then you might need more information (revnos, packaging branch etc.), which is why the overlay displays that in-line. * You can navigate to the +recipe page from there, and from there there is a build this button, which launches the archive picker. So as mentioned that navigation step would only be necessary if the recipe details were not present on the page where you select the recipe (ie. if you just listed the recipe names (?) on the branch page as you mentioned). But this would potentially be a lot of back-and-forward to find the recipe that suites
Re: [Launchpad-dev] RFC on build from branch UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Nelson wrote: The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. So are we sure that building from a recipe should be a user-level thing at all? It seems like a major use case will be build this branch using this packaging branch. If we had a UI that just provided that, what percentage of our users would still need more? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktp43gACgkQ0F+nu1YWqI3+hACeKYDmTyGfBPDYhQ6qIlqKnNTh rqwAmwdrqIljcYoZJ3YFAgyRr5JG9jez =6dMY -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Wed, 3 Feb 2010 16:12:10 +0100, Michael Nelson michael.nel...@canonical.com wrote: I have some comments that are quite fundamental, but let me say first that I like the design for interaction, and I'm confident that whatever you end up going with will be a pleasure to use. The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. I agree that is an important aim. Why wouldn't this be possible? Given that if you click Build this branch (or whatever it'll be), the overlay will allow you to select the recipe you want (ie. including those recipes that just refer to this branch). That wasn't clear, sorry. I think the base branch being immutable in the overlay indicated to me that it was all that would be offered. but for daily builds that won't be the base branch. Yes, so if, from the packaging branch, you click on Build this branch and non of the available recipes meet your requirements, so you need to create a new recipe - then if you do want a base-branch different from the current one you're stuck at this point (with the current design, as the base-branch is non-editable). So I talked with jml about this the other day when thinking through the workflow, and from memory there were three thoughts: 1. The base-branch seems like the logical place to build your base-branch (and specifying the packaging branch from there). That's not to say it is the only way, just the most natural way for the 90% case. Do you have other thoughts? I think it may be skewed as I am an Ubuntu developer, but I don't think packaging branches will just be implementation details. For instance, you may decide you want to set up a daily build for a new project, which isn't packaged yet. To do this you branch, create the packaging and push it. They you may go to the packaging branch as that was just what you were working with. I'm not sure it's a good enough argument that it should change your approach, but perhaps something like giving them a message if they choose daily build while on a package branch. 2. we couldn't see how we could have a consistent UI if users specified the base-branch (as you could create a recipe that has nothing to do with the current branch at all. [1]) 3. The case where it *does* make sense to initiate the recipe creation from a packaging branch is when the packaging branch contains the source already, and hence it is the base_branch (ie. no other merges required to have both the debian directory and the source code toghether). I guess you are saying that there are other cases? Well, creating a recipe from a packaging branch is how you will build a package in a non-daily fashion, so that has to be supported, but it will be the base branch in that case. Given that you understand the workflows much better than anyone, I'd be keen to have a call sometime to clarify the above :) I'd be happy to do that. Next week is probably better as I guess we will be in closer timezones again. This is exactly what's displayed in the overlay isn't it (or the non-js version)? It would be difficult to display this information (the recipes) on the branch page itself, as there is no single bit of the recipe that helps users identify whether it's the one they're after. You'd need the recipe name, owner, (distroseries?), at the very least (hence that's what's displayed in the overlay dropdown, but even then you might need more information (revnos, packaging branch etc.), which is why the overlay displays that in-line. Makes sense. [ snip more convincing comments ] Some further unstructured comments: When viewing a source package recipe build within their PPA, users can: easily go to the recipe that was used and from there to the branches. They should also be able to go to the manifest and so see the revisions that were used. I'm keen for these links to be more common in Launchpad, from e.g. bugs to the revisions that fix them etc. Being able to go binary package-source package-manifest- branches will be useful. Yes, that's great. I've updated the wiki with: When viewing a source package recipe build within their PPA, users can: ... * View the manifest (and from there the related branches and recipe) Although it'd be worth a link from the manifest to the recipe, I wouldn't link directly to the recipe as it could be very confusing if the recipe has been edited since? Good point. Yes, the mockup wasn't meant to communicate that it was editable (just that you could create a new recipe) - my mistake. I've updated it to show the non-editable recipe selection/display. See what you think. Looks great.
Re: [Launchpad-dev] RFC on build from branch UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitrijs Ledkovs wrote: On 3 February 2010 20:58, Aaron Bentley aa...@canonical.com So are we sure that building from a recipe should be a user-level thing at all? It seems like a major use case will be build this branch using this packaging branch. If we had a UI that just provided that, what percentage of our users would still need more? IMHO it would be 50/50 split cause I'm still thinking in terms of packaging branch as the starting point and which branches do I want to build using it. I am contrasting a UI that speaks in terms of branches and package branches with a UI that speaks in terms of recipes. I think that it's more intuitive to talk about the branches, and that providing recipes in the UI may be overkill, but I could be wrong and I want feedback. It sounds like you're saying that you'd like a UI on the packaging branch that lets you build other branches using it, instead of doing that from the individual branches. That's valid, but it answers a question I didn't mean to ask. For example as an upstream project maintainer I will strive to minimize amount of packaging branches / recipes cause that's not usually upstream expertise. So I would have one packaging branch possibly pinched of ubuntu and then I will go to it and start thinking which of my project branches I want to build eg. stable release, supported release and this wacky hack I'm working on. None of this requires recipes to be exposed to users. Since, as currently formulated, recipes specify their base branch, you would need a different recipe for stable, supported, and wacky hack. And ooops hardy has different lib sonames so i need to use this other packaging branch cause it has build time patch. As described, this doesn't need user-level recipes either, but another approach might. Instead of having a different packaging branch with the build-time patch, you could have a branch with just the build-time patch. That would be a reason to use the full power of recipes. This feature will be a popular both from Ubuntu development side and the upstream projects using launchpad for project management, QA / ubuntu experience enhancement. Note that this feature only builds native packages at the moment, so it will not be suitable for building packages for the main archive until that changes. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktp7WEACgkQ0F+nu1YWqI2NaQCbBAcpZHcB7ticB/dhAySD3/rS AoYAn1eILuW9ahLaWPosUcRYHuuNHLEf =cno3 -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] RFC on build from branch UI
Hi all, I've been putting together some mockups for the build-from-branch UI work (with the help of jml, wgrant and mwhudson), and would love to hear ideas on how they could be improved or re-worked etc. You can see the details at: https://dev.launchpad.net/BuildBranchToArchiveUI The Balsamiq mockups are all available in a branch if you have some inspiration too :) (linked on the page). And there is a list of questions at the bottom of the page that may answer initial thoughts. Thanks in adavance, -Michael BTW: Working through the UI workflow with the current schema/code brought up a few bugs that we'll need to work on (or clarify as invalid), so if you think you might be able to clarify them: = Our current schema doesn't support scheduling of builds (ie. daily builds) = https://bugs.edge.launchpad.net/launchpad-code/+bug/515923 = We're not passing the recipe's source package name or suite through to dailydeb = https://bugs.edge.launchpad.net/soyuz/+bug/515918 = Recipe has sourcepackagename before upload = This one might be invalid - I just wasn't sure why we're not using the normal process of processing an upload to create a SPN (rather than potentially creating the SPN record for the recipe). https://bugs.edge.launchpad.net/launchpad-code/+bug/515581 ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Tue, Feb 2, 2010 at 10:01 AM, Michael Nelson michael.nel...@canonical.com wrote: You can see the details at: https://dev.launchpad.net/BuildBranchToArchiveUI Hi Michael, this looks great. I've gone through the document and have a few questions to raise. General impressions: - In target user audiences, I wonder why you left out Project maintainers. It seemed like one of the primary users for this. I'm also a bit confused as to whether the target audience is for people who will use the feature (the ones who will interact with the UI) or people who will benefit from this feature (this would just be people installing PPAs) - Reading through this document ah brought back the itching need to link PPAs to projects. Many things would be much easier! - It seems to me from the UI, that I won't be able to easily say build this every day in Lucid, Karmic, Jaunty and Hardy. I feel that's the way many people are using it today Manual build of the latest branch revision: - I understand it as as a one-off action, I think we should show what specific revision you're building, and maybe a link to it - I wonder why the packaging branch isn't something you can search for and change. IIRC, there are some advanced use cases where you use more voodoo, but the common case would be marvelously simple if you would just select a packaging branch to create a recipe - I'm not sure if start build is the right wording, as it may take hours to build :) Maybe just Build? - When you expand the recipe, it seems as though you can edit it right there. There's may be some confusion involved in whether you're just editing it for that build, or editing the recipe all together - I'm not sure what the # bzr-builder... text is above the textarea - The Need help creating a recipe? link would probably be useful in the unexpanded area - What's the UI for when I want to build but there are no recipes? I imagined that will be the first experience for everybody, so we should really nail that Daily builds: - I wonder if we could use a drop down instead of an expander with options like Build revision XXX and Build daily Phew, sorry it got long. I wanted to give a quick turnaround. cheers, -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
