-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Nelson wrote: > On Thu, Feb 4, 2010 at 7:06 PM, Aaron Bentley <[email protected]> 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. > 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. I don't understand how it follows that you wouldn'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). Sure thing. I work 9-5 ET (14-22 UTC). Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktsMgEACgkQ0F+nu1YWqI0KsACcCU87+dLjG7DS5xUY6OS/kPss +WIAn2EUMqnHlfHzZDF3pZDupRYAUWZd =ruda -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
