I
Ilias Lazaridis
Essence:
* Trac is deficient, cause of "proud to be an egoism driven amateur"
developers
* Python and it's communities is excellent for learning. Not
programming, but to "learn from deficiency", community organization,
transparency, efficiency etc.!
* Do it in perl, if you need something more 'pretty', do it in ruby,
if you need something more 'serious' do it in java, if you have enough
brain and time, do it in C++ from bottom up.
-
I don't think that's a secret anymore. Anyone should know that the
trac team has huge problems to bring trac forward. People who have
looked at the code-base and project understand some reason: difficult
to maintain 'spaghetti-code' in many places, disorganized project,
missing separations of concerns etc.! I've provided an overview some
time ago
http://case.lazaridis.com/wiki/TracAudit
At this time the developers are searching like crazy to find a mem-
leak... since months.
http://trac.edgewall.org/ticket/6614
But the main problem with the trac team is the processing within
project resources. Believe it or not, developers can act within this
project as they like, 'trimming' ticket comments in a way that a
ticket gets a totally other meaning.
The main specialist for this is Mr. Noah Kantrowitz. He calls it
"sanitizing". The team hides behind him, cowardly, without any public
vote.
How did everything start?
I post a simple message to trac-users (note: the user resource, NOT
the developer resource), in order to extend my custom version of trac
0.11 a little. The message did not appear, as my email is under
moderation. I do not switch to another email, as I write always with
the same identity.
So i file a ticket within the ticket system (here you can see the
"After a quick vote, it has been decided to sanitize this ticket. "...
I start to like this "sanitize" term, sounds really interesting)
http://trac.edgewall.org/ticket/6802
Mr. Noah Kantrowitz deleted the discussion, but I've saved it here,
thus you can see that the developers of trac have no idea about their
own processes:
http://case.lazaridis.com/ticket/48
After the developers placed the usual irrelevant comments (remember: I
just asked them to stop blocking my messages to trac users), they
"brute force closed" the ticket.
I've opened a new one, directly adressed to the project lead, in order
to complain about the developers which violate the project processes,
and to ask for a formal vote:
http://trac.edgewall.org/ticket/6844
Right! Mr. Noah Kantrowitz plays again "wild west". I relly don't know
who of those two is more funny: the one who plays the dictator, or the
other joker who suggests to revers the process (I should find
developers to veto against the censorship and send the to the team).
Remember: we are talking about the trac-user group.
I really cannot believe that a whole team can be in such way confused,
nuts, blind, egoism-driven etc.! Possibly they have lost the password
to the trac-user group, and are not able to manage it - who knows. I
would not wonder, seeing thos terrible processes and the rejection to
improve them.
(btw: If you like to act against censorship, please post this message
to trac-users, thus the get informed about the teams processing)
And we are talking about censorship of a trac 0.11dev custom-version-
developer. A custom version with localization support, plugin-bundles
(product-plugin) which run out of the svn, an fully functional but
simple side-navigation, and... everything deactivatable with a very
simple way, thus the original trac is there again.
http://dev.lazaridis.com/base
Open Source works like this: many many small human ego's need to be
fitted. There's no place for developers which could redesign the whole
thing within a few months. the trac-developers need to 'fight' with
tons of spaghetti. The developers plan like crazy, instead to merge
with a application framework like e.g. turbogears. Did you know that
trac has no support for... datetime fields? Yes, its true.
You may say: do it yourself. Of course I could do it, even without
touching the main sources (using dyna-patches or monkeypatches). But
that's not how open-source works. You implement thing for yourself and
contribute things back to the core-project - but with trac there's one
problem: no one get's the core anymore (apparently the initial
developer has left)
Of course I'll not stay with trac, I'll leave the sinking ship, I've
prepare long time ago to do so, step by step. An will migrate step by
step away from trac and python - toward an own implementation based
on...
perl and it's libraries.
Really, I don't understand the need for python. And after fighting
with some indenting within html templates, I dislike the whitespace-
syntax-thing of python again.
Do it in perl, if you need something more 'pretty', do it in ruby, if
you need something more 'serious' do it in java, if you have enough
brain and time, do it in C++ from bottom up.
Python and it's communities is excellent for learning. Not
programming, but to "learn from deficiency", community organization,
transparency, efficiency etc.!
-
So, keep your eyes on this project, if you want to be prepared to jump-
off the sinking ship "trac"
http://dev.lazaridis.com/base/
-
Party Time!
..
* Trac is deficient, cause of "proud to be an egoism driven amateur"
developers
* Python and it's communities is excellent for learning. Not
programming, but to "learn from deficiency", community organization,
transparency, efficiency etc.!
* Do it in perl, if you need something more 'pretty', do it in ruby,
if you need something more 'serious' do it in java, if you have enough
brain and time, do it in C++ from bottom up.
-
I don't think that's a secret anymore. Anyone should know that the
trac team has huge problems to bring trac forward. People who have
looked at the code-base and project understand some reason: difficult
to maintain 'spaghetti-code' in many places, disorganized project,
missing separations of concerns etc.! I've provided an overview some
time ago
http://case.lazaridis.com/wiki/TracAudit
At this time the developers are searching like crazy to find a mem-
leak... since months.
http://trac.edgewall.org/ticket/6614
But the main problem with the trac team is the processing within
project resources. Believe it or not, developers can act within this
project as they like, 'trimming' ticket comments in a way that a
ticket gets a totally other meaning.
The main specialist for this is Mr. Noah Kantrowitz. He calls it
"sanitizing". The team hides behind him, cowardly, without any public
vote.
How did everything start?
I post a simple message to trac-users (note: the user resource, NOT
the developer resource), in order to extend my custom version of trac
0.11 a little. The message did not appear, as my email is under
moderation. I do not switch to another email, as I write always with
the same identity.
So i file a ticket within the ticket system (here you can see the
"After a quick vote, it has been decided to sanitize this ticket. "...
I start to like this "sanitize" term, sounds really interesting)
http://trac.edgewall.org/ticket/6802
Mr. Noah Kantrowitz deleted the discussion, but I've saved it here,
thus you can see that the developers of trac have no idea about their
own processes:
http://case.lazaridis.com/ticket/48
After the developers placed the usual irrelevant comments (remember: I
just asked them to stop blocking my messages to trac users), they
"brute force closed" the ticket.
I've opened a new one, directly adressed to the project lead, in order
to complain about the developers which violate the project processes,
and to ask for a formal vote:
http://trac.edgewall.org/ticket/6844
Right! Mr. Noah Kantrowitz plays again "wild west". I relly don't know
who of those two is more funny: the one who plays the dictator, or the
other joker who suggests to revers the process (I should find
developers to veto against the censorship and send the to the team).
Remember: we are talking about the trac-user group.
I really cannot believe that a whole team can be in such way confused,
nuts, blind, egoism-driven etc.! Possibly they have lost the password
to the trac-user group, and are not able to manage it - who knows. I
would not wonder, seeing thos terrible processes and the rejection to
improve them.
(btw: If you like to act against censorship, please post this message
to trac-users, thus the get informed about the teams processing)
And we are talking about censorship of a trac 0.11dev custom-version-
developer. A custom version with localization support, plugin-bundles
(product-plugin) which run out of the svn, an fully functional but
simple side-navigation, and... everything deactivatable with a very
simple way, thus the original trac is there again.
http://dev.lazaridis.com/base
Open Source works like this: many many small human ego's need to be
fitted. There's no place for developers which could redesign the whole
thing within a few months. the trac-developers need to 'fight' with
tons of spaghetti. The developers plan like crazy, instead to merge
with a application framework like e.g. turbogears. Did you know that
trac has no support for... datetime fields? Yes, its true.
You may say: do it yourself. Of course I could do it, even without
touching the main sources (using dyna-patches or monkeypatches). But
that's not how open-source works. You implement thing for yourself and
contribute things back to the core-project - but with trac there's one
problem: no one get's the core anymore (apparently the initial
developer has left)
Of course I'll not stay with trac, I'll leave the sinking ship, I've
prepare long time ago to do so, step by step. An will migrate step by
step away from trac and python - toward an own implementation based
on...
perl and it's libraries.
Really, I don't understand the need for python. And after fighting
with some indenting within html templates, I dislike the whitespace-
syntax-thing of python again.
Do it in perl, if you need something more 'pretty', do it in ruby, if
you need something more 'serious' do it in java, if you have enough
brain and time, do it in C++ from bottom up.
Python and it's communities is excellent for learning. Not
programming, but to "learn from deficiency", community organization,
transparency, efficiency etc.!
-
So, keep your eyes on this project, if you want to be prepared to jump-
off the sinking ship "trac"
http://dev.lazaridis.com/base/
-
Party Time!
..
