[dojo-contributors] Submitting fixes - best practices?

Kitson Kelly kitson.kelly at asseverate.co.uk
Sat Jun 30 04:16:25 EDT 2012


They are standard unified diffs...  Trac is the one that interprets them
and marks them up.  It is more standard practice to apply the .patch
extension to them though than .diff.  Even it is new files, it is best to
utilise a diff.  What I tend to do is use git to produce a diff against my
private fork against the the upstream tracking repository:

git diff upstream/master > ../something.patch


If you have dojo trunk checked out from SVN, you should be able to at least
run the regression modules by navigating to them in your browser.  For
example dojox/rpc/tests/runTests.html will bootstrap DOH and run the
appropriate test files.  Modifying them is fairly straight forward,
although the vast majority of them haven't been refactored for AMD yet.

On 30 June 2012 09:01, Ken Benjamin <kenbenjamin at kenbenjamin.net> wrote:

> Thanks, Kitson, that helps a lot.
>
>
>
> How are those pretty diff files generated for Trac? I’m using Windows so
> if there is some special tool that does it (other than a regular command
> line “fc”), I’d like to know. Do you just generate the difference, put a
> .diff extension on it and upload it?
>
>
>
> Re. the patch I submitted, it’s a regression in 1.8b1 for dojo/_base/xhr.
>
>
>
> [patch][cla] already attached. Testing, yes, but not via DOH. I haven’t
> gotten into DOH yet but will take a look. This should be a clean patch but
> definitely needs an expert eye since it’s in core.
>
>
>
> Direct and robust feedback sounds good. Maybe I’ll learn something new.
>
>
>
> Ken
>
>
>
> *From:* dojo-contributors-bounces at mail.dojotoolkit.org [mailto:
> dojo-contributors-bounces at mail.dojotoolkit.org] *On Behalf Of *Kitson
> Kelly
> *Sent:* Saturday, June 30, 2012 9:45 AM
> *To:* dojo dev.
> *Subject:* Re: [dojo-contributors] Submitting fixes - best practices?
>
>
>
>
>
> Standard practice is to attach a diff patch to the ticket.  As in the case
> with the one you point out, it doesn't have an owner yet until.  Once it
> gets triaged it will be assigned an owner, who is a committer and it will
> be up to that owner to determine what action to take.  They may take your
> patch wholesale, or may need to adjust it.  Sometimes they will give you
> feedback on your patch, if it doesn't match the coding style (
> http://livedocs.dojotoolkit.org/developer/styleguide) of the toolkit and
> may request that you modify the test cases and the documentation as well.
>
>
>
> Usually it is best to note when you submit your patch that you have a CLA
> on file (if it is a CCLA, you should note what organisation).
>
>
>
> You should have tested your patch against the appropriate DOH unit test
> cases to ensure it doesn't introduce a regression and you should ensure it
> patches cleanly into trunk.  It is also important to understand where we
> are in the development cycle.  Right we are on a feature freeze, so nothing
> that would appear to be an API change or enhancement will get accepted.
>
>
>
> Be prepared for fairly robust and direct feedback on your code.
>
>
>
> On 30 June 2012 08:22, Ken Benjamin <kenbenjamin at kenbenjamin.net> wrote:
>
> As a newcomer to this list, I’d like to know the best approach for
> submitting code fixes.
>
>
>
> Specifically, I encountered an important bug in dojo/_base/xhr (submitted
> w/fix in Trac http://bugs.dojotoolkit.org/ticket/15591) that highlighted
> the need to update dojo/rpc/* to support dojo/request.
>
>
>
> dojo/rpc/* works correctly with the submitted fix to dojo/_base/xhr so
> nothing really **needs** to be done until 2.0 but…
>
>
>
> Should I:
>
> A)     submit updated versions of dojo/rpc/* to Trac
>
> B)      submit some other way, how?
>
> C)      ignore dojo/rpc and let someone else deal with it
>
> D)     ignore dojo/rpc because “dojox/rpc will replace it” (when? really?)
>
>
>
> I have a CLA on file but I’m reluctant to be a committer as I’m not
> sufficiently confident or experienced enough in Dojo to know for sure that
> my fixes might not break something else. I really need an experienced eye
> on the code I submit just to be sure (or what passes for sure in software
> development).
>
>
>
> Thanks,
>
> Ken
>
>
>
>
>
> [image: Ken-Headshot1-2012-75x75]
>
> Kenneth Benjamin
>
>
>
>     WisdomWebsite.com <http://wisdomwebsite.com/>
>
> The wisdom you need to live well.
>
>
>
> Follow on:
>
> Google+ <https://plus.google.com/u/0/111911356299615046076>
>
> Twitter <http://twitter.com/WisdomWebsite>
>
> LinkedIn <http://www.linkedin.com/profile/view?id=155905078>
>
> Facebook <http://www.facebook.com/pages/WisdomWebsitecom/169562026394287>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120630/fc55f6cd/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2104 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120630/fc55f6cd/attachment.jpeg 


More information about the dojo-contributors mailing list