launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #02598
Re: Build branch to Archive UI
Michael Nelson wrote:
> On Mon, Feb 15, 2010 at 5:17 AM, Tim Penhey <tim.penhey@xxxxxxxxxxxxx> 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
Follow ups
References