[poky] RFC: create-pull-request / send-pull-request updates

[Khem Raj]

On Wed, May 11, 2011 at 9:15 AM, Darren Hart <dvhart at linux.intel.com> wrote:
> Between myself and others, there are several outstanding proposals to
> modify the pull-request scripts. Patches have been sent, but nothing has
> been merged due to a lack of consensus. I thought I would summarize what
> I see to be the current weaknesses of the scripts and my proposal to
> address them. I would like your feedback to ensure we have tools that
> meet the needs of a broad user base. Once we agree, I'll be happy to
> write up the patches or help review those written by others.
>
> 1) send-pull-request is too aggressive with the auto-cc feature (Khem
>   Raj)
>
>   One of the reasons I wrote these scripts was out of frustration with
>   git-send-email which allowed for a cover letter, but didn't include
>   all the collected addresses on it. The current script sends every
>   message to all the collected addresses. Khem (and others) have found
>   this behavior to be sub-optimal, if not down right annoying.
>
>   I propose it be modified to only use the addresses local to each
>   patch for the patches and all the collected addresses only for the
>   cover letter.
>
>   a) Do people agree with this policy? If not, and people prefer the
>      cover-letter only be sent to the recipients specified on the
>      command line, then this script doesn't add any real value over
>      'git request-pull' and 'git send-email', and users can easily
>      wrap those on their own.
>
> 2) create-pull-request needs to facilitate the use of multiple
>   repositories (Tom Rini)
>
>   Some folks find gitorious or github work best for their use. It is
>   also reasonable to want to use this script with independent layers.
>   Tom proposed a -l option to specify the PULL_URL leaving some
>   boiler-plate text in the cover-letter for the user to populate.
>
>   This dovetails with something I've been considering. Rather than
>   duplicate the generation of a pull request cover letter, I'd like to
>   see us re-use the output of 'git request-pull'. This has the added
>   benefit of sanity checking the URL and commits. It does however
>   remove the concept of the BROWSE_URL. We could add the BROWSE_URL
>   back for recognized locations (git.yoctoproject.org, gitorious, and
>   github I believe).
>
>   Some have expressed a desire for the URL to be automatically
>   discoverable. We could try and extract this information from the
>   current branch and a remote of a specific name, with some URL
>   rewrites to convert ssh access to generic git access. Unfortunately,
>   this approach breaks under several conditions. I would prefer that
>   these scripts not be tied to any particular naming conventions for
>   the git branches or remotes.
>
>   I propose we go with something very similar to Tom's -l PULL_URL
>   proposal and replace the cover letter generation with the output of
>   'git request-pull'. The PULL_URL should also be able to be specified
>   via an environment variable. Now that we are sending patches for
>   review and not just the pull request itself, I feel we can drop the
>   BROWSE_URL.
>
> 3) Rely on git-send-email exclusively (Darren Hart)
>
>   When I originally wrote these scripts, not all the users were
>   particularly familiar with git and others may have already had
>   a local sendmail client configured. At the time I thought it prudent
>   to decouple the mail process from git. In retrospect, this serves
>   only to unnecessarily complicate the send script as users must all
>   learn git to effectively work within the OE and Yocto environments.
>   If a local MTA is available, git can be configured to use that. There
>   is no advantage that I can see to maintain both sending mechanisms
>   in the scripts. They add complexity and complicate debugging and
>   maintenance.
>
>   I propose the local sendmail mechanism be removed from send-pull-
>   request and that it rely exclusively on 'git send-email'.
>
> 3) Rewrite the scripts in python (Tom)
>
>   While I agree that anything of any significant complexity is better
>   written in python than bash, I feel that with the above changes, the
>   current scripts will be smaller and remain simple enough for bash to
>   be a viable option.
>
>   I propose we leave the scripts in bash for the time being, leaving
>   the door open to rewrite them at a later date should their complexity
>   increase to merit the effort.
>
>
> Thoughts/Comments?
>

I would suggest to alter the process a bit and get rid of the scripts
completely. Patches are sent to mailing list for review once reviewed
the final patches are
sent as git pull-request. It would simplify things.

> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>