On Thu, Feb 02, 2017 at 10:51:37AM +0100, Greg KH wrote:
On Thu, Feb 02, 2017 at 09:08:15AM +0000, Amit Kumar wrote:
On Thu, Feb 02, 2017 at 08:10:56AM +0100, Greg KH wrote:
On Thu, Feb 02, 2017 at 05:11:32AM +0000, Amit Kumar wrote:
On Wed, Feb 01, 2017 at 01:54:16PM +0000, Amit Kumar wrote:
Hi, As I know quilt is used by maintainers. But kernel source code is maintained in git repo. So I want to know how git and quilt work together. I have found a video in which Mr. GregKH has explained how he applies patches to the stable tree. But this video is short and needs several view to understand what is going on.
Do you have questions about it? I use git-send-email and msmtp combination. I also use mutt and msmtp combination. Could you provide me quilt mail and git-send-email configuration?
You already have git-send-email working, what do you need changed there?
As for quilt mail, what did you try that did not work?
In mutt I have seen that a mail sent by Mr. GregKH has quilt mail as user agent and git-send-email as x-mailer. It means he is using git-send-email as a backend for quilt mail.
Last but not least, I think if a developer starts using quilt to maintain his diferent versions of a patch, it will ease a maintainer job. I'm in the process of making developers available upto minute code under change.So duplicate patch problem can be solved.
What duplicate patch problem? Sometimes when a developer sends his patch. He receives a reply this patch has been already submitted by another developer.
I think the reason is that when a developer starts working on a patch, he has not bleeding edge copy of maintainers tree. There is a long review cycle of patch which is required for a large project as Linux.
Define "long" :)
Of course there will be conflicts, that's just the nature of working on a distributed project where no one can "lock" any portion of the tree. Just redo your patch and move on. Nothing complex there.
So I request kernel experts their words.
What question do you have? So, I have a solution. As patches are collected on patchwork.kernel.org. While patches are under review, it can be tracked by a bot and show lines of code,on a web page, which will be affected on the basis of currently submitted patch. So, developers don't touch those lines of code.
Nope. That would prevent others from doing work, which is never a good idea.
How often have you really hit this issue? As someone who reviews more patches than anyone else in the kernel, I see it happen only very infrequently (i.e. less than 1% of the time.) Yes. This is only a view for developers which shows which area of tree is expected to change and under process, but we can't force anyone to not touch that area of code.
I also propose in-queue branch(patches in queue to be applied) for maintainers, which will help a maintainer to know which patches has been selected by other maintainer. I think there will be less conflicts.
Where are the conflicts you see happening? Again, is this really a big problem that you are trying to solve here? I haven't heard any other maintainer complain about it, you do know about linux-next, right?
I see whenever linux-next maintainer merge, he complains about manual resolution of conflicts.
If you help me answering few questions as I develop this system, I will be grateful to you.
Don't work to solve a non-existant problem :)
Ok, I consider your suggestion and first involve in kernel development process heavily and then watch for problem. Last but not least, Thank you for your replies.
thanks,
greg k-h