Re: [Launchpad-dev] Status of +patches view (story-patch-report)
Latest progress on this feature: All code is done *except* for UI change to offer the newly-available sorting by patch age. However, we still need some reviews to land this stuff (including DB changes) so it's visible on staging. My understanding is that we just land the devel branches on devel, and the db-devel branches on db-devel, and then magic happens and it all gets tied together on staging. If someone here knows more about magic, please use that knowledge! Jorge, I think we'll get this on staging in time, but if not, I have enough to make you screenshots now at least. Obviously, staging would be better. Details: There are five branches. Here are their statuses: * lp:~kfogel/launchpad/506018-patch-report STATUS: Code is approved. UI needs re-review (though all concerns should now be addressed). * lp:~intellectronica/launchpad/no-patches-message STATUS: Code is approved. UI needs review. * lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018 STATUS: Code is approved. (Not sure if UI review needed, as UI is same as for first branch.) * lp:~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort STATUS: Submitted to PQM, possibly landed in db-devel by the time you read this. (DB changes approved by stub, jml.) * lp:~adeuring/launchpad/bug-512500-model-change STATUS: Needs merge proposal, and some easy conflict resolution. [See Note to Abel: below.] Anyway, I created a mega-integration branch containing all the above: https://code.edge.launchpad.net/~kfogel/launchpad/patches-view-mega-integration (Some trivial conflict resolution was necessary, due to variable name changes. See the commits on the integration branch for what I did.) Next I ran EC2 tests on the integration branch, and they passed. Yay. Well, actually as you can see from rev 8958 on the integration branch, there was one test failure due to a trivial conflict mis-resolution in the test code itself -- when I fixed that, that test passed, so the branch passes. Note to Abel: I included lp:~adeuring/launchpad/bug-512500-model-change in my mega-integration branch, and it passed, so everything's looking good. Note I had to resolve some conflicts in obvious ways; the integration branch's commits show how. The only thing remaining is to make this functionality available via the UI. I will do that first thing in the morning (unfortunately I had an appointment tonight), but if you want to beat me to it, go for it! You've got that nice 5 hour lead time :-). For various reasons, I already wrote the merge proposal cover letter for that hypothetical branch, so here is that text, to save one of us time later: --- Enable the +patches view on persons and teams. (Putting lp:~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort as the prerequisite branch, but if reviewing for UI, I suggest using https://code.edge.launchpad.net/~kfogel/launchpad/patches-view-mega-integration, which contains all the prerequisites as well as this branch. That 'patches-view-mega-integration' branch has passed EC2. -kfogel) For UI testing, you can apply dev sampledata from here: people.canonical.com/~kfogel/patches-view/512500-current-dev-sql.diff and try URLs like this: https://bugs.launchpad.dev/~name12/+patches https://bugs.launchpad.dev/~name16/+patches I don't think the test data does anything with teams, so you'll have to do that manually, but at least you get all the bugs with patch attachments for free. Some non-person / non-team URLs are: https://bugs.launchpad.dev/patches-view-test/+patches https://bugs.launchpad.dev/gnome/+patches https://bugs.launchpad.dev/evolution/+patches https://bugs.launchpad.dev/ubuntu/hoary/+patches https://bugs.launchpad.dev/ubuntu/warty/+source/evolution/+patches ...though they've already been tested in other branches, e.g., https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report, so it's up to you whether to re-examine them. --- Z, -Karl ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Status of +patches view (story-patch-report)
Karl Fogel karl.fo...@canonical.com writes: --- Enable the +patches view on persons and teams. Wow, I got really confused between sorting-on-patch-age and patches-view-for-persons-and-teams! Sorry about that. I no longer have enough functioning neurons to disentangle them and write the proper merge proposal for the former. Abel, please do it with your fresh brain. I hope my text about test data is still useful: (Putting lp:~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort as the prerequisite branch, but if reviewing for UI, I suggest using https://code.edge.launchpad.net/~kfogel/launchpad/patches-view-mega-integration, which contains all the prerequisites as well as this branch. That 'patches-view-mega-integration' branch has passed EC2. -kfogel) For UI testing, you can apply dev sampledata from here: people.canonical.com/~kfogel/patches-view/512500-current-dev-sql.diff and try URLs like this: https://bugs.launchpad.dev/~name12/+patches https://bugs.launchpad.dev/~name16/+patches I don't think the test data does anything with teams, so you'll have to do that manually, but at least you get all the bugs with patch attachments for free. Some non-person / non-team URLs are: https://bugs.launchpad.dev/patches-view-test/+patches https://bugs.launchpad.dev/gnome/+patches https://bugs.launchpad.dev/evolution/+patches https://bugs.launchpad.dev/ubuntu/hoary/+patches https://bugs.launchpad.dev/ubuntu/warty/+source/evolution/+patches ...though they've already been tested in other branches, e.g., https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report, so it's up to you whether to re-examine them. Bedtime now :-). -K ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Status of +patches view (story-patch-report)
Hi Karl, this sounds like interesting stuff. Could you put a screenshot of your work onto a bug somewhere, or point me to it if I missed it? -- Martin http://launchpad.net/~mbp/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Status of +patches view (story-patch-report)
Martin Pool m...@canonical.com writes: Hi Karl, this sounds like interesting stuff. Could you put a screenshot of your work onto a bug somewhere, or point me to it if I missed it? I think Abel Deuring may be about to attach these to various bugs, but for now just grab them here: http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-distroseries-2010-02-03.png http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-no-patches-message-2010-02-03.png http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-orderby-dropdown-2010-02-03.png http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-padding-around-tooltip-has-orderby-label-bug-icon-respects-importance-2010-02-03.png http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-project-group-2010-02-03.png :-) -Karl ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Tue, Feb 2, 2010 at 3:15 PM, Martin Albisetti argent...@gmail.com wrote: On Tue, Feb 2, 2010 at 10:01 AM, Michael Nelson michael.nel...@canonical.com 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
[Launchpad-dev] ReviewersMeetings cancelled for today
Hi all, Since a large number of our team is unavailable for a meeting today combined with no new agenda items I am going to cancel both Launchpad Reviewers Meetings for today. See you next week. --Brad ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Using HTTP basic auth on windmill tests
Hi there, I have a branch on which I changed the +login page to use OpenID, and when developing or testing it uses testopenid.lp.dev as the provider. That's a problem for windmill tests because windmill can't cleanly switch between domains[1], so I thought of using HTTP basic auth (+basiclogin) instead, which works ok in this case as our tests don't switch between domains anyway. Does anybody see that as a problem in any way? An alternative would be to not use a separate vhost for the testopenid provider, but that would make it slightly trickier to disable the test provider in production -- when using a separate vhost it's very easy to do that. [1] I tried really hard to make it possible to login using the test OpenID provider in windmill tests and almost succeeded (with a few hacks here and there), but in the end I wasn't sure it'd be possible at all, so I gave up. http://trac.getwindmill.com/ticket/279 -- Guilherme Salgado salg...@canonical.com signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Tue, Feb 2, 2010 at 8:52 PM, James Westby jw+deb...@jameswestby.net wrote: On Tue, 2 Feb 2010 11:01:49 +0100, Michael Nelson michael.nel...@canonical.com wrote: Hi all, I've been putting together some mockups for the build-from-branch UI work (with the help of jml, wgrant and mwhudson), and would love to hear ideas on how they could be improved or re-worked etc. You can see the details at: https://dev.launchpad.net/BuildBranchToArchiveUI Thanks for working on this Michael, it's great to be able to review it as a whole at this time, rather than making comments as the changes arrive. It's a pleasure... and it's great finding lots of issues before any UI code has been written too :), so thanks for all your input! I have some comments that are quite fundamental, but let me say first that I like the design for interaction, and I'm confident that whatever you end up going with will be a pleasure to use. The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. I think that it is important to have something on a branch page to get started, but I'm not sure that driving everything from the point of view of the branch is the right thing to do. Yes, I agree that the (base?) branch shoudn't be the starting point for every recipe-related action, but I'm not sure if I'm understanding all of what you're saying. For example, there are urls along the lines of (from the wiki page): (code?) ~owner/distro/distroseries/sourcepackagename/recipename (code?) ~owner/+recipes: all recipes owned/created by a person as points for viewing/editing and dealing with recipes directly. For instance, I might go to the branch page for the packaging branch, and want to do a build from there, Why wouldn't this be possible? Given that if you click Build this branch (or whatever it'll be), the overlay will allow you to select the recipe you want (ie. including those recipes that just refer to this branch). but for daily builds that won't be the base branch. Yes, so if, from the packaging branch, you click on Build this branch and non of the available recipes meet your requirements, so you need to create a new recipe - then if you do want a base-branch different from the current one you're stuck at this point (with the current design, as the base-branch is non-editable). So I talked with jml about this the other day when thinking through the workflow, and from memory there were three thoughts: 1. The base-branch seems like the logical place to build your base-branch (and specifying the packaging branch from there). That's not to say it is the only way, just the most natural way for the 90% case. Do you have other thoughts? 2. we couldn't see how we could have a consistent UI if users specified the base-branch (as you could create a recipe that has nothing to do with the current branch at all. [1]) 3. The case where it *does* make sense to initiate the recipe creation from a packaging branch is when the packaging branch contains the source already, and hence it is the base_branch (ie. no other merges required to have both the debian directory and the source code toghether). I guess you are saying that there are other cases? [1] That's not to say that the base-branch shouldn't be editable when you edit the recipe itself, as the recipe's traversal is not restricted by the branch: ~owner/distro/distroseries/sourcepackagename/recipename/+edit Given that you understand the workflows much better than anyone, I'd be keen to have a call sometime to clarify the above :) If I were to make a suggestion it may be for the following: * A branch page has a list of recipes that mention the branch, and a link to add a new one. This is exactly what's displayed in the overlay isn't it (or the non-js version)? It would be difficult to display this information (the recipes) on the branch page itself, as there is no single bit of the recipe that helps users identify whether it's the one they're after. You'd need the recipe name, owner, (distroseries?), at the very least (hence that's what's displayed in the overlay dropdown, but even then you might need more information (revnos, packaging branch etc.), which is why the overlay displays that in-line. * You can navigate to the +recipe page from there, and from there there is a build this button, which launches the archive picker. So as mentioned that navigation step would only be necessary if the recipe details were not present on the page where you select the recipe (ie. if you just listed the recipe names (?) on the branch page as you mentioned). But this would potentially be a lot of back-and-forward to find the recipe that suites
Re: [Launchpad-dev] Status of +patches view (story-patch-report)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Fogel wrote: My understanding is that we just land the devel branches on devel, and the db-devel branches on db-devel, and then magic happens and it all gets tied together on staging. If someone here knows more about magic, please use that knowledge! There's a description of the magic here: https://dev.launchpad.net/Trunk I'd be happy to clarify anything that's confusing there. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktppqEACgkQ0F+nu1YWqI1JywCeN3Yv3DE2W7ZgPqEiaXhmDlkt jZsAn11dZTWFY4qLI+6ROrOKlQnH4agS =Oi8h -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] New lp-land command in bzr-pqm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've implemented a new command as part of the bzr-pqm plugin: lp-land. This command will scan the merge proposals for a branch, and use that info to submit a merge request to PQM. Specifically, it will pre-populate the [r=foo][ui=bar][release-critical] tags in the correct order. If you've used ec2 land, this is the same code. The big advantages of this are: - - it will automatically submit to the submit branch specified in the merge proposal, so you don't need to handle db-devel-targetted branches specially. - - if you've specified a commit message in the merge proposal, it will use that. To use this, you'll need bzr-pqm revno 64 or later. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktprigACgkQ0F+nu1YWqI3HuQCeOOUiHX7+YSSA+tJoB5wyWf0B PtgAnjoRzzRCPUU0lnKrZpgpXHEpzSek =HqJS -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] New lp-land command in bzr-pqm
I'm not sure if it matters but this seems a bit like it's putting lp-project-specific policy into bzr-pqm? -- Martin http://launchpad.net/~mbp/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] New lp-land command in bzr-pqm
On Wed, Feb 3, 2010 at 5:42 PM, Martin Pool m...@canonical.com wrote: I'm not sure if it matters but this seems a bit like it's putting lp-project-specific policy into bzr-pqm? Nope. Hooks are great. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] New lp-land command in bzr-pqm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Pool wrote: I'm not sure if it matters but this seems a bit like it's putting lp-project-specific policy into bzr-pqm? It is, but it's not forcing that policy onto existing features, just the new one, so I don't see any harm. We can make the policy customizable, if it turns out people want that. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktpt2oACgkQ0F+nu1YWqI34swCfWLeEtQPAjvTSKL7EiAkTkq7s yGcAn1R4MsdoTRr9kG7E7IslzEwOX2aD =mtOy -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] New lp-land command in bzr-pqm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan Lange wrote: On Wed, Feb 3, 2010 at 5:42 PM, Martin Pool m...@canonical.com wrote: I'm not sure if it matters but this seems a bit like it's putting lp-project-specific policy into bzr-pqm? Nope. Hooks are great. We didn't do the LP policy with hooks in lp-land. I think you're thinking of lp-submit? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktpt7gACgkQ0F+nu1YWqI0urQCePFbsBHaPseU8P+AOlGTE5m4i 3wIAn1tGn8JZfNrlpxPK5Qd9/cncZ7mW =fuhE -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] New lp-land command in bzr-pqm
On Wed, Feb 3, 2010 at 5:51 PM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan Lange wrote: On Wed, Feb 3, 2010 at 5:42 PM, Martin Pool m...@canonical.com wrote: I'm not sure if it matters but this seems a bit like it's putting lp-project-specific policy into bzr-pqm? Nope. Hooks are great. We didn't do the LP policy with hooks in lp-land. I think you're thinking of lp-submit? Oops. My bad. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] New lp-land command in bzr-pqm
Martin Pool wrote: I'm not sure if it matters but this seems a bit like it's putting lp-project-specific policy into bzr-pqm? It is, but it's not forcing that policy onto existing features, just the new one, so I don't see any harm. We can make the policy customizable, if it turns out people want that. Since we are getting into the subject, I would like to work find a better home for lp-project-specific plugins. For example, I would like to create a few helper commands like: bzr link-to-bug 321654 will link the current branch to the specified bug. bzr propose-merge 321654 will link the current branch to the specified bug and create a merge proposal with two requests for reviews from Landscape team members. bzr propose-merge will create a merge proposal, but only if the branch is already linked to a bug. We also have some existing ones that could be interesting to other people and were heavily borrowed from lp-submit, like 'bzr ls-pep8', which finds the files that have been changed from the submit branch (if not in a pipeline) or from the previous pipe (if in a pipeline) and runs pep8.py on them. -- Sidnei ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Urllib2 or curl as HTTP fetcher for python-openid?
By default, our version of python-openid uses pycurl, when installed, and falls back to urllib2 when not. That's not ideal as we might end up using one of them for tests and the other in production, so we should probably override that behaviour to make it always use the same[1]. Given that pycurl is not currently a dependency of lp-deps and that it causes problems when developing (it doesn't like our self-signed certs), I'd like to set urllib2 as the default. Any objections? [1] This is just a matter of calling openid.fetchers.setDefaultFetcher(Urllib2Fetcher) -- Guilherme Salgado salg...@canonical.com signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Nelson wrote: The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. So are we sure that building from a recipe should be a user-level thing at all? It seems like a major use case will be build this branch using this packaging branch. If we had a UI that just provided that, what percentage of our users would still need more? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktp43gACgkQ0F+nu1YWqI3+hACeKYDmTyGfBPDYhQ6qIlqKnNTh rqwAmwdrqIljcYoZJ3YFAgyRr5JG9jez =6dMY -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Wed, 3 Feb 2010 16:12:10 +0100, Michael Nelson michael.nel...@canonical.com wrote: I have some comments that are quite fundamental, but let me say first that I like the design for interaction, and I'm confident that whatever you end up going with will be a pleasure to use. The main point that underlies all my comemnts is that your focus is on building a branch using a recipe, rather than building a recipe. Yes, definitely. I had thought that the recipe is just a means to the user goal of building a branch. Sorry, I wasn't trying to minimise their importance or flexibility, but rather ensure that the desire I want to build this branch stays in focus. I agree that is an important aim. Why wouldn't this be possible? Given that if you click Build this branch (or whatever it'll be), the overlay will allow you to select the recipe you want (ie. including those recipes that just refer to this branch). That wasn't clear, sorry. I think the base branch being immutable in the overlay indicated to me that it was all that would be offered. but for daily builds that won't be the base branch. Yes, so if, from the packaging branch, you click on Build this branch and non of the available recipes meet your requirements, so you need to create a new recipe - then if you do want a base-branch different from the current one you're stuck at this point (with the current design, as the base-branch is non-editable). So I talked with jml about this the other day when thinking through the workflow, and from memory there were three thoughts: 1. The base-branch seems like the logical place to build your base-branch (and specifying the packaging branch from there). That's not to say it is the only way, just the most natural way for the 90% case. Do you have other thoughts? I think it may be skewed as I am an Ubuntu developer, but I don't think packaging branches will just be implementation details. For instance, you may decide you want to set up a daily build for a new project, which isn't packaged yet. To do this you branch, create the packaging and push it. They you may go to the packaging branch as that was just what you were working with. I'm not sure it's a good enough argument that it should change your approach, but perhaps something like giving them a message if they choose daily build while on a package branch. 2. we couldn't see how we could have a consistent UI if users specified the base-branch (as you could create a recipe that has nothing to do with the current branch at all. [1]) 3. The case where it *does* make sense to initiate the recipe creation from a packaging branch is when the packaging branch contains the source already, and hence it is the base_branch (ie. no other merges required to have both the debian directory and the source code toghether). I guess you are saying that there are other cases? Well, creating a recipe from a packaging branch is how you will build a package in a non-daily fashion, so that has to be supported, but it will be the base branch in that case. Given that you understand the workflows much better than anyone, I'd be keen to have a call sometime to clarify the above :) I'd be happy to do that. Next week is probably better as I guess we will be in closer timezones again. This is exactly what's displayed in the overlay isn't it (or the non-js version)? It would be difficult to display this information (the recipes) on the branch page itself, as there is no single bit of the recipe that helps users identify whether it's the one they're after. You'd need the recipe name, owner, (distroseries?), at the very least (hence that's what's displayed in the overlay dropdown, but even then you might need more information (revnos, packaging branch etc.), which is why the overlay displays that in-line. Makes sense. [ snip more convincing comments ] Some further unstructured comments: When viewing a source package recipe build within their PPA, users can: easily go to the recipe that was used and from there to the branches. They should also be able to go to the manifest and so see the revisions that were used. I'm keen for these links to be more common in Launchpad, from e.g. bugs to the revisions that fix them etc. Being able to go binary package-source package-manifest- branches will be useful. Yes, that's great. I've updated the wiki with: When viewing a source package recipe build within their PPA, users can: ... * View the manifest (and from there the related branches and recipe) Although it'd be worth a link from the manifest to the recipe, I wouldn't link directly to the recipe as it could be very confusing if the recipe has been edited since? Good point. Yes, the mockup wasn't meant to communicate that it was editable (just that you could create a new recipe) - my mistake. I've updated it to show the non-editable recipe selection/display. See what you think. Looks great.
Re: [Launchpad-dev] RFC on build from branch UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitrijs Ledkovs wrote: On 3 February 2010 20:58, Aaron Bentley aa...@canonical.com So are we sure that building from a recipe should be a user-level thing at all? It seems like a major use case will be build this branch using this packaging branch. If we had a UI that just provided that, what percentage of our users would still need more? IMHO it would be 50/50 split cause I'm still thinking in terms of packaging branch as the starting point and which branches do I want to build using it. I am contrasting a UI that speaks in terms of branches and package branches with a UI that speaks in terms of recipes. I think that it's more intuitive to talk about the branches, and that providing recipes in the UI may be overkill, but I could be wrong and I want feedback. It sounds like you're saying that you'd like a UI on the packaging branch that lets you build other branches using it, instead of doing that from the individual branches. That's valid, but it answers a question I didn't mean to ask. For example as an upstream project maintainer I will strive to minimize amount of packaging branches / recipes cause that's not usually upstream expertise. So I would have one packaging branch possibly pinched of ubuntu and then I will go to it and start thinking which of my project branches I want to build eg. stable release, supported release and this wacky hack I'm working on. None of this requires recipes to be exposed to users. Since, as currently formulated, recipes specify their base branch, you would need a different recipe for stable, supported, and wacky hack. And ooops hardy has different lib sonames so i need to use this other packaging branch cause it has build time patch. As described, this doesn't need user-level recipes either, but another approach might. Instead of having a different packaging branch with the build-time patch, you could have a branch with just the build-time patch. That would be a reason to use the full power of recipes. This feature will be a popular both from Ubuntu development side and the upstream projects using launchpad for project management, QA / ubuntu experience enhancement. Note that this feature only builds native packages at the moment, so it will not be suitable for building packages for the main archive until that changes. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktp7WEACgkQ0F+nu1YWqI2NaQCbBAcpZHcB7ticB/dhAySD3/rS AoYAn1eILuW9ahLaWPosUcRYHuuNHLEf =cno3 -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] +patches view (story-patch-report) has landed.
The +patches view code has landed on db-devel, which means it will be live on https://staging.launchpad.net/ someday soon. But see below for more on what soon means -- it can be, like, a couple of days :-(. Many thanks to adeuring, intellectronica, and allenap for their persistence in getting this done. The revision of interest is: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8961 To use +patches, you'd visit URLs like: https://bugs.staging.launchpad.net/PROJECT/+patches https://bugs.staging.launchpad.net/PROJECTGROUP/+patches https://bugs.staging.launchpad.net/DISTRO/SERIES/+patches https://bugs.staging.launchpad.net/DISTRO/SERIES/+source/PROJECT/+patches https://bugs.staging.launchpad.net/~PERSON/+patches https://bugs.staging.launchpad.net/~TEAM/+patches There'd have to be bugs with patch attachments associated with those entities, for those URLs to show much. I'm not sure what's in the staging database, though -- you might need to create some bugs and patch attachments. Of course, there are always these screenshots too: http://people.canonical.com/~kfogel/patches-view/screenshots.html (That's mostly up-to-date. There have been a few UI improvements since then, but it'll give you a good idea of what the feature looks like.) So when will this feature be live on staging? Unfortunately, it may take a couple of days, though if we're lucky it could happen sooner. The db-devel - db-stable - staging path is complicated and fraught with guardian monsters straight out of Greek mythology, including the BuildBot, a many-headed, many-tentacled beast charged by Zeus with protecting the gates to Augean DB-Stables. (Stay with me, please; I'm making this up as I go along.) The pretty diagrams at https://dev.launchpad.net/Trunk describe the exact process. Steve McInerny and I talked about the situation: kfogel spm: so basically, we shouldn't count on this being live on staging by Friday morning US west coast time, though it *might* happen, right? spmkfogel: the only way it's even got a chance is if I stop the existing restore; and hold pending that landing getting thru buildbot; and even then... yeah, cutting it fine. spmkfogel: is the DB side critical? as in the other changes as part of the set should be on edge; or soon will be? kfogel spm: the db changes are a critical part of the overall change, yes kfogel spm: this stuff hasn't landed on devel, afaik, since it needs its db changes. It's only in db-devel. So I'm not expecting to see it on edge right away. spmkfogel: oki; I'll see what I can do, but zero promises unf. these restores are not fast So, we'll see. Jorge, if you want screenshots, grab from above. The screenshots don't happen to have an example of sorting on patch age, but that *is* in the branch, rest assured. -Karl ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
