Michael Nelson wrote: > On Mon, Feb 15, 2010 at 5:17 AM, Tim Penhey <[email protected]> wrote: >> On Mon, 15 Feb 2010 16:59:45 Michael Hudson wrote: >>> Tim Penhey wrote: >>>> Hi guys, >>>> > > Hi Tim and Michael, thanks for taking the time to update the mockups > with your thoughts etc.! > > I'd really like to be able to call about these - some of the things > you've raised have come up in previous discussions and/or have > associated questions with answers on the wiki (and I realise it's > unrealistic to wade through all those questions, hence suggesting a > call). > >>>> I've been spending more time looking at this, and I want to make sure we >>>> start getting some traction on the UI to build. >>>> >>>> I'm not yet convinced that showing existing recipes is useful at this >>>> stage. We aren't yet clear ourselves why we'd want to do this or what it >>>> would mean. > > I think that all depends on what is actually in a recipe. The examples > you've used below seem to assume (as far as I can tell), that the > target PPA is part of the recipe, in which case yes it would be hard > to see how showing existing recipes from other people could be useful. > But if the target PPA is not part of the recipe, then is the first > use-case/example at: > > https://dev.launchpad.net/BuildBranchToArchiveUI/UseCaseManualBuild > > unrealistic? (That is, there's already a recipe that does exactly what > I want, created for the project by one of the project maintainers). > > Note 1: As stated on that page: the following mockups do not try to > fit the current implementation of bzr builder recipes or the > corresponding current LP models. (specifically, they are based on > recipes being *applied* to a branch, rather than including a > base_branch on the recipe itself - this came out of the discussions > with jml, James and Aaron)
I think we certainly need to have a mutual understanding of what this means. >>>> Perhaps we start off really strict, and slowly roll out options. This >>>> I'm in favour with, especially with the feature branch merge work that >>>> Bjorn is championing. >>> Yeah. It feels like we're verging on analysis paralysis now. >> Me too. > > Really? Maybe that's a communication problem on my part? I've found > the discussions (email/irc) and calls I've had with Jono, James and > Aaron to be incredibly productive, helping us to converge on something > that I think balances ease-of-use, flexibility and re-usability very > well. > > Or maybe you both feel that way because the discussions have taken > place over two weeks? (I've not been working on this full time, but > doing some soyuz bugs on the side.) > > Anyway, I'd be keen to hear why you think this is the case - to me > it's felt like a convergence the whole time. Well, I think it's mostly that Tim and I have not been part of these calls, for obvious reasons. Maybe that counts as a communication problem, but it's sort of an inevitable one I guess. >>>> I suggest a somewhat limited initial cut for the build from branch. >>>> Attached is my first mockup with Balsamiq. I don't offer a revision to >>>> build, only show the current and development distro series. >>> We still don't have a way to represent a multi distroseries recipe. For >>> now we could just create multiple recipes. >>> >>> We probably want to allow the name of a SourcePackageRecipe to be NULL > > On that point, the wiki page has the following question/answer: > > "James says, from a technical pov, we don't need the source package > name field at all, and in fact, it can't be used for anything useful. > James will actually remove the --package option from bzr dailydeb, as > it's not even required when there's no changelog entry, as it must be > present in the control file." I wasn't talking about sourcepackagename, I was talking about name. > I was planning to remove it from the mockups today, but noted there: > "Although we still then need a discussion around the recipe traversal > URL, as the last time this was discussed they were to be traversed via > the SPName, which LP won't currently have access to even though it is > data in one of the branches referenced by the recipe and (currently) > we will have that data once the source package is uploaded." Right, this is certainly the case. >>> if we're going to go for these throw-away type recipes to start with. >> Do we want multi-distroseries recipes? > > From the initial email discussions and subsequent phone conversations, > I updated the wiki page with the following answer to this: "OK, so the > agreed answer on this is YES - a user should be able to do this. The > fact that the current infrastructure might not support it should not > be considered." > > That is, they should be able to click build once, and it is built for > multiple distroseries. OK. Is this something we can safely leave out in the first cut? Looking forward to the call! Cheers, mwh _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
