Changes between Version 1 and Version 2 of Ticket #12398, comment 6
- Timestamp:
- Apr 23, 2016, 11:30:07 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #12398, comment 6
v1 v2 14 14 > - there are basically two categories of Trac users, those using it on the open, and those using it within intranets; for the second category, which I suspect is the largest, the SpamFilter is entirely unnecessary; at the very least, we would have to make sure to mark all the introduced dependencies as optional 15 15 16 That was my reasoning for putting it in `tracopt`. `tracopt` by definition contains optional components, so !SpamFilter would no different in this regard than the Subversion and Git connectors. For users that don't need !SpamFilter the only affect would be a slightly larger egg, and it would be trivially larger.16 That was my reasoning for putting it in `tracopt`. `tracopt` by definition contains optional components, so !SpamFilter would no different in this regard than the Subversion and Git connectors. For users that don't need !SpamFilter the only effect would be a slightly larger egg, and it would be trivially larger. 17 17 18 18 You are probably right that the majority of users are running a "private" Trac instance, but !SpamFilter is extremely important to public installations, some of which have been users of Trac for a long time and represent important and very visible projects: !MacPorts, Django, !WordPress, jQuery UI. I don't know that all of those are running !SpamFilter, but assuming it's important to some. Moving !SpamFilter to `tracopt` might help make sure it receives first-class maintenance. … … 20 20 > I think the possibility to have a different pace of releases for the SpamFilter if kept separate is also appreciable, given the relative volatility of the external services it depends on. 21 21 22 Currently !SpamFilter doesn't get any formal releases, so that's something we need to improve on one way or another. The time to create a Trac release has been shortened considerably and I think we can maintain the pace of every 2 months or so. I'm interested to know how often a change in !SpamFilter would necessitate an immediate release because that is an important data point. From what I've seen there is maybe once or twice per year that a major change needs to be pushed, and the last incident I can think of was due to a service ending a few months from the time the change was made, giving adequate lead time to push the release. 22 Currently !SpamFilter doesn't get any formal releases, so that's something we need to improve on one way or another. The time to create a Trac release has been shortened considerably and I think we can maintain the pace of every 2 months or so. I'm interested to know how often a change in !SpamFilter would necessitate an immediate release because that is an important data point. From what I've seen there is maybe once or twice per year that a major change needs to be pushed, and the last incident I can think of was due to a service ending a few months from the time the change was made, giving adequate lead time to push the release. I'd be okay with moving up a planned release of Trac to push out an important change to !SpamFilter, as long it's no more than once or twice per year. 23 23 24 24 > Now one thing that might make sense is to have the //core// of the SpamFilter in `tracopt` and a few modules that don't depend on any external service (3rd party package dependencies would be OK, like Pillow or spambayes, but not external services). External services could be added on a one by one basis (trac-spamfilter-akismet, trac-spamfilter-mollom, etc.). … … 36 36 * The Trac codebase needs to be kept to a size that can be managed by the Trac dev team. 37 37 38 With regard to the latter point and considering a hypothetical, even if the Trac dev team doubled in size this year, we'd need to make sure that we've achieved maintainable momentum before adding many major features to Trac. The risk is that the size of the team could shrink, and Trac would collapse if the number of bugs grew too large for the dev team to maintain.38 With regard to the latter point and considering a hypothetical, even if the Trac dev team doubled in size this year, we'd need to make sure that we've achieved sustainable momentum before adding many major features to Trac. The risk is that the size of the team could shrink, and Trac would collapse if the number of bugs grew too large for the dev team to maintain. 39 39 40 40 At this time moving !SpamFilter to `tracopt` would have to wait for Trac 1.4. We can always revisit the debate later in the 1.3.x dev cycle. I can find plenty of other "pieces" to integrate to Trac in the meantime.
