Le meilleurs bug tracker qui soit, c'est le fichier texte d'un certain format sur le dépôt subversoin/git/whatever, et grep pour faire une recherche.
+-------+--------+----------+----------+
| Bug no| Status | Category | Severity | Comments
+-------+--------+----------+----------+
| 00012 | Open | Cache | 4 | When there is a *file* /A, if an other peer tries to create /A/B (it considers that /A is a directory),
| | | | | a NoSuchFileOrDir exception is raised and there is a desynch.
| 00011 | Open | Cache | 5 | There is an undefined behavior which can cause a crash. Here is an example of backtrace:
| | | | | #0 0xffffe410 in __kernel_vsyscall ()
| | | | | #1 0xb7cf0701 in raise () from /lib/libc.so.6
| | | | | #2 0xb7cf1e38 in abort () from /lib/libc.so.6
| | | | | #3 0xb7fa9cbd in unwind_cleanup () from /lib/libpthread.so.0
| | | | | #4 0xb7df4abd in _Unwind_DeleteException () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1
| | | | | #5 0xb7f6f288 in __cxa_end_catch () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6
| | | | | #6 0x080cb7a0 in pf_read (path=0x856e5e0 "/Speedy's Coming [Live].mp3",
| | | | | buf=0x816d760 "\bÕÞ·\bÕÞ·v031円TALB", size=32768, offset=16384, fi=0xb7b352ec)
| | | | | at /home/vamps/peerfuse/common/fuse/read.cpp:47
| | | | | #7 0xb7eaabf2 in fuse_fs_read () from /usr/lib/libfuse.so.2
| 00010 | Open | | 1 | When the crl is downloaded, the connection to retrieve it is not cleanly closed
| 00009 | Open | PFN-Dist | 4 | When I create a file, I send a MKFILE to responsible of this file, but no to the parent dir responsible
| 00008 | Closed | PFNet | 5 | If two modifications of a file are sent at the same second, second modification will not be applied!
| 00007 | Closed | PFNet | 5 | When A<->B<->C, if B disconnects, A will trying to connect to C, but it doesn't work.
| 00006 | Open | Compile | 2 | If architecture of compilation wants to give gcc parameters which aren't supported by gcc-wrapper
| 00005 | Closed | Cache | 3 | When a file is received from network and is created, it doesn't store pf_mode
| 00004 | Closed | PFN-Dist | 3 | It seems to have a desynchronization between peers to know who is responsible of what file
| 00003 | Closed | PFN-Quit | 5 | Assertion failed in PeersList::GetDownLinks() when someone exits network, because a precedent
| | | | | removed ID isn't removed from Peer::downlinks
| | | | | #5 0x080d0bbb in PeersList::GetDownLinks (this=0x80f1a80, p=0x812f820) at /home/peerfuse/peerfuse/peerfuse-net/peers_list.cpp:96
| | | | | #6 0x080d0cd8 in PeersList::RemoveDownLinks (this=0x80f1a80, p=0x812f820) at /home/peerfuse/peerfuse/peerfuse-net/peers_list.cpp:109
| | | | | #7 0x080c47f4 in Network::OnRemovePeer (this=0x80f18a0, peer=0x812f820) at /home/peerfuse/peerfuse/peerfuse-net/network.cpp:102
| | | | | #8 0x080a2c43 in NetworkBase::RemovePeer (this=0x80f18a0, fd=7, try_reconnect=true) at /home/peerfuse/peerfuse/common/network_base.cpp:101
| 00002 | Open | PFL-Merge| 5 | There are some desynchronisation risk if a peer start a merge with a peer currently merging.
| 00001 | Open | PF-PKI | 1 | The sign-req script emits an error (no such file or dir on the key), that is normal.
+-------+--------+----------+----------+
# vim + grep
Posté par Romain . En réponse au journal Quel bug tracker utiliser ?. Évalué à 3.
+-------+--------+----------+----------+
| Bug no| Status | Category | Severity | Comments
+-------+--------+----------+----------+
| 00012 | Open | Cache | 4 | When there is a *file* /A, if an other peer tries to create /A/B (it considers that /A is a directory),
| | | | | a NoSuchFileOrDir exception is raised and there is a desynch.
| 00011 | Open | Cache | 5 | There is an undefined behavior which can cause a crash. Here is an example of backtrace:
| | | | | #0 0xffffe410 in __kernel_vsyscall ()
| | | | | #1 0xb7cf0701 in raise () from /lib/libc.so.6
| | | | | #2 0xb7cf1e38 in abort () from /lib/libc.so.6
| | | | | #3 0xb7fa9cbd in unwind_cleanup () from /lib/libpthread.so.0
| | | | | #4 0xb7df4abd in _Unwind_DeleteException () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1
| | | | | #5 0xb7f6f288 in __cxa_end_catch () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6
| | | | | #6 0x080cb7a0 in pf_read (path=0x856e5e0 "/Speedy's Coming [Live].mp3",
| | | | | buf=0x816d760 "\bÕÞ·\bÕÞ·v031円TALB", size=32768, offset=16384, fi=0xb7b352ec)
| | | | | at /home/vamps/peerfuse/common/fuse/read.cpp:47
| | | | | #7 0xb7eaabf2 in fuse_fs_read () from /usr/lib/libfuse.so.2
| 00010 | Open | | 1 | When the crl is downloaded, the connection to retrieve it is not cleanly closed
| 00009 | Open | PFN-Dist | 4 | When I create a file, I send a MKFILE to responsible of this file, but no to the parent dir responsible
| 00008 | Closed | PFNet | 5 | If two modifications of a file are sent at the same second, second modification will not be applied!
| 00007 | Closed | PFNet | 5 | When A<->B<->C, if B disconnects, A will trying to connect to C, but it doesn't work.
| 00006 | Open | Compile | 2 | If architecture of compilation wants to give gcc parameters which aren't supported by gcc-wrapper
| 00005 | Closed | Cache | 3 | When a file is received from network and is created, it doesn't store pf_mode
| 00004 | Closed | PFN-Dist | 3 | It seems to have a desynchronization between peers to know who is responsible of what file
| 00003 | Closed | PFN-Quit | 5 | Assertion failed in PeersList::GetDownLinks() when someone exits network, because a precedent
| | | | | removed ID isn't removed from Peer::downlinks
| | | | | #5 0x080d0bbb in PeersList::GetDownLinks (this=0x80f1a80, p=0x812f820) at /home/peerfuse/peerfuse/peerfuse-net/peers_list.cpp:96
| | | | | #6 0x080d0cd8 in PeersList::RemoveDownLinks (this=0x80f1a80, p=0x812f820) at /home/peerfuse/peerfuse/peerfuse-net/peers_list.cpp:109
| | | | | #7 0x080c47f4 in Network::OnRemovePeer (this=0x80f18a0, peer=0x812f820) at /home/peerfuse/peerfuse/peerfuse-net/network.cpp:102
| | | | | #8 0x080a2c43 in NetworkBase::RemovePeer (this=0x80f18a0, fd=7, try_reconnect=true) at /home/peerfuse/peerfuse/common/network_base.cpp:101
| 00002 | Open | PFL-Merge| 5 | There are some desynchronisation risk if a peer start a merge with a peer currently merging.
| 00001 | Open | PF-PKI | 1 | The sign-req script emits an error (no such file or dir on the key), that is normal.
+-------+--------+----------+----------+