Re: HULK management policy and user manual-v1.4//Re: æéäååçæèïäæäéååæççã//ææçäåæçæççççäåæäæå//Re: çèääåäèèéåääå // Re: èåäæäèé git æååçåé // Re: Fw: éèååäèåégitäåmaillistçåå

[Ding Tianhong]

On 2014/5/7 10:45, Li Zefan wrote:
> On 2014/5/6 20:19, Ding Tianhong wrote:
>> On 2014/5/6 19:15, sanil kumar wrote:
>>> On 5/6/2014 4:37 PM, Ding Tianhong wrote:
>>>> On 2014/5/6 17:29, maobibo 00177601 wrote:
>>>>> Hi Tianhong,
>>>>>
>>>>> I have two questions about the HULK
>>>>>    1) When we get kernel from HULK such as euler-arm64branch, if there are some bugs in the branch and we report this bug,
>>>>>       will CSI team be responsible to fix the bug?
>>>>
>>>> If the bug is exist in the kernel and not from third-party application just like Customer's own drivers, I have to say "YES", we
>>>> will fix them and upstream them.
>>>>
>>>>
>>>>>
>>>>>    2) When we submit a patch to HULK and if it is accepted, will CSI team be response to push it to upstream mainline branch?
>>>>>
>>>>
>>>>
>>>> If this patch is developed by yourself, and only for features or capabilities, you have to upstream the patch yourself.
>>> If we don't have strategy to handle this, we may end up facing issues with long term maintenance of HULK. Do you see this risk?
>>> This can be applicable to any patches whether its coming from external or internal members of CSI.
>>
>> Hi sanil:
>>
>> Yes, I got your opinion, and we already face this problem several times, in principle everyone should be responsible for their own code,
>> I hope every patch in our HULK repository could be applied to linux mainline tree, the CSI should help them to make the code more in line
>> with the community standard, it is a relationship, not a obligations.
>>
>> So I think we should discuss the strategy together, In my opinion, there is no external or internal members of CSI, everyone is a
>> kernel developer, if the code or patch has a good reason to upstream to the linux mainline tree, the author should have responsibility to handle
>> this work, if the author met some problem and could not handle this alone, our HULK team should help him to upstream, this is a great team should do.
>>
>> Hi zefan: 
>> As a senior expert, can you give us more suggestion to handle this, thanks.
>>
> 
> As I'm not working on arm64, I don't know how you guys have been co-operating. :)
> 
> Can't we learn from the development process of LSK?
> 
> How about we obey a rule "upstream first". Patches are sent to our internal mailing
> list for review, and then they should be sent to the community. They won't be accepted
> by HULK util they are merged into mainline, or you have to explain why they aren't
> accepted and why it's ok for HULK to merge them though.
> 
> The principal is we should all work on upstreaming our code. We can't ask HULK to
> do all the upstream work.
> 
> The community doesn't like delegation, which means it should be the author that submits
> the patch. However this is not a strict requirement. If you can fully understand the
> patch and you're able to answer people's comments on this patch when it's posted, you
> may submit it given you've got the autoher's approval.
> 

Hi zefan:

Thanks for your suggestion, I think it is more clear and reasonable, if we need deeper discussion, the branch maintainer for CHI and Hisilicon need to enter
this discussion.

Hi guozhu, wangwei:

I need to know the branch maintainer for your department, please tell me the name and then I could discussion with them for the strategy and perfect the HULK document,
thanks for any suggestion.

Regards
Ding

> btw what does CSI mean?
> 

Central Software Institute :)

> 



> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/