Re: [dev] [sbase] about audit
On Thu, 1 Sep 2016 12:34:12 -0300 Marc Collin wrote: Hey Marc, > Yeah, I'm not complaining about the audits, I remember they found > many bugs! It was just a random thing that came to me - normally a > person that makes a mistake will overlook the mistake. But someone > from the outside should spot it more easily. > I don't even know if this is true, but I think it is based on self > experience. And I think the message was good, since now Ali H. Fardan > decided to go through the code too. > In the end everyone wins :) the fault was a bit at me because the audit-patches were so big and nobody would be arsed to check the mall. However, nobody stops you from subscribing to hackers@ and receiving all the commits. Open Source lives from many eyes checking changes. > Since we're talking about sbase already in kind of meta way, I'll post > a question here instead of a new email. > sbase is basically ready, right? The few missing tools are not yet > applied, but were sent to the ML by maandree some months ago (patch, > diff and others). Should we expect a release soon? I'm excited :) Oh well, this is a difficult topic. Sbase has received a lot of work and it works better in some respects than the GNU coreutils. Aside from sed, ed and grep the tools are well-audited and I am confident they can be used in everyday life. However, there are still some things to do, but it's really not something preventing a release. Up to this point, we have not gotten around for doing a release because there is always something that can get in the way. Most prominently, nobody wants to make a release only to get a bug report the next day for a critical problem in some tool. We tested the sbase tools extensively, but some bugs just show up after heavy usage or deployment. In some respects, sbase is almost too ambitious for the given manpower. An important point for instance is the UTF-8/Unicode stuff. I expanded libutf to support proper case conversions, but we are still lacking in detecting grapheme clusters and multi-codepoint case conversions. This all depends on my redevelopment of libutf that is currently in the works, but given some personal things I have not gotten around to it in the last few months and thus development kinda halted. Cheers FRIGN -- FRIGN
Re: [dev] [sbase] about audit
>http://git.suckless.org/sbase/tree/TODO >at https://github.com/maandree/sat >awk http://lists.suckless.org/dev/1602/28382.html >bc https://github.com/suiginsoft/bc >diff http://lists.suckless.org/hackers/1603/10326.html >patch http://lists.suckless.org/hackers/1603/10410.html >stty http://lists.suckless.org/hackers/1603/10466.html On Thu, Sep 1, 2016 at 12:38 PM, Ali H. Fardan wrote: > On 2016-09-01 18:34, Marc Collin wrote: >> >> Since we're talking about sbase already in kind of meta way, I'll post >> a question here instead of a new email. >> sbase is basically ready, right? The few missing tools are not yet >> applied, but were sent to the ML by maandree some months ago (patch, >> diff and others). Should we expect a release soon? I'm excited :) > > > http://git.suckless.org/sbase/tree/TODO
Re: [dev] [sbase] about audit
On 2016-09-01 18:34, Marc Collin wrote: Since we're talking about sbase already in kind of meta way, I'll post a question here instead of a new email. sbase is basically ready, right? The few missing tools are not yet applied, but were sent to the ML by maandree some months ago (patch, diff and others). Should we expect a release soon? I'm excited :) http://git.suckless.org/sbase/tree/TODO
Re: [dev] [sbase] about audit
Yeah, I'm not complaining about the audits, I remember they found many bugs! It was just a random thing that came to me - normally a person that makes a mistake will overlook the mistake. But someone from the outside should spot it more easily. I don't even know if this is true, but I think it is based on self experience. And I think the message was good, since now Ali H. Fardan decided to go through the code too. In the end everyone wins :) Since we're talking about sbase already in kind of meta way, I'll post a question here instead of a new email. sbase is basically ready, right? The few missing tools are not yet applied, but were sent to the ML by maandree some months ago (patch, diff and others). Should we expect a release soon? I'm excited :) On Thu, Sep 1, 2016 at 11:51 AM, Ali H. Fardan wrote: > On 2016-09-01 17:46, Marc Collin wrote: >> >> Hey guys. >> >> The missing brackets on paste.c that I talked about on the last >> message revealed something else to me. >> >> It was introduced in commit cdbc0d50356a0f7e0dd5755e3c46593a947cf029 >> by FRIGN, 2015-01-29. >> >> Then it was marked as audited and correct in commit >> 1bc002b44acdbfec8d374bfd0e5a858a142c0378 also by FRIGN, 2015-03-17. >> >> This makes me think that a file should not be audited by a person that >> had many contributions to it. Because if the person missed something >> at first, it's likely she will miss something again. Someone else that >> thinks in different ways is more likely to find errors. >> >> So I think files should be audited by third-parties or at least by >> more than 1 person before being marked as audited. This way there are >> less chances of passing a files as audited when there are still >> errors. >> >> Just to make it clear, I'm not criticizing FRIGN. This happens to >> everyone. It's *much* harder to find your own bugs, but easier to find >> other's bugs. That's what I think. >> >> Best wishes. > > > You're right, I'll go though the code > > Raiz
Re: [dev] [sbase] about audit
On 2016-09-01 17:46, Marc Collin wrote: Hey guys. The missing brackets on paste.c that I talked about on the last message revealed something else to me. It was introduced in commit cdbc0d50356a0f7e0dd5755e3c46593a947cf029 by FRIGN, 2015-01-29. Then it was marked as audited and correct in commit 1bc002b44acdbfec8d374bfd0e5a858a142c0378 also by FRIGN, 2015-03-17. This makes me think that a file should not be audited by a person that had many contributions to it. Because if the person missed something at first, it's likely she will miss something again. Someone else that thinks in different ways is more likely to find errors. So I think files should be audited by third-parties or at least by more than 1 person before being marked as audited. This way there are less chances of passing a files as audited when there are still errors. Just to make it clear, I'm not criticizing FRIGN. This happens to everyone. It's *much* harder to find your own bugs, but easier to find other's bugs. That's what I think. Best wishes. You're right, I'll go though the code Raiz
Re: [dev] [sbase] about audit
On Thu, 1 Sep 2016 11:46:36 -0300 Marc Collin wrote: Hey Marc, > The missing brackets on paste.c that I talked about on the last > message revealed something else to me. > > It was introduced in commit cdbc0d50356a0f7e0dd5755e3c46593a947cf029 > by FRIGN, 2015-01-29. > > Then it was marked as audited and correct in commit > 1bc002b44acdbfec8d374bfd0e5a858a142c0378 also by FRIGN, 2015-03-17. > > This makes me think that a file should not be audited by a person that > had many contributions to it. Because if the person missed something > at first, it's likely she will miss something again. Someone else that > thinks in different ways is more likely to find errors. > > So I think files should be audited by third-parties or at least by > more than 1 person before being marked as audited. This way there are > less chances of passing a files as audited when there are still > errors. > > Just to make it clear, I'm not criticizing FRIGN. This happens to > everyone. It's *much* harder to find your own bugs, but easier to find > other's bugs. That's what I think. yeah sorry for introducing this. Mistakes happen. Overall, the audits fixed many many bugs though, so it's pain that can be taken. Send a patch to fix it and everything is cool. :) Cheers FRIGN -- FRIGN
[dev] [sbase] about audit
Hey guys. The missing brackets on paste.c that I talked about on the last message revealed something else to me. It was introduced in commit cdbc0d50356a0f7e0dd5755e3c46593a947cf029 by FRIGN, 2015-01-29. Then it was marked as audited and correct in commit 1bc002b44acdbfec8d374bfd0e5a858a142c0378 also by FRIGN, 2015-03-17. This makes me think that a file should not be audited by a person that had many contributions to it. Because if the person missed something at first, it's likely she will miss something again. Someone else that thinks in different ways is more likely to find errors. So I think files should be audited by third-parties or at least by more than 1 person before being marked as audited. This way there are less chances of passing a files as audited when there are still errors. Just to make it clear, I'm not criticizing FRIGN. This happens to everyone. It's *much* harder to find your own bugs, but easier to find other's bugs. That's what I think. Best wishes.
