On Thu, Feb 4, 2010 at 7:06 PM, Aaron Bentley <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Nelson wrote: >> On Wed, Feb 3, 2010 at 9:58 PM, Aaron Bentley <[email protected]> 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 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. 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). I'm also not sure how I'd edit a saved dailybuild something-other-than-recipe if I didn't have a concept of it being saved/available etc. But I'll try to organise a time to hear/discuss your thoughts on it! (or if you prefer to put theme here, that's fine too). Thanks! _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
