On Tuesday 12 of February 2013 08:39:01 Łukasz Maśko wrote: > Dnia środa, 30 stycznia 2013 12:21:05 Arkadiusz Miśkiewicz pisze: > > On Wednesday 30 of January 2013, Tomasz Pala wrote: > > > 2. aby choć odrobinę zmniejszyć pewność olania, musisz sam namierzyć > > > psujący commit - git bisect, > > > > To ważne :-) > > > > > 3. zamiast się frustrować, trzymasz swoje łaty na kernela u siebie (ja > > > utrzymywałem przez długi czas do VGA, digital beep na laptopie, ciągle > > > mam jakiegoś quirka do ACPI, MTD oraz VLAN stripping). > > > > Osobiście wolę jednak pchać do upstreamu - potem spokój, a nie ciągłe dbanie > > o łatki (chyba, że to takie 1 linijkowe). > > > > > 4. jedyna pewna droga, aby się przebić, to zostać klientem jakiegoś > > > dużego gracza i zgłosić problem komercyjną drogą. > > > > Ciekaw jestem jak to działa jak masz np. serwery bez certyfikatu dużego > > gracza, o desktopach, laptopach nie wspominając - nie odpiszą, "sorry, > > unsupported"? > > Udało się wyizolować problem, dzięki jednemu z hakerów kernela mam patch, > dzieki któ©emu wraca "stara" funkcjonalność (czyli kilka niegroźnych > komunikatów w logach, ale czytnik działa).
duzy to patch? jesli on naprawia regresje w kontekscie takim, ze sprzet znow dziala, to ja bym to probowal popchnac do stable zeby najblizszy 3.7.y/3.8.y bylyb lepsze niz wydanie x.y.0. > I teraz pytanie. Czy wprowadzić to > do naszego kernela jako łatkę, czy też pomęczyć się samemu, bo odpowiednie > kody mają być włączone już (!) do jądra 3.9? 3.9 to jeszcze kawalek czasu... _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
