On Wed, May 11, 2011 at 9:15 AM, Darren Hart <dvh...@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 > _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core