[ combuster @ 19.11.2010. 21:30 ] @
http://www.phoronix.com/scan.php?page=news_item&px=ODgwMQ

Citat:

F*%^ me, why does drm always have to be so messy?

You guys pull each others trees, and then rebase them. Yes, git is smart enough that it will merge it all fine, but dammit, now that multi-hundred-line Radeon commit exists twice in the tree. Do this:

git show --stat 16790569eddf fba4312e223f
git show --stat 21e2eae4daae a41c73e04673

and cry.

And yeah, it's ugly. And if that patch introduces a regression (which is entirely possible, it's not like it's small and trivial and obviously correct) it will just make bisection harder, and add confusion. And it's totally pointless. It only adds pain. And it makes the history harder to read.

Why did the Intel drm tree merge a patch that had _nothing_ what-so-ever to do with Intel DRM? WHY?

And why did the drm tree rebase a tree that had obviously been public and pulled from? WHY? Why did you make it public before it was ready? And/or why was it so ugly that it needed to rebase it? Why do these things keep happening?

What's wrong with the whole drm crowd? Even if it isn't rebasing, why is drivers/gpu/drm always so very visible in the later -rc trees?

I'm asking "why", but what I really want you guys to do is to ask _yourself_ why. And ask "Why is that? What am I doing wrong that this keeps happening?"

Really. Spend some time pondering. What the hell just happened, and why did it happen, and how can you guys stop doing it?

Chris: stop pulling in random crap in your tree. Do _your_ development, in your tree. Nothing else.

And Dave, I have no idea why those two commits were rebased. They seem identical in the tree that Chris had pulled. They have the same base commit. What was the point?

Linus


Ma koliko ja gotivio likove iz drm ekipe (cimam ih po potrebi :D), Linus ima poentu ovde oko nekih stvari. Iako Michael sa Phoronixa ne voli ove ispade LT-a, _cinjenica_ je da je drm grana (izuzev staging-a ali on je i namenjen za to) onako najhaoticnija od svih. Vrlo cesto se ubacuje nov kod posle zatvaranja merge-ovanja, API se lomi u zadnjim momentima, pa se to pegla tokom celog stabilnog ciklusa jedne verzije kao da je rc u pitanju.

Dakle 2.6.37 je u rc2 fazi i pazite sad ovaj fazon :)

http://lists.freedesktop.org/a...evel/2010-November/005596.html

Citat:


Dave:

Just a fixes tree for -rc3 if possible, it did get rebased recently as I
had to get the nouveau pull cleaned, but I'd been running the non-nouveau
bits for a few days, there is also one late regression fix from Alex and
some fixups after Jean pushed an i2c change that broke the kms drivers.

Chris:

Hi Dave and Linus,

with travel I was a bit late in getting this pull request sent. It
contains a fix for Linus' machine, an i2c initialisation failure and a fix
from Keith to stop VGA flashing during polling on recent hardware. As well
as a patch that should hopefully prevent all of our indefinite GPU waits
on mode setting.

Note it also contains a couple of fluff fallout patches from the recent
drm-fixes rebase. (I thought it would be wise to include any core drm
changes in our testing before sending the request...)

I naravno sledi onaj Linusov odgovor...

Dave

please just reject Chris's pull, I've asked he don't send you pulls
directly, and he seems to have missed the memo in this case, if he'd
sent this to me I'd have pushed back.


Hehehe funny bunny :D Utnuo bi on i taj patch uz njegove, ne bi odbio nista :)

Kakav bre unity, kakav wayland, ono sto ljudi ne kontaju je ogroman problem u srzi razvoja GPU/IGP drajvera.

1. Hardware inzinjeri, pocev od njih, prave s****, ili im dokumentacija nije dobra, ili ne ispostuju pri samoj proizvodnji ono sto bi trebalo da funkcionise na odredjeni nacin, pa se onda devovi cesu zasto odredjeno parce koda ne radi onako kako bi trebalo ("ALI POSLAO SAM 0xFFFFFF u taj registar i nece majku mu")

2. Dinamika razvoja na ovom polju ne dozvoljava grupi devova da to sve isprate, ATI donekle pruza podrsku opensource dev-ovima dok nVIDIA i ne obraca paznju uopste. Noviji hardware ili ne radi uopste ili radi traljavo. Intel je tu za sada najjaci i popravljaju se (ako zanemarimo totalno sve pre Clarkdale/Arrandale procesora)

3. Svako nesto razvija na svoju ruku, ispravlja, vrlo cesto vidim da postoji slaba komunikacija na relaciji dev-ova unutar samog razvojnog tima a kamoli izmedju dev-ova ciji se projekti medjusobno dopunjuju. Onda se te razvojne grane merge-uju, i tako spojene na brzinu utrcavaju u rc3 :) Ups, izvin'te vi mene ali ulete u rc4 patch koji je slomio API za nouveau a DDX drajveri jos nisu prilagodjeni pa ljudi koji krcaju i testiraju kernel na Fedori recimo dobiju init3 umesto X-a :)

4. Ideje se stvore na izgled niotkuda i isto tako brzo se napustaju. Gde je vizija od samog starta da se uradi nesto kako valja (sto je u Linux slucaju stvarno jbno jer se okruzenje menja iz verzije u verziju)

5. Dobra dokumentacija je osnov svega. Znam da je deo te dokumentacije poslovna tajna, da to ne moze svako da dobije, neki delovi koda (ili svi u slucaju nouveau-a) se dobijaju reverznim inzinjeringom, ali bez toga NIKADA opensource drajveri nece biti dovoljno dobri sem Intelovih koji imaju sanse.

Skoro sam prijavljivao neki bug u sred rc faze vezan za i915 drajver i rece mi Chris da je bolje da to sto pre ispravimo inace ce linus ponovo da komentarise na ovu foru drm ekipu. I ja jos rekoh, ma nece, dosadno je kada sve radi kako treba, malko da ubijemo dosadu... Da je LT ono procitao verovatno bi me oterao u tri lepe... :)

E sad, nisu stvari toliko jednostavne ni kako Linus misli da bi trebale da budu. Ne moze covek da razvija u svojoj grani nesto sto se bazira ili je medjusobno zavisno od koda u nekoj drugoj grani, e sad dal je to random crap ili nije nisam upucen.

Ovo je moje misljenje kada obratim paznju na internalije. Inace krajnji efekat i nije toliko crn, to uglavnom sve radi bez nekih povecih problema...

Cela ova diskusija mi je krenula od cinjenice da se prica o Wayland-u kao novom revolucionarnom lightweight display serveru, prica o nekoj sminci poput gnome-shell-a i unity-ja a ono na cemu sve to pociva i od cega sve to zavisi - vidi prc, frka :)