28 Aug
2011
28 Aug
'11
5:08 p.m.
Hi,
On avg. we get 2 spam tickets a day on Trac. Can you add some level of spam protection to
add a ticket?
*CAPTCHA
*login required < this barrier is the quickest... (and is the same as other osmocom
tracs)
*changed ticket flow ( ticket not visible before approval)
Best,
Allard
28 Aug
28 Aug
8:51 p.m.
Hi all,
On Sun, Aug 28, 2011 at 05:08:34PM +0200, Allard Dijk wrote:
On avg. we get 2 spam tickets a day on Trac. Can you
add some level of
spam protection to add a ticket?
as Patrick is currently busy with the netfilter workshop, I have removed
TICKET_{CREATE,APPEND} for anonymous users.
I've also deleted tickets 22-75 as well as 77-84
In the process I also discovered that the trac.db is _very_ large
(5.1GB) since it contains all the changes of a linux kernel .git tree
going back to when Linus started to use git. I guess this might
experience some of the performance problems I'm sometimes experiencing
on the machine...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
8 Sep
8 Sep
11:37 a.m.
Am 28.08.2011 20:51, schrieb Harald Welte:
Hi all,
On Sun, Aug 28, 2011 at 05:08:34PM +0200, Allard Dijk wrote:
Thanks.
On avg. we get 2 spam tickets a day on Trac. Can
you add some level of
spam protection to add a ticket?
as Patrick is currently busy with the netfilter workshop, I have removed
TICKET_{CREATE,APPEND} for anonymous users.
I've also deleted tickets 22-75 as well as 77-84 In the process I also discovered that the trac.db is
_very_ large
(5.1GB) since it contains all the changes of a linux kernel .git tree
going back to when Linus started to use git. I guess this might
experience some of the performance problems I'm sometimes experiencing
on the machine...
Yes, its very slow interacting with git. Do you any hints how to
avoid this except disabling trac<->git interaction entirely?
12:53 p.m.
Hi Patrick,
On Thu, Sep 08, 2011 at 11:37:26AM +0200, Patrick McHardy wrote:
Yes, its very slow interacting with git. Do you any
hints how to
avoid this except disabling trac<->git interaction entirely?
I think for something as large as the linux kernel tree it might make
sense to disable it completely. Unfortunately the support for
'inceremntal repositories' was never fully implemented in git. This way
you could have a small repo on dect.osmocom.org containing only those
few commits that relate to DECT.
Another option would be to go for mysql or postgresql as database
backend. But even then, the load on the system (hosting dozens of
virtual machines for various projects) is probably still going to be
quite big...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6:37 p.m.
Am 08.09.2011 12:53, schrieb Harald Welte:
Hi Patrick,
On Thu, Sep 08, 2011 at 11:37:26AM +0200, Patrick McHardy wrote:
I don't think I need that, the gitweb interface should be enough,
I'll just disable it completely.
Thanks!
Yes, its very slow interacting with git. Do you
any hints how to
avoid this except disabling trac<->git interaction entirely?
I think for something as large as the linux kernel tree it might make
sense to disable it completely. Unfortunately the support for
'inceremntal repositories' was never fully implemented in git. This way
you could have a small repo on dect.osmocom.org containing only those
few commits that relate to DECT.
Another option would be to go for mysql or postgresql as database
backend. But even then, the load on the system (hosting dozens of
virtual machines for various projects) is probably still going to be
quite big...
4621
days inactive
4632
days old
4 comments
3 participants
participants (3)
-
Allard Dijk -
Harald Welte -
Patrick McHardy