[PATCH] ehci-hcd: remove useless timeout

[PATCH] ehci-hcd: remove useless timeout

[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

Re: [PATCH] ehci-hcd: remove useless timeout

[Sascha Hauer]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Aleksey Kuleshov]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Antony Pavlov]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Aleksey Kuleshov]

[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

Re: [PATCH] ehci-hcd: remove useless timeout

[Antony Pavlov]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Aleksey Kuleshov]

>     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

Re: [PATCH] ehci-hcd: remove useless timeout

[Andrey Smirnov]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Aleksey Kuleshov]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Andrey Smirnov]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Aleksey Kuleshov]

>>  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

Re: [PATCH] ehci-hcd: remove useless timeout

[Antony Pavlov]

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

Re: [PATCH] ehci-hcd: remove useless timeout

[Aleksey Kuleshov]

>>  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