A legrégebbi lezáratlan hibajegyem a hibakezelő, hibakövető rendszerünkben ...

Bug

pár perces, pár órás.
5% (19 szavazat)
pár napos.
7% (28 szavazat)
pár hetes.
9% (35 szavazat)
pár hónapos.
22% (88 szavazat)
pár éves.
17% (68 szavazat)
több mint 5 éves.
5% (20 szavazat)
több mint 10 éves.
3% (13 szavazat)
A micsoda?
11% (44 szavazat)
A miben?
14% (55 szavazat)
Egyéb, leírom.
8% (32 szavazat)
Összes szavazat: 402

( ulysses v | 2014. 02. 18., k – 10:45 )

2013. január 22, ha a hozzám rendelt hibajegyet nézem, egyébként 2012. április 4. a projekten belül.

( kariThe1 | 2014. 02. 18., k – 11:07 )

Jelenleg nincs a csoporthoz hozzárendelt hibajegy a hibajegykezelőben ill. nincs lezáratlan hibajegyünk.
Szeretem, ha minden hozzánk allokált hibát a lehető leghamarabb megoldunk és nincs hibajegy a csoportunknál.
Miért nincs olyan opció, hogy:
- Nincsen lezáratlan hibajegyem ill. hibajegyünk.
?

( Lacyc3 v | 2014. 02. 18., k – 12:27 )

Próbálkoztam hibakövető rendszer bevezetésén, de valahogy mindenkinek sokkal kényelmesebb telefonálgatni, e-mail-ezgetni a screenshot-okat.. etc mint hogy egy normális felületen keresztül jelenteni a hibát. Magyarul.

Azért tartok egy saját "hibakövető" táblázatot, ahova írom hogy mikor, hol, mit, kinek, miért, ~meddig csináltam, ha többször is előfordul egy gond akkor permanens megoldást is keresek rá, amit távolról feltolva a gépekre eliminálja (vagy triggereli.. :D) a hibát.

Egyszerűen fölösleges volt a webes felület, mindenki emailezett, emailt akart. Az email bodyban elvégezhető az a néhány status update amit mi használunk, ezt pedig épp nem kezelte a szoftver.

Másik, hogy a régi ticketing subjectbe akarta írni a ticket számot, ha nem volt ott, új ticketet regisztrált: a júzerek szoktak úgy feladatot adni, hogy egy hosszú szál vége felé Cc-re teszik a ticketing email címet, hogy akkor ami itt tárgyaltuk, az a feladat. Ha aztán jöttek a szálba újabb emailek, akkor mindhez nyílt egy ticket. Nem találtam úgy, hogy ez PEBKAC lenne, inkább alkalmazkodjon a szoftver.

Persze "webes" szoftverrel is megoldható mindez, de a megfelelő keresgélése helyett megírtam 60 sor procmailrc-ben, a közös megegyezésen alapuló status update-eket pedig kezeli mindenki magának különböző szűrőkkel ahogy akarja. Van egy monitoring mailbox is, amin felkonfiguráltam a status update szűrőket, így erről IMAP-en kikérhetőek a különböző státuszokban lévő ticketek (emailek), ennyi az API.

Ezzel meg is lett valósítva a ticketing szoftver kihasznált funkcionalitása és 100%-osan belesimul a levelezésbe, ami jó, levelezni szeretünk.

( vl v | 2014. 02. 18., k – 20:06 )

Alternatív értelmezése a kérdésnek: a legrégebbi, általam nyitott (és még nyitva levő) hibajegy 2003. áprilisában készült, és nem mellesleg a Netscape 4.0 megjelenése óta (engem már legalább 98 óta irritál) benne van a Netscape/Mozilla/Firefox gyönyörűségben. A státusz mezőkben a "NEW" és a "DUPEME" stringek szerepelnek, bármit is jelentsenek ezek. :D

Az a "hiba", hogy nincs page history benne, csak URL history. Ha nyomsz egy back gombot, akkor nem azt a tartalmat kapod vissza, amit korábban láttál ott, hanem azt az URL-t, ami korábban aktív volt - pont, mintha újra begépelnéd. Ebből következik egyébként 2-3 másik, hasonlóan irritáló hiba (pl. Show page source nem ANNAK a tartalomnak a forrását mutatja, amit látsz, hanem ugyanannak az URL-nek az aktuális tartalmát; a Print nem AZT nyomtatja ki, amit látsz, hanem annak az URL-nek az aktuális tartalmát).
Persze a kedvenc az, hogy emiatt ha egy posztolt formra visszamégy, akkor jön az obligát kérdés: elposztoljuk mégegyszer (és szopsz, fiam), vagy inkább mégse akarsz visszamenni.

Áhá!
Mondjuk ez inkább feature requestnek tűnik, nem bugnak. Ettől még persze elhiszem hogy Neked nagyon zavaró, bennem fel se ötlött hogy lehetne másképp is, megszoktam.

>Ebből következik egyébként 2-3 másik, hasonlóan irritáló hiba (pl. Show page source nem ANNAK a tartalomnak a forrását mutatja, amit látsz, hanem ugyanannak az URL-nek az aktuális tartalmát; a Print nem AZT nyomtatja ki, amit látsz, hanem annak az URL-nek az aktuális tartalmát).

Ezzel viszont nem értek egyet, mármint hogy az előzőből egyértelműen következik. Ezek ketten szerintem is durva hibák, amiket külön kéne bejelenteni és fixálni. Szóval én a helyedben ezt tenném, már legalábbis a bejelentés részig.

Bug az, ha
- az idevágó (kb. a Netscape 4.0-val egyidőben publikált) RFC szerint ez lenne a helyes működés,
- a Netscape 3.0 még tudta (regresszió),
- a többi browser is tudja ezt alapból.

bennem fel se ötlött hogy lehetne másképp is, megszoktam.

Nyilván ezen nőttél fel, nem használtál más browsereket, stb. Én már rég neteztem, amikor megjelent ez az okosság.

Az "alternatív manifesztációkat" nem tudod úgy megfixálni, hogy egyúttal ne írd meg a page history kódjának 97%-át. Ergó ez egy és ugyanaz a koncepcionális hiányosság.

Az RFC -t nem olvastam, ha aszerint ez lenne a helyes működés, akkor tényleg hajlok arra hogy bugnak nevezzem, tudnál linket adni?
Mondjuk ehhez az kellene hogy visszamenőlegesen az összes history item (dom-ja) el legyen mentve, plusz a hozzátartozó resourcek, ez elég overkill, azért lepődnék meg ha így működne, illetve ez lenne a helyes viselkdés, ahogy te írod.
Ezzel szemben az épp aktuális oldal dom -ja amúgyis a memóriában van, a forrása talán, vagy ha nem, hát egyszerű (nem akkora overkill) megoldani, hogy legyen.
Használtam Netscape 3.0 -t, valószínűleg 1.0-t is. Utóbbi években csak ritkán használok netscape leszármazottat, tehát főleg nem azt használok. Ez a history dolog általános viselkedés mostani böngészőknél, elhiszem hogy 3.0-ban nem így volt, már nem emlékszem. A printet és a sourcet viszont kipróbáltam az általam rendszeresen használt böngészőben (Safari 7.0.1) jól működik, nem fetcheli újra a tartalmat.

Hát alapból igen, csak épp a cache tartalmából nem mindig regenerálható az "eredeti" dom, vagyis ma már jellemzően inkbb nem, mint igen. Pl. javascript töltötte be a tartalom egy részét, akkor régen, most meg már más tartalmat töltene be. Tehát akkor a domot külön el kéne cachelni. Persze ez sem lehetetlen vállalkozás, kérdés, kinek ér meg ennyit ez a feature hogy dolgozzon vele.

( Husky v | 2014. 02. 19., sze – 02:48 )

Láttam már rendszert ahol a legrégebbi hibajegyet 1970 január elsején délután két órakor nyitották.
A rendszeróra hibáját jelentette be. Meghagyták emlékbe.

( bri | 2014. 02. 20., cs – 19:07 )

amit én vettem fel, ami hozzám van beosztva, vagy ami az én projektemen belül van?

alias killall='echo "Wenn ist das Nunstück git und Slotermeyer? Ja. Beiherhund das Oder die Flipperwaldt gersput." | espeak -vde' #That's not funny.

( GerzSonka | 2014. 02. 20., cs – 21:10 )

Most zártam le egy közel két és fél éves belső ticketet. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

( Aadaam v | 2014. 02. 22., szo – 19:53 )

Azért nem teljesen mindegy, fejlesztésről vagy infrastruktúráról beszélünk.

A "lehalt egy szerver" és a "van egy bug amit még nem sikerült senkinek reprodukálnia a bejelentőn kívül" közt vannak különbségek.