[12:20] <ddaa> wow! colors in the pending branches summary!
[12:21] <ddaa> looking at the diff now
[12:21] <ddaa> https://devpad.canonical.com/~jamesh/pending-reviews/tim/launchpad/spec-branches/full-diff
[12:22] <ddaa> so... one of the things we agreed on with tim
[12:22] <ddaa> was _not_ to make spec branches look like bugbranches
[12:22] <jamesh> okay
[12:22] <ddaa> in particular, the rule of thumb was "no YAGNI"
[12:22] <ddaa> so, no bugbranch status
[12:22] <ddaa> uh
[12:22] <ddaa> no specbranch lifecycle
[12:23] <ddaa> specificationbranch.summary was added on poolie's request
[12:23] <ddaa> we also decided to make the specbranch page a form
[12:24] <jamesh> so this would be used for comments related to the connection as opposed to spec.whiteboard or branch.whiteboard
[12:24] <ddaa> yes
[12:25] <ddaa> the sort of thing you'd display in body of the spec page and the branch page
[12:25] <ddaa> so, unlike the rest of launchpad, where every object has one read-only _page_ and a number of forms, we decided to have a single form for spec branch that allows editing the details _and_ deleting the spec-branch.
[12:25] <jamesh> so, the main things needed is the browser code, then?
[12:27] <ddaa> right... the form declaration in the zcml is commented out
[12:27] <ddaa> note that defaultView is +status
[12:28] <jamesh> so who should be able to edit what?
[12:28] <ddaa> no comment on specificationbranch.summary too
[12:28] <ddaa> mh
[12:28] <jamesh> +      <require
[12:28] <jamesh> +          permission="launchpad.AnyPerson"
[12:28] <jamesh> +          set_attributes="summary" />
[12:28] <ddaa> I guess the answer would be something "who has the right to edit spec details"
[12:28] <jamesh> is that accurate?
[12:28] <ddaa> but I'm at a complete loss with the spec permission scheme...
[12:30] <ddaa> mh...
[12:30] <ddaa> it's fine with me
[12:30] <ddaa> do you have a better suggestion?
[12:31] <jamesh> if the idea is to have a single form, and be able to delete the link from there, that sounds fine
[12:31] <jamesh> no need to handle changing the branch or spec fields of the link
[12:31] <ddaa> right
[12:32] <jamesh> It does leave the question of who should be allowed to delete the link though
[12:32] <ddaa> the same as who is allowed to create it :)
[12:32] <ddaa> just "any authenticated user" seems fine to me
[12:33] <jamesh> do we base that on the specification permissions then?
[12:33] <ddaa> I have do not grok spec permissions
[12:33] <ddaa> I guess that to preserve the current level of permission it should be "whoever is able to edit the spec whiteboard"
[12:34] <jamesh> yep
[12:34] <jamesh> spec.whiteboard has launchpad.AnyPerson permission
[12:35] <ddaa> then go for it
[12:36] <ddaa> To add a spec-branch, we also need at least one form. We have a branch vocabulary that can be restricted per product. I'm in favour of using the unrestricted branch vocabulary.
[12:36] <ddaa> and put the form in the context of the spec
[12:38] <ddaa> the add form should redirect to the context object (not the specbranch form), and allow setting the summary directly.
[12:38] <ddaa> while you are at it, it would be nice if the branch vocabulary could be extended to recognise the canonical url of branches in launchpad.
[12:39] <jamesh> you mean the bazaar.launchpad.net ones?
[12:39] <ddaa> initially, we do not need the ability to create a spec-branch from the branch page
[12:39] <ddaa> jamesh: I mean launchpad.net/people ones
[12:40] <ddaa> so people can find branches by browsing around, and copy-paste the url of the page, I remember I tried it myself in the past :)
[12:40] <ddaa> but that's arguably an orthogonal change
[12:41] <ddaa> That all I can think of right now.
[12:41] <ddaa> Keep it as simple as possible, and maybe a bit more simple than that if you can get away with it.
[12:42] <ddaa> Any question?
[12:45] <jamesh> nope.  I think that covers it
[12:46] <ddaa> Okay. Thank you for your help.