Re: [PATCH] added a .bb for node.js

["J. L. " <vwyodapink@gmail.com>]

Great write up AJ once again I wasnt even aware of some of those
steps. Probably why a patch I tried to send in a long while ago never
showed up again nor did I hear anything. Thanks for taking the time to
write out those steps and very clearly, hope to see more on your blog
as well about all this. I hope I will get the hang of all this soon,
but I still cant get programs I want to build using BB.



On Mon, Aug 23, 2010 at 4:20 PM, AJ ONeal <coolaj86@gmail.com> wrote:
>>
>> > > Please also remember to update the patch queue [2].
>> > >
>> >
>> > Update it to what?
>> >
>> > That link you gave me is very unclear
>> >
>> > It is desirable to update the state of the patch in the patch queue. This
>> > > could also be added to the script.
>>
>> This sentence addresses the case when your patch is accepted.
>>
>
> I already marked the first two as superseded
>
>
>> > The patch is listed as "new". I'd agree with that state. It certainly
>> isn't
>> > "accepted" - that's someone else's job to put that, right?
>>
>> Reading the reviews your patch got you need to improve it a little bit.
>> So after you send in the next iteration of your patch – v2 in our case –
>> you should update the state to superseded.
>>
>
> If you look at the newest patch I already implemented all of those changes
> excepting that I didn't do the Signed-off-by and the patch includes the [v2]
> in the commit message.
>
> Do you still want me to submit again with just those changes?
>
>>> All I do to add that is --signoff, correct?
>
>> No. Please take a look at the link I gave you [1] and the other patches
>> sent to this list.
>
> Again, I don't think that's very clear
>
> - Include a Signed-off-by: line indicating the change has valid certificate
>
> of origin as per the Linux kernel
>
>
> What is a valid certificate of origin?
>
> How about an example? You correct me where I'm mistaken and then I'll copy
> this to the wiki as reference
>
>
>
>
> Let's say you create a new recipe and you'd like to submit it for inclusion
> (and you've already tested that it works, of course).
>
> Now commit with a good strong helpful message
>
>    git add recipes/nodejs/
>    git commit # don't use the -m option
>
> The message should look like this
>
>    added recipe for node.js
>
>    * added recipe for node.js (bug #5555 - no nodejs recipe)
>    ** patched libev's wscript to not try to execute code
>    ** patched node's wscript to not search in '/usr/include'
>
>    Signed-off-by: AJ ONeal <coolaj86@gmail.com>
>
> Create your patch
>
>    git format-patch -1 # or however many commits are part of this change
>
> If you are submitting a second version also add "--subject-prefix [v2]"
>
>    git send-email
>
> Your patch will be immediately visible on
> http://patchwork.openembedded.org/patch/
> Once your patch has been accepted or rejected, update the status to
> "accepted" or "rejected"
>
> If you get soft-rejected (a lot of feedback), make the changes, submit the
> next version, and update the status of the previous patch to "superseded"
>
> Appendix: Properly configuring git (using tekkub@gmail.com as an example
> user)
>
>    sudo apt-get install git-core git-email
>    git config --global user.name "Tekkub"
>    git config --global user.email "tekkub@gmail.com"
>    git config --global sendemail.smtpserver smtp.gmail.com
>    git config --global sendemail.smtpserverport 587
>    git config --global sendemail.smtpencryption tls
>    git config --global sendemail.smtpuser tekkupl@gmail.com
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>