PQM Work This Summer

[Martin Pool]

On Tue, Jul 1, 2008 at 1:00 AM, Wichmann, Mats D
<mats.d.wichmann at intel.com> wrote:
> Martin Pool wrote:
>
>>>  brainstorm this at the London sprint[0], but I'm looking for what
>>>  amongst those ideas people consider most important.
>
> two things:
>
> merge directives
>
> what we call the "phantom merge", the thing that means that when
>  my merge goes through, the branch I generated the merge from is
>  now suddenly out of date wrt. the branch I merged to

Maybe this should be handled by allowing merge directives to specify
"please pull if you can", so they won't make a new revision if it's
not necessary.  (Maybe this should not be the default as you then
don't get a clear record of which revisions were tested by pqm, but it
might be a reasonable option.)

Obviously if someone else has committed before you a merge has to
happen somewhere and perhaps you want pqm to do it.  But perhaps it
would even be reasonable to want to do all merges yourself, and so say
"pull, or otherwise fail."

Alternatively you can do merge --pull yourself after pqm succeeds...

>> I think all the other points suggested are good, but as an overall
>> approach I suggest you look from the point of view of someone new
>> setting up pqm, and see what barriers might be in their way.  Is it
>> packaged and adequately documented?  If there are things that are hard
>> to describe or hard to do correctly that gives you an idea of
>> something to improve in the code.  You can also take the approach of
>> writing hypothetical docs as if the perfect code already existed then
>> looking at the gaps from reality.
>
> With respect, getting this right is crucial but it's really better
> (at least documenting the issues) coming from folks who are having
> the problems; normally someone who's very familiar with setting up
> a moderately complex system already initimately understands the
> details and they don't seem unclear/difficult/etc. in the same way.

I agree.  But I think here Daniel has some amount of "beginner's mind"
and may be able to do it.

Alternatively maybe you (and other people on the list) could draft the
way you'd like the documentation to be, and we can work towards that.


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