On Tue, Feb 2, 2010 at 3:15 PM, Martin Albisetti <[email protected]> wrote: > On Tue, Feb 2, 2010 at 10:01 AM, Michael Nelson > <[email protected]> wrote: >> You can see the details at: >> >> https://dev.launchpad.net/BuildBranchToArchiveUI > > Hi Michael, this looks great. I've gone through the document and have > a few questions to raise.
Great! Thanks for taking the time... > > > General impressions: > - In target user audiences, I wonder why you left out "Project > maintainers". It seemed like one of the primary users for this. I replaced "QA leads.." with Project maintainers. > I'm > also a bit confused as to whether the target audience is for "people > who will use the feature" (the ones who will interact with the UI) or > "people who will benefit from this feature" (this would just be people > installing PPAs) Yes, this work is primarily for the people who will be building branches to archives. The UI for people just installing from targeted PPAs won't change (although I'd *love* to take the opportunity to update the PPA index to display installable binaries instead of a 'simplified' version of the list of source packages). I'm not sure what the cause of confusion was? > - Reading through this document ah brought back the itching need to > link PPAs to projects. Many things would be much easier! > - It seems to me from the UI, that I won't be able to easily say > "build this every day in Lucid, Karmic, Jaunty and Hardy". I feel > that's the way many people are using it today Yes - it would be great to support this (with the improvements suggested by James), but the current db schema and builder implementation do not support multiple distroseries for a recipe or multiple distroseries for a single build. I've created the following bug to capture this: https://bugs.edge.launchpad.net/launchpad-code/+bug/516448 On the other hand, the current schema and implementation *would* support us creating four separate sourcepackagerecipebuilds for one recipe (each with a different distroseries). So, it might be worth weighing up the extra cost (building the same source package 4 times) versus the benefit of supporting this straight away. Updated the following bug with this info: https://bugs.edge.launchpad.net/launchpad-code/+bug/513201 > > Manual build of the latest branch revision: > - I understand it as as a one-off action, I think we should show what > specific revision you're building, Yes, I've added a selector that defaults to (tip) - see if this is what you had in mind. > and maybe a link to it Hrm, I think we should definitely link to the other branches mentioned in the recipe - when not editing (I'd forgotten to do that), but the base-branch is the current branch that you're viewing. Or did you mean link to the specific version of the branch (ui-wise, that could be tricky - perhaps a link next to the version selector? but it's already very crowded.) > - I wonder why the packaging branch isn't something you can search for > and change. IIRC, there are some advanced use cases where you use more > voodoo, but the common case would be marvelously simple if you would > just select a packaging branch to create a recipe I'm not sure how we could establish that link in the general case (eg., I have a packaging branch in my +junk area?) But assuming that it is possible, yes, the packaging branch could be a(n optional) selector or inline branch picker. This would mean that the text area would only be required for specific recipes that merge multiple packaging/fix branches. Which leaves me wondering whether we even should/need to convey the structure of the actual recipe (ie. we could remove the uneditable header, and just have a normal form with fields, rather than trying to emulate the recipe text). We headed down this direction because there is no standard way to construct a recipe and so I thought we'd need to expose the recipe for what it was. But all of the above fields are applicable to the various types of recipes (as long as the packaging branch option is optional). As long as we always enable the text area at the end so power users can add custom merge directives etc., we should be able to cover the most common use-cases without exposing the recipe? I'll have a play with other layouts (after thinking more about James' points). > - I'm not sure if "start build" is the right wording, as it may take > hours to build :) Maybe just "Build"? I've updated this as well. > - When you expand the recipe, it seems as though you can edit it right > there. There's may be some confusion involved in whether you're just > editing it for that build, or editing the recipe all together Sorry, that's my laziness in not creating a separate mockup. There was never any intention that you would edit recipes on this form, only use current recipes, or create a new recipe (as the focus is on building the branch). I've updated the mockup to display three states (collapsed, expanded to see recipe details, after clicking create new recipe). > - I'm not sure what the "# bzr-builder..." text is above the textarea It's the standard header for recipes. As above, we were trying to display the actual recipe text that would be created (due to all the different ways recipes can be constructed), but it may be that we don't need to do this... > - The "Need help creating a recipe?" link would probably be useful in > the unexpanded area If we did lose the recipe structure on the form, this help would only be necessary for people doing advanced things. Although we'd want a separate link for help specifying the deb-version etc. > - What's the UI for when I want to build but there are no recipes? I > imagined that will be the first experience for everybody, so we should > really nail that See the third dialog at: http://people.canonical.com/~michaeln/bfb/build_now_overlay.png > > Daily builds: > - I wonder if we could use a drop down instead of an expander with > options like "Build revision XXX" and "Build daily" Initially I balked at this thought, as it implies that a revision spec should be on the SPRBuild table, rather than on the Recipe itself (as part of the base_branch definition), but it does seem like a more sensible place for a user to make the decision. And if we were able to update the schema, it would provide much more re-usability to recipes. What I mean is, if the "Build revision XXX" option specified the base_branch revision on the recipe itself, the recipe would no longer be re-usable (ie. I need a separate recipe the next time I want to build a different rev, or tip). But, for this reason, perhaps it would be better if the recipes created through the UI simply referred to tip of the base-branch always (ie. no option there), and we added a base_branch_revision_spec column to the SourcePackageRecipeBuild table? I've created https://bugs.edge.launchpad.net/launchpad-code/+bug/516496 to track this. Without updating the schema, I think putting the revision spec here could be a source of confusion (I think I'm creating a general recipe that I'll be able to re-use to build different revisions, but I'm not). > > > Phew, sorry it got long. I wanted to give a quick turnaround. > Thankyou * 1000 for such useful feedback! > > cheers, > -- > Martin > _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
