[OT] Podpowiedzcie proszę, gdzie należy wysyłać takie zgłoszenia błędów

[Paweł Sikora]

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