linux-kernel - Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a platform driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20140214101725.GC9462@lee--X1>
Date:	Fri, 14 Feb 2014 10:17:25 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Laszlo Papp <lpapp@....org>
Cc:	Jean Delvare <jdelvare@...e.de>,
	LKML <linux-kernel@...r.kernel.org>, lm-sensors@...sensors.org,
	Guenter Roeck <linux@...ck-us.net>
Subject: Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a
 platform driver

On Fri, 14 Feb 2014, Laszlo Papp wrote:

> On Fri, Feb 14, 2014 at 9:02 AM, Lee Jones <lee.jones@...aro.org> wrote:
> >> >> http://comments.gmane.org/gmane.linux.kernel/1645251
> >> >>
> >> >> Step 2 did not happen. I did not get any review for my change. I
> >> >> literally submitted that within a couple of hours after the request.
> >> >>
> >> >> Could you please tell me what was wrong with that change, and why I
> >> >> did not get any respect not to "xargs rm -rf" my work in that area? I
> >> >> believe I was ignored instead of improving the change, and someone
> >> >> else tried to address the same thing. There was no argument in that
> >> >> thread. It was a technical change. I personally do not feel happy
> >> >> about it.
> >> >
> >> > Let's start again.
> >> >
> >> > Rebase your work on top of the HWMON tree on kernel.org and resubmit
> >> > the entire set. If rebasing takes you more than 20 mins, you're
> >> > probably doing it wrong.
> >>
> >> I tried, but I could not manage it within 20 minutes, so I guess I am
> >> doing something wrong. Can you please provide some pointers how not to
> >> do it wrong? Perhaps, I am not aware of some tricks.
> >
> > One question, are you still working on this stuff or not? I'm confused
> > by the disparity in your messages. I'm going to guess that you're in
> > for now.
> >
> > Do:
> >   `git rebase -i <base> --onto <newbase>`
> > Where:
> >   <base> is the SHA1 of the first patch below your changes in `git log`
> >   <new_base> is Guenter's staging tree on kernel.org
> >
> > Ensure you're rebasing all of your patches (and patches that aren't
> > yours) when your $EDITOR pops up. If they are wrong, delete all the
> > lines in the file and the rebase will be aborted. If they're correct
> > save and close your $EDITOR.
> >
> > You'll receive conflicts. You can see the state of the conflicts using
> > `git status` Open the file, find the conflict markers and make a choice
> > from the HEAD section or the section from your patch. Sometimes
> > you'll need to manually merge the two, if there are changes from both
> > refs that you want to keep. Once you're happy `git commit -a` and `git
> > rebase --continue`. Each conflict should not take you long, but if it
> > does, keep at it, as it's good practice. After a time of doing it,
> > you'll be able to fix merge conflicts in no time at all.
> 
> Right, that is what I have been following myself for a couple of
> years.

> Why it took me more time because I had to go through his
> changes and to understand all in details to make reasonably good
> decisions what to keep and what to drop at the conflicts.

Correct, that's what will improve with time.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/