Hi, The Bugtrack DB was updated for dillo2 too. -- Cheers Jorge.-
Jorge wrote:
The Bugtrack DB was updated for dillo2 too.
When I compare it to an old copy I have locally, it appears as if entries were deleted randomly rather than because they have been fixed. e.g., starting at the top, there used to be 127. "optgroup is ignored...", and optgroup is still commented out in Tags. But 128. "in form, input type=file is ignored..." remains, even though I implemented that.
On Fri, Aug 29, 2008 at 01:56:44PM +0000, corvid wrote:
Jorge wrote:
The Bugtrack DB was updated for dillo2 too.
When I compare it to an old copy I have locally, it appears as if entries were deleted randomly rather than because they have been fixed.
e.g., starting at the top, there used to be 127. "optgroup is ignored...", and optgroup is still commented out in Tags. But 128. "in form, input type=file is ignored..." remains, even though I implemented that.
They were not deleted at random. I checked lots of them and set "done" on the ones that work. This is with regard to dillo2. If they still don't work in dillo1 doesn't matter. Along the long way a few were deleted... I also wondered whether to start with a clean bug-track, but preferred to comb the whole DB and try to keep the valuable information. If you take a bigger sample, the first impression may change. -- Cheers Jorge.-
Jorge wrote:
On Fri, Aug 29, 2008 at 01:56:44PM +0000, corvid wrote:
Jorge wrote:
The Bugtrack DB was updated for dillo2 too.
When I compare it to an old copy I have locally, it appears as if entries were deleted randomly rather than because they have been fixed.
e.g., starting at the top, there used to be 127. "optgroup is ignored...", and optgroup is still commented out in Tags. But 128. "in form, input type=file is ignored..." remains, even though I implemented that.
They were not deleted at random.
I checked lots of them and set "done" on the ones that work. This is with regard to dillo2. If they still don't work in dillo1 doesn't matter.
I set done on things a while back if they worked, (sometimes leaving UI ones if the fltk replacement feature still had its own brokenness).
Along the long way a few were deleted... I also wondered whether to start with a clean bug-track, but preferred to comb the whole DB and try to keep the valuable information.
If you take a bigger sample, the first impression may change.
Let's see. Starting from the top: 127. optgroup. fixed: NO deleted: YES 128. file input. fixed: YES deleted: NO 131. frames. fixed: NO deleted: YES 138. anim. gifs. fixed: NO deleted: NO 159. cache limit. fixed: NO deleted: YES 161. cache control. fixed: NO deleted: YES 185. "Tables, part II: structure elements" fixed: depends on whether that means thead et al. deleted: YES 220. forms don't remember data. fixed: NO deleted: YES 224. AUTH. fixed: NO deleted: NO 242. CSS. fixed: NO deleted: NO 245. image-broken indicator. fixed: NO deleted: NO 250. PNG alpha different bgrounds. fixed: NO deleted: YES 270. punctuation wrapping. fixed: NO deleted: YES 281. non-latin-1 charsets. fixed: YES deleted: NO (gets bored) First impression has not changed.
On Fri, Aug 29, 2008 at 03:05:04PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 29, 2008 at 01:56:44PM +0000, corvid wrote:
Jorge wrote:
The Bugtrack DB was updated for dillo2 too.
When I compare it to an old copy I have locally, it appears as if entries were deleted randomly rather than because they have been fixed.
e.g., starting at the top, there used to be 127. "optgroup is ignored...", and optgroup is still commented out in Tags. But 128. "in form, input type=file is ignored..." remains, even though I implemented that.
They were not deleted at random.
I checked lots of them and set "done" on the ones that work. This is with regard to dillo2. If they still don't work in dillo1 doesn't matter.
I set done on things a while back if they worked, (sometimes leaving UI ones if the fltk replacement feature still had its own brokenness).
Along the long way a few were deleted... I also wondered whether to start with a clean bug-track, but preferred to comb the whole DB and try to keep the valuable information.
If you take a bigger sample, the first impression may change.
Let's see. Starting from the top:
fixed: YES deleted: NO is OK as long as its marked as "done" (they are removed once the release is made) fixed: NO deleted: NO is OK fixed: NO deleted: YES is a mistake (unless a "won't fix") I'll comment the mistakes:
127. optgroup. fixed: NO deleted: YES
May be re-inserted.
128. file input. fixed: YES deleted: NO 131. frames. fixed: NO deleted: YES
Duplicated, 660 is the same (and has an email)
138. anim. gifs. fixed: NO deleted: NO 159. cache limit. fixed: NO deleted: YES 161. cache control. fixed: NO deleted: YES
Kind of a "won't fix" for the moment. One of the ideas of the cache is not loosing the visited pages upon Bck/Fwd or when offline. Implementing this would need a new cache design.
185. "Tables, part II: structure elements" fixed: depends on whether that means thead et al. deleted: YES
Not very descriptive. Major work needing a new head developer. Sebastian name there was misleading in the sense that is was being worked.
220. forms don't remember data. fixed: NO deleted: YES
Needs a re-insert (I thought it was duplicated).
224. AUTH. fixed: NO deleted: NO 242. CSS. fixed: NO deleted: NO 245. image-broken indicator. fixed: NO deleted: NO 250. PNG alpha different bgrounds. fixed: NO deleted: YES
Duplicated with 542.
270. punctuation wrapping. fixed: NO deleted: YES
Example URL doesn't exist anymore.
281. non-latin-1 charsets. fixed: YES deleted: NO
-- Cheers Jorge.-
Jorge wrote:
On Fri, Aug 29, 2008 at 03:05:04PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 29, 2008 at 01:56:44PM +0000, corvid wrote:
Jorge wrote:
The Bugtrack DB was updated for dillo2 too.
When I compare it to an old copy I have locally, it appears as if entries were deleted randomly rather than because they have been fixed.
e.g., starting at the top, there used to be 127. "optgroup is ignored...", and optgroup is still commented out in Tags. But 128. "in form, input type=file is ignored..." remains, even though I implemented that.
They were not deleted at random.
I checked lots of them and set "done" on the ones that work. This is with regard to dillo2. If they still don't work in dillo1 doesn't matter.
I set done on things a while back if they worked, (sometimes leaving UI ones if the fltk replacement feature still had its own brokenness).
Along the long way a few were deleted... I also wondered whether to start with a clean bug-track, but preferred to comb the whole DB and try to keep the valuable information.
If you take a bigger sample, the first impression may change.
Let's see. Starting from the top:
fixed: YES deleted: NO is OK as long as its marked as "done" (they are removed once the release is made)
fixed: NO deleted: NO is OK fixed: NO deleted: YES is a mistake (unless a "won't fix")
I'll comment the mistakes:
127. optgroup. fixed: NO deleted: YES
May be re-inserted.
128. file input. fixed: YES deleted: NO 131. frames. fixed: NO deleted: YES
Duplicated, 660 is the same (and has an email)
Ah, so the old ones get deleted as dups of the new ones. That is not the way I expected this to work. But it improves our metrics.
138. anim. gifs. fixed: NO deleted: NO 159. cache limit. fixed: NO deleted: YES 161. cache control. fixed: NO deleted: YES
Kind of a "won't fix" for the moment. One of the ideas of the cache is not loosing the visited pages upon Bck/Fwd or when offline. Implementing this would need a new cache design.
Pulling out wontfixes? Perhaps it would be of some value to have a document showing, like... cache: what you said. anim. gifs: none of the current developers want the feature, but a good patch will be accepted if it can be disabled. forms remembering data: that i've been sort of considering it -- with mixed feelings -- but have not felt any great urgency regarding this matter :) AUTH: if I were given a way to test it, I'd be willing to look into the matter in case it turned out to be trivial, but wouldn't promise anything more. png backgrounds: that I tried once, did not succeed, but still have the code if anybody should want to dig into it. punctuation wrapping: none of the current developers have shown much interest in dealing with textblock.cc. etc...etc...
185. "Tables, part II: structure elements" fixed: depends on whether that means thead et al. deleted: YES
Not very descriptive. Major work needing a new head developer. Sebastian name there was misleading in the sense that is was being worked.
220. forms don't remember data. fixed: NO deleted: YES
Needs a re-insert (I thought it was duplicated).
224. AUTH. fixed: NO deleted: NO 242. CSS. fixed: NO deleted: NO 245. image-broken indicator. fixed: NO deleted: NO 250. PNG alpha different bgrounds. fixed: NO deleted: YES
Duplicated with 542.
270. punctuation wrapping. fixed: NO deleted: YES
Example URL doesn't exist anymore.
But any stretch of, like, "<a href=sdfsfl>ksjfk</a>, ksdjfds" shows the problem. *checks whether you deleted the one as well* You did. But...soft hyphens don't work...
281. non-latin-1 charsets. fixed: YES deleted: NO
On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 29, 2008 at 03:05:04PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 29, 2008 at 01:56:44PM +0000, corvid wrote:
Jorge wrote:
The Bugtrack DB was updated for dillo2 too.
When I compare it to an old copy I have locally, it appears as if entries were deleted randomly rather than because they have been fixed.
e.g., starting at the top, there used to be 127. "optgroup is ignored...", and optgroup is still commented out in Tags. But 128. "in form, input type=file is ignored..." remains, even though I implemented that.
They were not deleted at random.
I checked lots of them and set "done" on the ones that work. This is with regard to dillo2. If they still don't work in dillo1 doesn't matter.
I set done on things a while back if they worked, (sometimes leaving UI ones if the fltk replacement feature still had its own brokenness).
Along the long way a few were deleted... I also wondered whether to start with a clean bug-track, but preferred to comb the whole DB and try to keep the valuable information.
If you take a bigger sample, the first impression may change.
Let's see. Starting from the top:
fixed: YES deleted: NO is OK as long as its marked as "done" (they are removed once the release is made)
fixed: NO deleted: NO is OK fixed: NO deleted: YES is a mistake (unless a "won't fix")
I'll comment the mistakes:
127. optgroup. fixed: NO deleted: YES
May be re-inserted.
128. file input. fixed: YES deleted: NO 131. frames. fixed: NO deleted: YES
Duplicated, 660 is the same (and has an email)
Ah, so the old ones get deleted as dups of the new ones. That is not the way I expected this to work. But it improves our metrics.
138. anim. gifs. fixed: NO deleted: NO 159. cache limit. fixed: NO deleted: YES 161. cache control. fixed: NO deleted: YES
Kind of a "won't fix" for the moment. One of the ideas of the cache is not loosing the visited pages upon Bck/Fwd or when offline. Implementing this would need a new cache design.
Pulling out wontfixes?
Perhaps it would be of some value to have a document showing, like... cache: what you said. anim. gifs: none of the current developers want the feature, but a good patch will be accepted if it can be disabled. forms remembering data: that i've been sort of considering it -- with mixed feelings -- but have not felt any great urgency regarding this matter :) AUTH: if I were given a way to test it, I'd be willing to look into the matter in case it turned out to be trivial, but wouldn't promise anything more. png backgrounds: that I tried once, did not succeed, but still have the code if anybody should want to dig into it. punctuation wrapping: none of the current developers have shown much interest in dealing with textblock.cc. etc...etc...
Yes, more or less that's the point. ;) -- Cheers Jorge.-
Jorge wrote:
On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote:
Perhaps it would be of some value to have a document showing, like... cache: what you said. anim. gifs: none of the current developers want the feature, but a good patch will be accepted if it can be disabled. forms remembering data: that i've been sort of considering it -- with mixed feelings -- but have not felt any great urgency regarding this matter :) AUTH: if I were given a way to test it, I'd be willing to look into the matter in case it turned out to be trivial, but wouldn't promise anything more. png backgrounds: that I tried once, did not succeed, but still have the code if anybody should want to dig into it. punctuation wrapping: none of the current developers have shown much interest in dealing with textblock.cc. etc...etc...
Yes, more or less that's the point. ;)
Of the bug tracker as it is now?
On Fri, Aug 29, 2008 at 07:41:46PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote:
Perhaps it would be of some value to have a document showing, like... cache: what you said. anim. gifs: none of the current developers want the feature, but a good patch will be accepted if it can be disabled. forms remembering data: that i've been sort of considering it -- with mixed feelings -- but have not felt any great urgency regarding this matter :) AUTH: if I were given a way to test it, I'd be willing to look into the matter in case it turned out to be trivial, but wouldn't promise anything more. png backgrounds: that I tried once, did not succeed, but still have the code if anybody should want to dig into it. punctuation wrapping: none of the current developers have shown much interest in dealing with textblock.cc. etc...etc...
Yes, more or less that's the point. ;)
Of the bug tracker as it is now?
Strange as it may look: I'd rather prefer a bugtracker with a few entries that are being worked-on than a complete one whith a long list that no-one cares enough to work on. And most probably the best point lies somewhere in the middle (as the current bugtracker). Of course a detailed list gives a good idea of what's to be done, and if there're developers willing to work on them that's great, but watching the same entries unworked for years makes me think this way. If you see a way to improve the situation please feel free to do. -- Cheers Jorge.-
Jorge wrote:
On Fri, Aug 29, 2008 at 07:41:46PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote:
Perhaps it would be of some value to have a document showing, like... cache: what you said. anim. gifs: none of the current developers want the feature, but a good patch will be accepted if it can be disabled. forms remembering data: that i've been sort of considering it -- with mixed feelings -- but have not felt any great urgency regarding this matter :) AUTH: if I were given a way to test it, I'd be willing to look into the matter in case it turned out to be trivial, but wouldn't promise anything more. png backgrounds: that I tried once, did not succeed, but still have the code if anybody should want to dig into it. punctuation wrapping: none of the current developers have shown much interest in dealing with textblock.cc. etc...etc...
Yes, more or less that's the point. ;)
Of the bug tracker as it is now?
Strange as it may look: I'd rather prefer a bugtracker with a few entries that are being worked-on than a complete one whith a long list that no-one cares enough to work on. And most probably the best point lies somewhere in the middle (as the current bugtracker).
Of course a detailed list gives a good idea of what's to be done, and if there're developers willing to work on them that's great, but watching the same entries unworked for years makes me think this way.
If you see a way to improve the situation please feel free to do.
I'm not sure that I see how deleting some of the entries will cause other entries to be worked on, but oh well... *tires of topic at last*
participants (2)
-
corvid＠lavabit.com -
jcid＠dillo.org