Opened 15 years ago
Closed 14 years ago
#8883 closed enhancement (fixed)
[PATCH] Add variable number of entries to spamtracker monitoring
| Reported by: | stoecker | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | plugin - spam-filter |
| Component: | plugin/spamfilter | Version: | none |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
The attached patch adds the possibility to have a variable number of entries in the spamtracker monitoring. It works as expected, but I did not yet expose the functionality to the user. Currently adding "?num" or "&num" to the initial page load is required.
Attachments (2)
Change History (14)
by , 15 years ago
| Attachment: | count.diff added |
|---|
comment:1 by , 15 years ago
| Milestone: | → not applicable |
|---|
Nearly fine, please see TracDev/CodingStyle. In particular, lines must shorter than 80 columns and there should be a space after commas.
comment:2 by , 15 years ago
| Milestone: | not applicable → spam-filter-plugin |
|---|
Hm, it looks we scare everyone away with our coding style ;-)
comment:3 by , 15 years ago
Actaully you scare away people with not applying simple patches for months. I have some other bug-fixes, but don't bother to report them at all, as preparing the report is not worth the effort.
comment:4 by , 15 years ago
That's a pretty sad comment there, and I hope it wasn't intended to sound as harsh as it did.
Christian asked for two very simple changes (limiting line lengths to 80 columns and adding spaces after commas) and got nothing but silence as a reply. The trouble with "simple patches" that need "small cleanups" is that if the (limited number of) Trac maintainers accepted them as-is and did the cleanups themselves, they would do nothing else. Whereas if the (many) patch contributors clean up their patches, the work is more distributed, and the maintainers can integrate the contributions quickly, and still have time to move the project forward.
So the unspoken general rule here is along the lines of: patches for which the contributor is not willing to invest at least a bit of effort to adjust them according to feedback from maintainers (be it coding style or architecture) will not be integrated. It's the only way to avoid having the project grind to a halt.
I hope this explains the situation a bit, and that you might even reconsider your position. Receiving feedback to one's own work is difficult in the beginning, but very rewarding in the long run. It's certainly a good way to improve one's skills.
follow-ups: 6 8 comment:5 by , 15 years ago
It was meant as said. I did add 3 reports with patches at the same time and none of these has been applied (althought they habe been found useful in general).
I did and do manage lots of OpenSource projects as well and minor formating issues are never reason not to apply patches (especially when original code does not follow the guidelines as well). I even discourage people to do formating changes, as they make reading patches harder.
Your second paragraph is wrong. It is true for larger patches, but not for short patches like this one.
You assume only the time of Trac developers is valuable. For me Trac is a tool which has to do its work. When I find problems I fix them locally. And due to the idea of opensource I make a report to improve the original. When these are not applied I don't report any more, as reporting makes work as well. My local installation works fine even when patches are not applied.
Every project either gets no responses, bug reports or reports including patches. Discouraging the people who send patches is a dumb idea in my eyes, as normally you wont get the solution together with the problem.
comment:6 by , 15 years ago
Replying to stoecker:
It was meant as said. I did add 3 reports with patches at the same time and none of these has been applied (although they have been found useful in general).
It's simply that I haven't made a round of improvements to the SpamFilter plugin since months. The next time this happens (and this might happen soon for a 0.12 only version of the plugin), I'll certainly try to take care of those patches.
I did and do manage lots of OpenSource projects as well and minor formating issues are never reason not to apply patches (especially when original code does not follow the guidelines as well). I even discourage people to do formating changes, as they make reading patches harder.
But that's what you did, you introduced deviations from the coding style (not specifically from our own, from the standard Python one PEP:0008) that we need to fix before applying the patch.
Your second paragraph is wrong. It is true for larger patches, but not for short patches like this one.
Well, so instead of 2 minutes, I'd have to spend 5 minutes. Not a big deal. The big deal is the "context switch", getting to work on the SpamFilter again. The incentive to do this switch would be higher if I know there are good patches ready to apply, not ones which I have to fix first.
You assume only the time of Trac developers is valuable. For me Trac is a tool which has to do its work. When I find problems I fix them locally. And due to the idea of opensource I make a report to improve the original. When these are not applied I don't report any more, as reporting makes work as well. My local installation works fine even when patches are not applied.
Fair enough, and thanks indeed for contributing the patches back. We simply tried to explain you why those patches didn't get applied quicker and hinted at ways to possibly speed that up (already explained at length in TracDev/SubmittingPatches#Whatisagoodpatch, btw).
Every project either gets no responses, bug reports or reports including patches. Discouraging the people who send patches is a dumb idea in my eyes, as normally you wont get the solution together with the problem.
Each project has its own barrier-to-entry level. Trac's one is pretty low, we find ourselves often accepting patches without unit-tests, patches that we need to rework, etc. You just have to realize that we have something like ~1000 tickets opened, some with good patches waiting for years, some corresponding to critical issues that take lot of time and effort to fix. We're currently 2 active maintainers for that project and I mean for Trac itself, not for its SpamFilter plugin ;-).
(and no, I think the time spent answering you is not wasted and can provide a reasonable answer to the general Why is my patch not yet applied? question)
comment:7 by , 15 years ago
To be comparable: For JOSM we currently have 606 reports (289 bugs, only few serious ones) out of 4864 (most of them done in last 2 years). These reports include 4 patches which are in state of beeing rejected (or be reworked).
The number of acceptable patches for JOSM is usally zero (except one was overlooked). This is pretty easy to do: everything which contains something like [PATCH] in the topic gets priority.
This way I as maintainer found a set of people willing to improve the software and take away work from me. They get better access after some work done and feel encouraged. Maybe the way you handle contributions of others is one reason why Trac has only 2 active members? Anyway it is your decision how to handle Trac and my if I want to contribute any more.
comment:8 by , 15 years ago
Replying to stoecker:
I did and do manage lots of OpenSource projects as well (…)
This is a fact I couldn't guess from your first comment, and obviously my explanations were then quite redundant.
and minor formating issues are never reason not to apply patches (especially when original code does not follow the guidelines as well).
That's largely a matter of personal (or project) preference. You may be interested in the concept of fixing broken windows, though. You're right, there still are a few occurrences of style violations in the Trac code, but they are the exception rather than the norm. We fix them as we come across them.
You assume only the time of Trac developers is valuable.
Not really. Asking contributors clean up their patches is a simple attempt at parallelizing tasks. Whether it's efficient or not can probably be debated to death.
When these are not applied I don't report any more, as reporting makes work as well.
Fair enough, you're free to use your own time as you see fit. Still, thanks for the contributions that you did post.
Every project either gets no responses, bug reports or reports including patches. Discouraging the people who send patches is a dumb idea in my eyes, as normally you wont get the solution together with the problem.
I guess our views of how an open source project should be run are pretty much divergent. Fortunately, this doesn't really matter.
comment:9 by , 14 years ago
I guess our views of how an open source project should be run are pretty much divergent. Fortunately, this doesn't really matter.
Seems so. I don't understand your view at all. Waiting 5 months for patch integration is a bit long. I thought maybe fixing a major issue like #7173 may help, but no - same situation. So I now finally stop to supply patches.
I continue to improve Trac and spamfilter plugin. If you are interested (which I doubt) in the fixes, you will find them from now on only in the source RPMs of openSUSE buildservice at
http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_Factory/src/
e.g. trac-plugin-spamfilter.
Normally informing upstream is recommended for packagers. Seems in your case this is wasted effort.
comment:10 by , 14 years ago
As you've seen, the problem is that there's currently no one in the position to be really "upstream". The original authors of the plugins have lost interest in maintaining them (and in Trac in general), and the current maintainers of Trac are only interested in that plugin to the extent that we rely on it heavily for keeping t.e.o (this place) sane.
But as it basically works for us, there's not much interest to actively develop it further, not to mention we're quite busy these days with trying to get Trac 0.12 itself out of the door.
Contributing the patches like you did is very good for at least the following reasons:
- other people using the SpamFilter plugin and needing the same feature will likely find them here rather than in some place in OpenSUSE
- it shows us that you're indeed interested in the long term maintenance of this plugin, so that we could eventually give you this possibility if you were interested
… but saying that you will now "stop supply" patches is not a step in this direction.
comment:11 by , 14 years ago
For me "spamfilter" did not really work good. It is essential for my Trac installation (there are times when I get 200-500 spams a day - due to 100% rejection in last months with hand-work it is down to 10-30 [seems the spammers also learn where to try it and where not]), but has many drawbacks (too much handwork e.g. in bayes training, …). Some of them I did already fix and supply patches. Others are still open and in development.
If you have missing maintainer, well I anyway do this work now, so I can do it also officially. It's not like I have not enough to do, but if this is required to get this going, then I will do it. But then I need support from your side, as I do not really know Trac in detail and have to spend lots of time to find out things which are obvious to you.
I can be contacted at "trac at dstoecker dot de".
Patch