DRM Maintainers Are Running Out Of Time To Ship New Features For Linux 4.12

[phoronix]

Phoronix: DRM Maintainers Are Running Out Of Time To Ship New Features For Linux 4.12

After Linus Torvalds was upset about the DRM pull request for Linux 4.11, the deadlines of new feature changes for the Direct Rendering Manager (DRM) code targeting Linux 4.12 is being strictly enforced...

http://www.phoronix.com/scan.php?page=news_item&px=DRM-Linux-4.12-Deadline

[NotMine999]

I guess I am not that surprised by this news. Programmers, at least the ones that I know, are notorious for using every minute they can get, and then every minute that they can "beg, borrow, or steal" when it comes to getting their work delivered on schedule. When I programmed (years ago) I was much the same way.

Maybe it's a desire for perfection; "it's gotta be just right or else I don't want it out there" attitude. Maybe it's a desire to have every promised feature working and "relatively bug free" in their deliverables. Maybe it's a case of "over promise and hope to deliver it all while not fully understanding the ramifications of the work involved". Maybe it's unforeseen problems. Maybe it's a case of too much, in terms of features and/or functionality, being demanded in too short a period of time, or even the infamous "scope creep".

Honestly I would rather programmers delay their deliverables compared to delivering "untested or adequately tested code" (what seems to have angered Linus) or "obviously buggy code" (like basic functionality not working right or constant crashing). Yeah I know it's a hit to one's pride to say, "Hey I won't have it all for you by the due date." But I think it's worse to rush the testing and to not properly structure the work into "incremental blocks" (if that's possible) that can be presented over a period of time just so it can be said, "Yeah we met your deadline."

[pipe13]

Well if it's not ready, it's not ready. No use trying to convince ourselves otherwise. Vega 10's High Bandwidth Cache is seriously intriguing, and superficially sounds like a good match for that Heterogeneous Memory Management Michael wrote about earlier. But integration of HMM into AMDGPU won't happen overnight, and if it isn't there now, it likely won't be for 4.12.

[pipe13]

I do take part in "the development". But being SandyBridge-Maxwell based, not part of *this* development.

[L_A_G]

This was unfortunately necessary after the 4.10 fiasco where David pushed code that had only been pushed to him the day before and hadn't gone trough any testing whatsoever on his part. I'd go as far as to say that the chewing out that he got from Linus was well deserved. David obviously knows that he lost Linus' trust with that debacle, but I'd say it's pretty clear that he's now being a bit overzealous in his attempt to regain Linus' trust. If this leads to enough complaints I suppose this could lead to Linus putting the word out that he's looking for someone to replace David.

You obviously need to have a freeze on the submission of new code at some point, but doing that before Linus pushes the previous version out the door is a bit too early if you ask me.

[pipe13]

It's a matter of opinion of course. But I doubt anyone is looking for a fast replacement for David Arlie.

[milkylainen]

It has nothing to do with David. It is the general state of anything graphics related.
So I am not surprised. GPUs and any related code has been the single biggest piece of FECK-type code to ever taint the kernel.

[bug77]

I guess I am not that surprised by this news. Programmers, at least the ones that I know, are notorious for using every minute they can get, and then every minute that they can "beg, borrow, or steal" when it comes to getting their work delivered on schedule. When I programmed (years ago) I was much the same way.

Maybe it's a desire for perfection; "it's gotta be just right or else I don't want it out there" attitude. Maybe it's a desire to have every promised feature working and "relatively bug free" in their deliverables. Maybe it's a case of "over promise and hope to deliver it all while not fully understanding the ramifications of the work involved". Maybe it's unforeseen problems. Maybe it's a case of too much, in terms of features and/or functionality, being demanded in too short a period of time, or even the infamous "scope creep".

Honestly I would rather programmers delay their deliverables compared to delivering "untested or adequately tested code" (what seems to have angered Linus) or "obviously buggy code" (like basic functionality not working right or constant crashing). Yeah I know it's a hit to one's pride to say, "Hey I won't have it all for you by the due date." But I think it's worse to rush the testing and to not properly structure the work into "incremental blocks" (if that's possible) that can be presented over a period of time just so it can be said, "Yeah we met your deadline."

In my experience, it's recognising that once pushed/delivered, the chance is slim you'll ever get budget for ironing out kinks or refactoring. That and Murphy's law that says 80% of the job get done in the last 20% of time.

[nanonyme]

Come on, rc6 is being fair. I remember many kernels having gone out at around rc8 so that's in fact really late stage

[RealNC]

Meanwhile, binary blob drivers can add new features whenever the heck they please.

Isn't there something fundamentally wrong here?