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

[Aleksey Kuleshov <rndfax@yandex.ru>]

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