* [PATCH] ehci-hcd: remove useless timeout @ 2016-03-03 12:48 Aleksey Kuleshov 2016-03-04 7:11 ` Sascha Hauer 0 siblings, 1 reply; 13+ messages in thread From: Aleksey Kuleshov @ 2016-03-03 12:48 UTC (permalink / raw) To: barebox; +Cc: Aleksey Kuleshov --- drivers/usb/host/ehci-hcd.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 862444b..9327015 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1189,7 +1189,6 @@ static int ehci_destroy_int_queue(struct usb_device *dev, struct usb_host *host = dev->host; struct ehci_priv *ehci = to_ehci(host); struct QH *cur = ehci->periodic_queue; - uint64_t start; if (disable_periodic(ehci) < 0) { dev_err(&dev->dev, @@ -1198,7 +1197,6 @@ static int ehci_destroy_int_queue(struct usb_device *dev, } ehci->periodic_schedules--; - start = get_time_ns(); while (!(cur->qh_link & cpu_to_hc32(QH_LINK_TERMINATE))) { dev_dbg(&dev->dev, "considering %p, with qh_link %x\n", @@ -1211,12 +1209,6 @@ static int ehci_destroy_int_queue(struct usb_device *dev, break; } cur = NEXT_QH(cur); - if (is_timeout_non_interruptible(start, 500 * MSECOND)) { - dev_err(&dev->dev, - "Timeout destroying interrupt endpoint queue\n"); - result = -ETIMEDOUT; - goto out; - } } if (ehci->periodic_schedules > 0) { -- 2.6.2 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-03 12:48 [PATCH] ehci-hcd: remove useless timeout Aleksey Kuleshov @ 2016-03-04 7:11 ` Sascha Hauer 2016-03-04 10:42 ` Aleksey Kuleshov 0 siblings, 1 reply; 13+ messages in thread From: Sascha Hauer @ 2016-03-04 7:11 UTC (permalink / raw) To: Aleksey Kuleshov; +Cc: barebox Hi Aleksey, On Thu, Mar 03, 2016 at 03:48:52PM +0300, Aleksey Kuleshov wrote: > --- > drivers/usb/host/ehci-hcd.c | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index 862444b..9327015 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -1189,7 +1189,6 @@ static int ehci_destroy_int_queue(struct usb_device *dev, > struct usb_host *host = dev->host; > struct ehci_priv *ehci = to_ehci(host); > struct QH *cur = ehci->periodic_queue; > - uint64_t start; > > if (disable_periodic(ehci) < 0) { > dev_err(&dev->dev, > @@ -1198,7 +1197,6 @@ static int ehci_destroy_int_queue(struct usb_device *dev, > } > ehci->periodic_schedules--; > > - start = get_time_ns(); > while (!(cur->qh_link & cpu_to_hc32(QH_LINK_TERMINATE))) { > dev_dbg(&dev->dev, > "considering %p, with qh_link %x\n", > @@ -1211,12 +1209,6 @@ static int ehci_destroy_int_queue(struct usb_device *dev, > break; > } > cur = NEXT_QH(cur); > - if (is_timeout_non_interruptible(start, 500 * MSECOND)) { > - dev_err(&dev->dev, > - "Timeout destroying interrupt endpoint queue\n"); > - result = -ETIMEDOUT; > - goto out; > - } My first reaction was to ask you why you think that this timeout is useless. Looking close at it I see that this is no register polling loop but an iteration loop. Could you add a explanation to the commit log? Also, like you other patches this one lacks a SoB. Please commit with git commit -s. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 7:11 ` Sascha Hauer @ 2016-03-04 10:42 ` Aleksey Kuleshov 2016-03-04 11:59 ` Antony Pavlov 0 siblings, 1 reply; 13+ messages in thread From: Aleksey Kuleshov @ 2016-03-04 10:42 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox Don't get me wrong, but what this (git commit -s) will give you? What is the purpose of this? 04.03.2016, 10:11, "Sascha Hauer" <s.hauer@pengutronix.de>: > Also, like you other patches this one lacks a SoB. Please commit with > git commit -s. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 10:42 ` Aleksey Kuleshov @ 2016-03-04 11:59 ` Antony Pavlov 2016-03-04 12:04 ` Aleksey Kuleshov 0 siblings, 1 reply; 13+ messages in thread From: Antony Pavlov @ 2016-03-04 11:59 UTC (permalink / raw) To: Aleksey Kuleshov; +Cc: barebox On Fri, 04 Mar 2016 13:42:14 +0300 Aleksey Kuleshov <rndfax@yandex.ru> wrote: > Don't get me wrong, but what this (git commit -s) will give you? > What is the purpose of this? You can find the answer at https://www.kernel.org/doc/Documentation/SubmittingPatches Please see chapter 11 (Sign your work). > 04.03.2016, 10:11, "Sascha Hauer" <s.hauer@pengutronix.de>: > > > Also, like you other patches this one lacks a SoB. Please commit with > > git commit -s. -- -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 11:59 ` Antony Pavlov @ 2016-03-04 12:04 ` Aleksey Kuleshov 2016-03-04 13:59 ` Antony Pavlov 2016-03-04 17:58 ` Andrey Smirnov 0 siblings, 2 replies; 13+ messages in thread From: Aleksey Kuleshov @ 2016-03-04 12:04 UTC (permalink / raw) To: Antony Pavlov; +Cc: barebox [quote] To improve tracking of who did what, especially with patches that can percolate to their final resting place in the kernel through several layers of maintainers, we've introduced a "sign-off" procedure on patches that are being emailed around. [/quote] So Linux kernel had some problems due to their huge developers/maintainers list and they solved them by using "sign-off" procedure. Do Barebox have that burden of "patches that can percolate to their final resting place in the kernel through several layers of maintainers"? Also in chapter 11 there are rules which are pure bureaucratic. Bureaucracy is a thing of a large projects. Is Barebox such as big as Linux that it must have these rules too? Solving inexisting problems doesn't make life easier but complicates it. So, the question "what this (git commit -s) will give you?" is still open. 04.03.2016, 14:33, "Antony Pavlov" <antonynpavlov@gmail.com>: > On Fri, 04 Mar 2016 13:42:14 +0300 > Aleksey Kuleshov <rndfax@yandex.ru> wrote: > >> Don't get me wrong, but what this (git commit -s) will give you? >> What is the purpose of this? > > You can find the answer at https://www.kernel.org/doc/Documentation/SubmittingPatches > Please see chapter 11 (Sign your work). > >> 04.03.2016, 10:11, "Sascha Hauer" <s.hauer@pengutronix.de>: >> >> > Also, like you other patches this one lacks a SoB. Please commit with >> > git commit -s. > > -- > -- > Best regards, > Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 12:04 ` Aleksey Kuleshov @ 2016-03-04 13:59 ` Antony Pavlov 2016-03-04 15:03 ` Aleksey Kuleshov 2016-03-04 17:58 ` Andrey Smirnov 1 sibling, 1 reply; 13+ messages in thread From: Antony Pavlov @ 2016-03-04 13:59 UTC (permalink / raw) To: Aleksey Kuleshov; +Cc: barebox On Fri, 04 Mar 2016 15:04:49 +0300 Aleksey Kuleshov <rndfax@yandex.ru> wrote: > [quote] > To improve tracking of who did what, especially with patches that can > percolate to their final resting place in the kernel through several > layers of maintainers, we've introduced a "sign-off" procedure on > patches that are being emailed around. > [/quote] > > So Linux kernel had some problems due to their huge developers/maintainers list > and they solved them by using "sign-off" procedure. > Do Barebox have that burden of "patches that can > percolate to their final resting place in the kernel through several > layers of maintainers"? > > Also in chapter 11 there are rules which are pure bureaucratic. > Bureaucracy is a thing of a large projects. > Is Barebox such as big as Linux that it must have these rules too? > > Solving inexisting problems doesn't make life easier but complicates it. > > So, the question "what this (git commit -s) will give you?" is still open. There are some full-system-image-generation frameworks: OpenWrt, buildroot etc. These frameworks make several independant pieces of software (compiler, linux kernel, C lib implementation, busybox etc) work together to combine solid system. Often these frameworks use mainline versions of software components with additional (non-mainline) patches. E.g. here is patch for barebox from buildroot: https://github.com/maximeh/buildroot/tree/master/board/calao/qil-a9260/patches/barebox It is reasonable to have as much author(s) information as possible. So your Sob will be very usable if somebody who works with the patch. Here is a poor example: patch without any comments at all, it's very difficult to trace origins of this patch: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/patches-4.4/200-MIPS-ath79-fix-ar933x-wmac-reset.patch > > 04.03.2016, 14:33, "Antony Pavlov" <antonynpavlov@gmail.com>: > > On Fri, 04 Mar 2016 13:42:14 +0300 > > Aleksey Kuleshov <rndfax@yandex.ru> wrote: > > > >> Don't get me wrong, but what this (git commit -s) will give you? > >> What is the purpose of this? > > > > You can find the answer at https://www.kernel.org/doc/Documentation/SubmittingPatches > > Please see chapter 11 (Sign your work). > > > >> 04.03.2016, 10:11, "Sascha Hauer" <s.hauer@pengutronix.de>: > >> > >> > Also, like you other patches this one lacks a SoB. Please commit with > >> > git commit -s. > > > > -- > > -- > > Best regards, > > Antony Pavlov -- -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 13:59 ` Antony Pavlov @ 2016-03-04 15:03 ` Aleksey Kuleshov 0 siblings, 0 replies; 13+ messages in thread From: Aleksey Kuleshov @ 2016-03-04 15:03 UTC (permalink / raw) To: Antony Pavlov; +Cc: barebox > https://github.com/maximeh/buildroot/tree/master/board/calao/qil-a9260/patches/barebox > > It is reasonable to have as much author(s) information as possible. So your Sob will be > very usable if somebody who works with the patch. This patch has "From:" field and exactly the same "Signed-off-by:" field. So no new additional information Sob gives you here. The Sob indeed will give you simplification when you want to squash many-many commits by many-many authors and for god's sake you don't want to reclaim ownership of each commit! But again, does Barebox facing such cases? Does it really necessary to follow all linux-related work process rules? Just look at this: Signed-off-by: James Hogan <james.hogan@imgtec.com> Fixes: e9de688dac65 ("irqchip: mips-gic: Support local interrupts") Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Qais Yousef <qais.yousef@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Reviewed-by: Andrew Bresticker <abrestic@chromium.org> Patchwork: https://patchwork.linux-mips.org/patch/9081/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> That's something! Because many people are invlolved. Linux is a huge machine. Barebox is not Linux. And just for comparsion, this is from Barebox: -------------------------- commit a6f73ec52f5c794938aa14b1264375228890f12c Author: Ulrich Ölmann <u.oelmann@pengutronix.de> Date: Thu Feb 4 08:25:24 2016 +0100 docs: fix typos Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst b/Documentation/devicetree/bindings/barebox/barebox,state.rst index d1b0627..d507657 100644 --- a/Documentation/devicetree/bindings/barebox/barebox,state.rst +++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst @@ -43,7 +43,7 @@ Variable nodes These are subnodes of a state node each describing a single variable. The node name may end with ``@<ADDRESS>``, but the suffix is -sripped from the variable name. +stripped from the variable name. State variables have a type. Currenty supported types are: ``uint8``, ``uint32``, ``enum32``, ``mac`` address or ``string``. Variable length -------------------------- > Here is a poor example: patch without any comments at all, it's very difficult to trace origins > of this patch: > > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/patches-4.4/200-MIPS-ath79-fix-ar933x-wmac-reset.patch Indeed, plain patches lacks origins. 1) That's why everyone here uses "git send-email" so that "git am" will apply patch with proper "Author:" field. 2) In the case of openwrt patch, why do anyone needs the origins anyway? If this patch breaks something - fix with new one, if not - okay then. If you know that that patch was written by Some Person - what this will give you? _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 12:04 ` Aleksey Kuleshov 2016-03-04 13:59 ` Antony Pavlov @ 2016-03-04 17:58 ` Andrey Smirnov 2016-03-04 20:47 ` Aleksey Kuleshov 1 sibling, 1 reply; 13+ messages in thread From: Andrey Smirnov @ 2016-03-04 17:58 UTC (permalink / raw) To: Aleksey Kuleshov; +Cc: barebox On Fri, Mar 4, 2016 at 4:04 AM, Aleksey Kuleshov <rndfax@yandex.ru> wrote: > [quote] > To improve tracking of who did what, especially with patches that can > percolate to their final resting place in the kernel through several > layers of maintainers, we've introduced a "sign-off" procedure on > patches that are being emailed around. > [/quote] > > So Linux kernel had some problems due to their huge developers/maintainers list > and they solved them by using "sign-off" procedure. > Do Barebox have that burden of "patches that can > percolate to their final resting place in the kernel through several > layers of maintainers"? > > Also in chapter 11 there are rules which are pure bureaucratic. > Bureaucracy is a thing of a large projects. > Is Barebox such as big as Linux that it must have these rules too? > IANAL, but AFAIU those "rules which are pure bureaucratic" are a legal framework that originated in Linux kernel and was borrowed by many projects, Barebox among them. So to answer your question: it has nothing to do with the size of the project, copyright and associated laws in various shapes or forms applies to everyone. Can it be done in a better, less verbose, more convenient form by smaller projects? Maybe or maybe not, but I don't think the question can be answered without performing proper legal analysis(done by law professionals, of course) which is very costly, time consuming, etc. > Solving inexisting problems doesn't make life easier but complicates it. > That's very much a truism, so you won't find much opposition to that. The devil, as usual, is in the details of how you define what constitutes a non-existing problem. This may sound rude and I apologize for not coming up with a way of better delivery, but I, personally, think that even if we were to assume that the whole SOB mechanism is most egregious and ridiculous legal cargo-cult, necessity to type "git commit -s" as opposed "git commit -s" when you are commiting changes is a non-existing problem. Andrey _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 17:58 ` Andrey Smirnov @ 2016-03-04 20:47 ` Aleksey Kuleshov 2016-03-04 22:57 ` Andrey Smirnov 0 siblings, 1 reply; 13+ messages in thread From: Aleksey Kuleshov @ 2016-03-04 20:47 UTC (permalink / raw) To: Andrey Smirnov; +Cc: barebox 04.03.2016, 20:58, "Andrey Smirnov" <andrew.smirnov@gmail.com>: > On Fri, Mar 4, 2016 at 4:04 AM, Aleksey Kuleshov <rndfax@yandex.ru> wrote: >> [quote] >> To improve tracking of who did what, especially with patches that can >> percolate to their final resting place in the kernel through several >> layers of maintainers, we've introduced a "sign-off" procedure on >> patches that are being emailed around. >> [/quote] >> >> So Linux kernel had some problems due to their huge developers/maintainers list >> and they solved them by using "sign-off" procedure. >> Do Barebox have that burden of "patches that can >> percolate to their final resting place in the kernel through several >> layers of maintainers"? >> >> Also in chapter 11 there are rules which are pure bureaucratic. >> Bureaucracy is a thing of a large projects. >> Is Barebox such as big as Linux that it must have these rules too? > > IANAL, but AFAIU those "rules which are pure bureaucratic" are a legal > framework that originated in Linux kernel and was borrowed by many > projects, Barebox among them. So why Barebox borrowed them? Was it so necessary? Was it well thought decision? Linux is a huge project, it has its mechanisms to control this machine. Does Barebox really need this? Or it's just blindly following the rules made by Linux project? > So to answer your question: it has > nothing to do with the size of the project, copyright and associated > laws in various shapes or forms applies to everyone.Can it be done in > a better, less verbose, more convenient form by smaller projects? > Maybe or maybe not, but I don't think the question can be answered > without performing proper legal analysis(done by law professionals, of > course) which is very costly, time consuming, etc. Well, that's what I call trying to solve problems which do not exist. Do really small projects need to follow all such bureaucratic way rather than just growing up? For example, btw, FreeBSD, NetBSD, OpenBSD - these projects have no SOB. They have "author" field and that's enough for them. They are happily evolving every day. What if git history magically disappears? Only authors written in files will be fixed, but all authors of patches will disappear as well. So this SOB field is only valid while "git log" gives you something to read. >> Solving inexisting problems doesn't make life easier but complicates it. > > That's very much a truism, so you won't find much opposition to that. > The devil, as usual, is in the details of how you define what > constitutes a non-existing problem. This may sound rude and I > apologize for not coming up with a way of better delivery, but I, > personally, think that even if we were to assume that the whole SOB > mechanism is most egregious and ridiculous legal cargo-cult, > necessity to type "git commit -s" as opposed "git commit -s" when > you are commiting changes is a non-existing problem. Actually, I don't think, that SOB is cargo-cult. Linux has it because developers decided that this is necessary and they can make steel arguments why they need this like "this is huge project, tons of patches, we do squashing, we must be sure that every patch was given under conditions of open source ..." But that's for Linux - companies, billions of dollars... What about Barebox? _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 20:47 ` Aleksey Kuleshov @ 2016-03-04 22:57 ` Andrey Smirnov 2016-03-05 0:04 ` Aleksey Kuleshov 0 siblings, 1 reply; 13+ messages in thread From: Andrey Smirnov @ 2016-03-04 22:57 UTC (permalink / raw) To: Aleksey Kuleshov; +Cc: barebox On Fri, Mar 4, 2016 at 12:47 PM, Aleksey Kuleshov <rndfax@yandex.ru> wrote: > 04.03.2016, 20:58, "Andrey Smirnov" <andrew.smirnov@gmail.com>: >> On Fri, Mar 4, 2016 at 4:04 AM, Aleksey Kuleshov <rndfax@yandex.ru> wrote: >>> [quote] >>> To improve tracking of who did what, especially with patches that can >>> percolate to their final resting place in the kernel through several >>> layers of maintainers, we've introduced a "sign-off" procedure on >>> patches that are being emailed around. >>> [/quote] >>> >>> So Linux kernel had some problems due to their huge developers/maintainers list >>> and they solved them by using "sign-off" procedure. >>> Do Barebox have that burden of "patches that can >>> percolate to their final resting place in the kernel through several >>> layers of maintainers"? >>> >>> Also in chapter 11 there are rules which are pure bureaucratic. >>> Bureaucracy is a thing of a large projects. >>> Is Barebox such as big as Linux that it must have these rules too? >> >> IANAL, but AFAIU those "rules which are pure bureaucratic" are a legal >> framework that originated in Linux kernel and was borrowed by many >> projects, Barebox among them. > I wasn't the person making any of those decisions nor am I a legal professional, but I can venture a guess/speak out of my ass about this. > So why Barebox borrowed them? Because it was an established legal practice followed by a successful project with identical licensing whose code base has seen its day in court > Was it so necessary? Yes. > Was it well thought decision? No idea, as I already mentioned I wasn't present during this decision. > Does Barebox really need this? Yes. > Or it's just blindly following the rules made by Linux project? It's irrelevant if BB follows this practice blindly, or with extensive knowledge and understanding of all factors involved if the procedure involved is believed to be legally sound > >> So to answer your question: it has >> nothing to do with the size of the project, copyright and associated >> laws in various shapes or forms applies to everyone.Can it be done in >> a better, less verbose, more convenient form by smaller projects? >> Maybe or maybe not, but I don't think the question can be answered >> without performing proper legal analysis(done by law professionals, of >> course) which is very costly, time consuming, etc. > > Well, that's what I call trying to solve problems which do not exist. IMHO, you need to be a law professional to make such assessment. > Do really small projects need to follow all such bureaucratic way rather than > just growing up? Yes, project with identical licensing, regardless of their size, need to adhere to certain legal procedures in order to have a good case if they are ever in court. There are two ways to establish what those "certain legal procedures" are, the project either have to consult law professionals or copy an already established procedures. > For example, btw, FreeBSD, NetBSD, OpenBSD - these projects have no SOB. > They have "author" field and that's enough for them. > They are happily evolving every day. All three projects that you mentioned are distributed under terms of BSD license, there's very little(if any) license compliance enforcement that can be done for those types of contracts (BSD license), so this comparison is meaningless. > > What if git history magically disappears? Only authors written in files will be fixed, > but all authors of patches will disappear as well. So this SOB field is only > valid while "git log" gives you something to read. I don't understand the point you are trying to make. If a legal document magically disappears, well, it disappears. You would no longer be able to use it for its intended purposes. That is still not really an argument to not make it in the first place. > >>> Solving inexisting problems doesn't make life easier but complicates it. >> >> That's very much a truism, so you won't find much opposition to that. >> The devil, as usual, is in the details of how you define what >> constitutes a non-existing problem. This may sound rude and I >> apologize for not coming up with a way of better delivery, but I, >> personally, think that even if we were to assume that the whole SOB >> mechanism is most egregious and ridiculous legal cargo-cult, >> necessity to type "git commit -s" as opposed "git commit -s" when >> you are commiting changes is a non-existing problem. > > Actually, I don't think, that SOB is cargo-cult. I didn't phrase myself really well. Let me correct my mistake: I, personally, think that even if we were to assume that the whole SOB mechanism, _as_applied_to_Barebox_, is most egregious and ridiculous legal cargo-cult, necessity to type "git commit -s" as opposed "git commit" when you are commiting changes planned for upstream is a non-existing problem. > Linux has it because developers > decided that this is necessary and they can make steel arguments why they > need this like "this is huge project, tons of patches, we do squashing, > we must be sure that every patch was given under conditions of open source ..." > But that's for Linux - companies, billions of dollars... What about Barebox? Same license, same rules. Aleksey, I am not really interested in continuing this discussion or trying to convince you to add SOB to your patch, so if any of the above explanations are insufficient for you, I am afraid we are going to have to agree to disagree on this subject. Andrey _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-04 22:57 ` Andrey Smirnov @ 2016-03-05 0:04 ` Aleksey Kuleshov 2016-03-05 9:15 ` Antony Pavlov 0 siblings, 1 reply; 13+ messages in thread From: Aleksey Kuleshov @ 2016-03-05 0:04 UTC (permalink / raw) To: Andrey Smirnov; +Cc: barebox >> Was it so necessary? > > Yes. >> Does Barebox really need this? > > Yes. Oh, these are exhaustive answers, thank you :) >> Or it's just blindly following the rules made by Linux project? > > It's irrelevant if BB follows this practice blindly, or with extensive > knowledge and understanding of all factors involved if the procedure > involved is believed to be legally sound > >> Do really small projects need to follow all such bureaucratic way rather than >> just growing up? > > Yes, project with identical licensing, regardless of their size, need > to adhere to certain legal procedures in order to have a good case if > they are ever in court. So this means that every GPL'ed hello-world.c project should follow Linux's rules "to have a good case if they are ever in court"? And If think in this way then Barebox should create a Barebox Foundation, hire a lawyer and wait until someone will sue them. But this is ridiculous, because Barebox don't need this! That's why there is no Barebox Foundation with lawyer. >> What if git history magically disappears? Only authors written in files will be fixed, >> but all authors of patches will disappear as well. So this SOB field is only >> valid while "git log" gives you something to read. > > I don't understand the point you are trying to make. SOB is just a matter of "git log". >> But that's for Linux - companies, billions of dollars... What about Barebox? > Same license, same rules. (see about GPL'ed hello-world.c) > Aleksey, I am not really interested in continuing this discussion or > trying to convince you to add SOB to your patch, so if any of the > above explanations are insufficient for you, I am afraid we are going > to have to agree to disagree on this subject. I asked a simple question - still no use case of SOB in Barebox. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-05 0:04 ` Aleksey Kuleshov @ 2016-03-05 9:15 ` Antony Pavlov 2016-03-05 9:27 ` Aleksey Kuleshov 0 siblings, 1 reply; 13+ messages in thread From: Antony Pavlov @ 2016-03-05 9:15 UTC (permalink / raw) To: Aleksey Kuleshov; +Cc: Andrey Smirnov, barebox On Sat, 05 Mar 2016 03:04:06 +0300 Aleksey Kuleshov <rndfax@yandex.ru> wrote: > >> Was it so necessary? > > > > Yes. > >> Does Barebox really need this? > > > > Yes. > > Oh, these are exhaustive answers, thank you :) > > >> Or it's just blindly following the rules made by Linux project? > > > > It's irrelevant if BB follows this practice blindly, or with extensive > > knowledge and understanding of all factors involved if the procedure > > involved is believed to be legally sound > > > >> Do really small projects need to follow all such bureaucratic way rather than > >> just growing up? > > > > Yes, project with identical licensing, regardless of their size, need > > to adhere to certain legal procedures in order to have a good case if > > they are ever in court. > > So this means that every GPL'ed hello-world.c project should follow > Linux's rules "to have a good case if they are ever in court"? > > And If think in this way then Barebox should create a Barebox Foundation, > hire a lawyer and wait until someone will sue them. But this is ridiculous, because > Barebox don't need this! That's why there is no Barebox Foundation with lawyer. > > >> What if git history magically disappears? Only authors written in files will be fixed, > >> but all authors of patches will disappear as well. So this SOB field is only > >> valid while "git log" gives you something to read. > > > > I don't understand the point you are trying to make. > > SOB is just a matter of "git log". > > >> But that's for Linux - companies, billions of dollars... What about Barebox? > > Same license, same rules. > > (see about GPL'ed hello-world.c) > > > Aleksey, I am not really interested in continuing this discussion or > > trying to convince you to add SOB to your patch, so if any of the > > above explanations are insufficient for you, I am afraid we are going > > to have to agree to disagree on this subject. > > I asked a simple question - still no use case of SOB in Barebox. Of course there is a use case for SOB in Barebox! Git has the 'Author' placeholder only for one person. If more that one person works on a patch then we can't put all their names into the 'Author' field. However we can use SOB to indicated co-authoring. -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ehci-hcd: remove useless timeout 2016-03-05 9:15 ` Antony Pavlov @ 2016-03-05 9:27 ` Aleksey Kuleshov 0 siblings, 0 replies; 13+ messages in thread From: Aleksey Kuleshov @ 2016-03-05 9:27 UTC (permalink / raw) To: Antony Pavlov; +Cc: Andrey Smirnov, barebox >> I asked a simple question - still no use case of SOB in Barebox. > > Of course there is a use case for SOB in Barebox! > > Git has the 'Author' placeholder only for one person. > If more that one person works on a patch > then we can't put all their names into the 'Author' field. > However we can use SOB to indicated co-authoring. /thread _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-03-05 9:28 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-03 12:48 [PATCH] ehci-hcd: remove useless timeout Aleksey Kuleshov 2016-03-04 7:11 ` Sascha Hauer 2016-03-04 10:42 ` Aleksey Kuleshov 2016-03-04 11:59 ` Antony Pavlov 2016-03-04 12:04 ` Aleksey Kuleshov 2016-03-04 13:59 ` Antony Pavlov 2016-03-04 15:03 ` Aleksey Kuleshov 2016-03-04 17:58 ` Andrey Smirnov 2016-03-04 20:47 ` Aleksey Kuleshov 2016-03-04 22:57 ` Andrey Smirnov 2016-03-05 0:04 ` Aleksey Kuleshov 2016-03-05 9:15 ` Antony Pavlov 2016-03-05 9:27 ` Aleksey Kuleshov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox