launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

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)

Note 2: I haven't updated the mockups from the last discussion with
James W. last Friday, but will do so ASAP.

>>
>> I know we talked about this a bit this morning, but now I'm not so sure.
>>    Even in the current model, a recipe encodes enough information that
>> you probably don't want to select the packaging branch each and every
>> time you want to build.
>
> I'm not suggesting that we show the full dialog every time someone wants to
> build, just when they are creating the recipe.
>
> Once the recipe is created we show this on the branch page (mockup pending)
> and there is where we have the build button (if one is not running or
> waiting).

As above, how would I use that recipe to build to a different PPA?

Even if we are only displaying *my* recipes on the branch page then
this could be possible, although even then it would be difficult to
include all the info to make a decision (for example, based on your
point below about separate recipes for different distroseries, and
target PPAs, I would end up with quite a few recipes, and would need
more info than the recipe name to make the decision).

>
>> > By that I mean that we don't
>> > automatically reschedule builds to happen daily, but have a "build now"
>> > type button that creates a build job if and only if there isn't one
>> > waiting or running already.  This button should obviously not be there if
>> > there is one waiting or pending.
>>
>> Are you saying that for any branch, there can only be one build of a
>> recipe that has the given branch as its base_branch?  I'm not sure
>> that's really what we want.
>
> No, that is not what I'm saying.
>
> What I am saying is that for any given recipe connected to the branch there is
> zero or one waiting or running build job.

Yes, this works if the assumption is that a recipe is only for one
person and/or one target PPA, but I'm not sure that's a good
assumption for us to start with - I'd like to discuss it with you.


>
>> > With this in mind, we'd be creating a recipe from one of two places:
>> >  - a project branch (no packaging info - or most likely no packaging
>> > info) - a packaging branch (may have trunk merged in)
>> >    * are we even going to allow this for now?
>>
>> For now, for the sake of doing something, let's not?
>
> Ok.

The current mockups pointed to in the above use-case wiki page handle
both scenarios without complexity (I need to write up the specific
use-case for the second situation today).


>
>> > 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.


>
>> > 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 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."


>> 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.


>
> I'm not suggesting throw-away recipes.

Great. The other side of the coin is to avoid recipe proliferation, as
that will also make it hard to re-use recipes (ie. find the one I
want). That's something we worked hard on with the mockups on the wiki
(by separating re-usable info in a natural way).

In the situation you've mentioned where I only see my own recipe, this
wouldn't be too bad (although a recipe for each distroseries and
target PPA would already be adding up, but I might have misunderstood
you on those points).

So, I'd be happy to come back your morning Tuesday 16th and try to
have a call. Let me know if that's possible? (Maybe 22:00 UTC?)

Thanks!



>
> Tim
>