launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 8 February 2010 21:53, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> On Fri, Feb 5, 2010 at 4:52 AM, Paul Hummer <paul@xxxxxxxxxxxxx> wrote:
>> On Wed, 3 Feb 2010 17:41:32 -0200
>> Sidnei da Silva <sidnei.da.silva@xxxxxxxxx> wrote:
>>
>>> > 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.
>>
>> Jono set up a project a while ago which I put code up for called
>> bzr-launchpadplus.  Maybe some of your code can go in there.  I meant it to be
>> a place to but bazaar plugins for working with launchpad, with the idea that
>> it's something like a bzrtools for launchpad specific stuff.  The things that
>> are really helpful could then go into bzrlib proper.
>
> Yeah, but now that bzr comes with launchpadlib support, I think that
> bzr-launchpadplus should be merged with core, and perhaps reserved as
> a ground for plugin experimentation.

I just realized my earlier statement about 'lp-specific policy' was a
bit ambiguous.

1- Code that talks to Launchpad is fine and very welcome.  If it makes
sense to cast it as a Launchpad-specific implementation of a more
general project-hosting function (like linking a bug or proposing a
merge) that may be cleaner, though obviously some commonsense about
yagni is needed too.

2- Code that is specific to working on Launchpad, like the particular
style of your commit messages or the way you use ec2test, pqm and
buildbot, is more questionable.  I'd really want to see this turned
into either an example in the documentation of "how you can script bzr
for your project" or something quite generic, or both.

>From Aaron's original description it looked a lot like #2.

-- 
Martin <http://launchpad.net/~mbp/>