On Fri, Feb 5, 2010 at 3:58 PM, Aaron Bentley <[email protected]> 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 : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
