[PATCH 000/119] staging: brcm80211: more code cleanup and bug fixed

Henry Ptasinski henryp at broadcom.com
Thu Jun 30 21:40:19 UTC 2011


On 06/30/2011 11:32 AM, Dan Carpenter wrote:
> On Thu, Jun 30, 2011 at 10:42:31AM -0700, Henry Ptasinski wrote:
>> On 06/29/2011 11:29 PM, Rafał Miłecki wrote:
>>> 2011/6/30 Franky Lin<frankyl at broadcom.com>:
>>>> Most of these patches are brcmfmac cleanup.
>>>
>>>
>>> Hm, interesting improvement in your "Release early, release often" strategy.
>>>
>>
>> Yea, we were waiting for the previous series to get applied.  Not
>> sure how to make this work better.  Any process suggestions would be
>> appreciated.
>
> Maintain your own git tree.  Post patches in bunches.  If no one
> comments on them within 3 days then probably you can assume they
> are going to be merged.  In the [0 / X] patch say something like:
>
>    Fixes blah blah blah.
>
>    Applies to linux-next with the following patch sets applied:
>    Message-ID:<1309391303-22741-1-git-send-email-frankyl at broadcom.com>
>    Message-ID:<8888888888-88888-1-git-send-email-frankyl at broadcom.com>
>    Or you can get the patches from git://whatever branch.
>
> regards,
> dan carpenter
>

So there are two suggestions here:

1. post patches in smaller bunches, and include dependency info in the 
0/X patch.  Presumably, if one of the dependencies is dropped, then 
people will know to drop this series as well, and we would have to 
repost everything that was dropped once we fix the identified issues.

2. maintain a public git tree that people can pull from.  If we do (1), 
is this needed and/or still useful?  Do community folks that want to 
contribute changes send them to us or Greg/John/whoever is upstream? 
Pros/cons?  Anybody have tips on workflow (my git mastery is still quite 
weak)?

Thanks,
- Henry





More information about the devel mailing list