Code fork

I don’t know if it has been noticeable at the mailing lists, but
anyway there have been some friction between Jesse and me. We have a
bit different coding style and different ways of seeing things. I’ve
always considered this to be an advantage, because the compromises we
land at often seems like better solutions than either of the
suggestions. Anyway, I guess Jesse is tired of arguing with me, and
it has eventually comen so far that a code fork is inevitable. I
really hadn’t believed this just a week ago… To quote Jesse:

  Your goals are fundamentally in conflict with the project's
  goals. Because of your short-term goals, the longterm
  maintainability and extensability of the codebase is suffering.
  I appreciate all the hard work you've put into RT over the past
  year or two, however, this has become an unresolvable conflict.

My first pri short term goal is to serve Funcom Support Department by
putting in whatever features they want to see in our local RT2 version
(or eventually telling them why the wanted feature is a bad idea). I
can understand that Jesse want to release a RT 2.0 without too much
“jingle&bells”, and that much of what we see as essential here at
Funcom doesn’t fit everywhere. However, most of those “doubious
features” are in the web templates, and can easily be removed.

My priority two “short term goal” is to get RT out to the people. I’d
really like to see a working beta before the 14th of August. Jesse
thinks that RT2 is absolutely not ready for production. Well, I can
agree to some extent - most users out there will probably either have
problems with the installation, or they will find that it lacks some
key features. BUT I have to stress that we actually do use it
extensively in the local production, and that we are quite satisfied
with it. I’m intending to move the last queues from RT1 during the
day! We’ve had no significant problems with RT2 so far - knock on
wood!

I’m deeply concerned with the slow development of RT2. All time
estimates have been successfully broken. I don’t know what plans
Jesse has for RT2, but it seems more and more to me like a one man
cathedral project than a baazar project, ref. Eric Raymond at
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ - I don’t blame
Jesse for beeing busy with other things than developing RT2, but it is
indeed slowing down the RT2 development considerably.

In my opinion there has been a crying demand for a successor/upgrade
of RT1 already since before the 1.0 release. RT2 is long overdue. Our
local RT1 version is very feature-rich compared to the official RT1
release - there is tons of enhancements. I’m not touching it unless I
really have to, not only because it’s an ugly hack collection, but
also because it has been a dead development path all since Jesse
suddently decided to skip the development of RT 1.1…

So, I have now set up a project at sourceforge for TwoRT� - The
Working Request Tracker. I guess it will be available during the day,
I will move all sources over to the CVS there. I also want to set up
a working demo instance somewhere; I’d appreciate it deeply if anybody
can assist me in finding a location outside a firewall where I can run
either fcgi (that’s just normal cgi, except that the perl binary has
to be statically linked with the fcgi-libraries) or mod_perl. I want
TwoRT to be self-hosting, all user requests and bug reports should be
stored in TwoRT.

Here is the major things that are missing from TwoRT (and also RT2):

1 Access control. Actually I can manage without for the moment. I
have no clue about how far Jesse has gotten with it. In the worst
case, I think I can handle that in two weeks if I work hard on it.

2 Keyword handling, a system that is to replace the areas. I’ll steal
a bit from Knowledge Base, a system Jesse has hacked together. It
will take me four days of intensive working to fix this.

3 Admin tools. Administration can be done in SQL, eventually it will
take me four days to hack together some simple web interface.

4 Ports to different database systems. That will hopefully be an easy
task, and I think the interessted parties can manage to do this
themselves.

5 Converting / Linking tool between RT1 and TwoRT.

Anything else?

RT2 and TwoRT will probably develop in a bit different directions. My
version will be more feature-rich, and probably the code will be a bit
more “hacky”. This will probably lead to higher complexity, more
bugs, slower code, less maintainability - anyway, I think the code is
so modular by now that those disadvantages can be kept to a minimum.
Just as a sidenote, our full-featured RT1-branch has never had
problems, except when my disk has been overflowing, and eventually
when my old version of mysql decided to do a lot of random things. I
will try to satisfy everybody, and if somebody have made some features
that there is some demand for, and which might be better to have in
the codebase than as add-on modules, then I will probably incorporate
that. I will give anyone that seems fit for it developer status in
the CVS.

Another thing, my experiences are geared towards support towards
external “clueless” “customers” rather than in-house technical
support. Naturally, I think my TwoRT will be more geared towards this
usage; while in-house technically aware requestors usually preffers to
get as much insight into RT and their request as possible, the average
external requestor should have a pleasant, warm feeling that he is
communicating directly and personally with the support personell.

RT is frequently beeing used for monitoring worktasks. I think it
sucks at it. I have started setting up a Project Management Tool
built on the top of RT … hem, TwoRT that is … :slight_smile: It’s of course
not a full-blooded Project Management Tool, but to say it this way
… the few features I’ve putted into it until now does indeed work,
and I am using them locally. I’m considering it to be a prototype
experiment, experience from this can be taken over to the fields of
Asset Tracking, Bug tracking, etc.

So, to be short:

  • If you’re completely happy with RT1, you shouldn’t care at all as
    for now.

  • If you’d like to wait until next year� for a perfect, stable RT2 that
    runs right out of the box, but might miss some of the fancy the
    features you want, you should definitively hang around for RT2.

  • If you’d like a feature-rich, easy customizable, easy hackable
    request tracker, and if you have the patience of setting up a system
    that most probably won’t run at the first try, you should
    definitively go for TwoRT.

  • If you would like any of those related products (Asset Tracker,
    Project Manager, etc), you should also have a look at TwoRT.

I will of course continue to monitor the development of RT2 and steal
whatever I find interessting from this project. I also think the
database schemas will be fairly compatible - if there will be changes,
I will probably provide a converting tool. I will also allow for
inter-instance linking between RT2 instances and TwoRT instances - as
far as it is in my power. I hate code forks, and I will eventually be
open for a merging in the future. Actually I think neither me nor
Jesse have what it takes to make the perfect RT2 alone.

� Just a suggestion. I don’t like it very well myself - I’m open for
better suggestions. I’ll also change it if Jesse finds it too
offensive :slight_smile:

� I hope I’m incorrect about this, but I do have a slight feeling it’s
going that way.

Tobias Brox, +47 22 925 871

Tobias,
I have to say that this saddens me quite a bit. I can’t claim to
be privy to the ins & outs of your working relationship with Jesse, but I
can tell you this – RT as it stands in its stable version is dependable,
reasonably full-featured, well-supported, and easy to use &
administer. Why would you want to break that by putting forth a version
that is (as you admit) hacky, not well supported, and a bear to install,
all in the name of getting the product out the door faster? It is thinking
like that which gave us the abominations like Windows 98 and XEmacs :wink:

To quote RMS (gratuitously), I would rather use stable, well-thought-out,
“Done-right-the-first-time” GNU tools than the more feature-rich,
bug-full, downright scandalous offerings of those who want to ship their
product ASAP and let the user base debug it for them. Forgive the
comparison, but I think it’s called for here.

I know from watching my own cadre of sysadmins and coders that conflict is
a good thing. We’ve sat and harangued eachother for hours on end over
policy, coding style, direction, and all manner of things. Generally, this
is the atmosphere that is most conducive to bringing out what each person
excels at the most, and funnelling bullshit down to the bottom of the
heap. Very seldom, provided all parties are mature, does it devolve into
poisonousness.

It is endemic to a software project that you will exceed your deadlines.
for the deadline is writing you a check. This is free software! If it’s
really important for an RT user to have a feature right now, and they
won’t let it go, offer to work tirelessly on it provided a small stipend
of some sort. I would rather pay you to hack on RT than pay the huge sums
that I would have to for a commercial product that I know isn’t bug-free.

As you said yourself:

Actually I think neither me nor
Jesse have what it takes to make the perfect RT2 alone.

If this is true, you should continue to hack on it together. It is my
opinion that software is best produced slowly and deliberately, not by
piling ugly hack upon ugly hack.

But again, I don’t know what goes on between you and Jesse. Perhaps there
are irreconcilable differences, and if true, a code fork would make me
quite sad.

~Dan D.
++ I feel the earth move.
++ I feel the tumbling down, the tumbling down.

Dan Debertin
Senior Systems Administrator
Bitstream Underground, LLC
airboss@bitstream.net

I have to say that this saddens me quite a bit.

Me too.

be privy to the ins & outs of your working relationship with Jesse, but I
can tell you this – RT as it stands in its stable version is dependable,
reasonably full-featured, well-supported, and easy to use &
administer.

Well, I’m quite surprised that so many actually is satisfied with RT1.
Anyway, I feel that I’m daily answering feature requests at the rt-users
mailinglist: “This is not feasible in RT1, but it exists in RT2”.

Why would you want to break that by putting forth a version
that is (as you admit) hacky, not well supported, and a bear to install,
all in the name of getting the product out the door faster? It is thinking
like that which gave us the abominations like Windows 98 and XEmacs :wink:

Have you read “The cathedral and the baazar”? The success of other beasts
like Linux depends greatly on the user community. For RT2, there is no
user community. My philosophy is that if a project actually is used, bugs
will be weeded out quicker, and it will be quicker to spot what concepts
is actually working and which one isn’t. The problem is that nobody
(except Jesse and me) is interessted in hacking on RT2 unless they can set
it to production today.

To quote RMS (gratuitously), I would rather use stable, well-thought-out,
“Done-right-the-first-time” GNU tools than the more feature-rich,
bug-full, downright scandalous offerings of those who want to ship their
product ASAP and let the user base debug it for them.

I’m greatly respecting RMS in many philosophic aspects - but I think he is
wrong about this one. One of the big advantage with the development
of free software is that the user base actually can and should do the
debugging. To qoute Linus, “all bugs are shallow, given enough eyes to
look at it”.

I know from watching my own cadre of sysadmins and coders that conflict is
a good thing.

Yes, it can be - it leads to healthy “coompetition”. Undoubtly, there
will be some leakages of features forth and back.

I would rather pay you to hack on RT than pay the huge sums
that I would have to for a commercial product that I know isn’t bug-free.

The annoying thing about commercial products is that you can’t do anything
with the bugs. With free software, you can and should.

If this is true, you should continue to hack on it together.

That’s not up to me anymore.

It is my
opinion that software is best produced slowly and deliberately, not by
piling ugly hack upon ugly hack.

I’m really prefering to improve a system that I can actually use, than to
build on a system that will be ready some time in the future. When using
a product, you know a bit better what have to be done, why and how.

Spell checkers are for wimps
(please send feedback on all typos)

I have to say that this saddens me quite a bit.

Me too.

And here’s another sad one.

[…] It is thinking like that which gave us the abominations like
Windows 98 and XEmacs :wink:

Have you read “The cathedral and the baazar”?

Of course!

The success of other beasts like Linux depends greatly on the user
community. For RT2, there is no user community. My philosophy is
that if a project actually is used, bugs will be weeded out quicker,
and it will be quicker to spot what concepts is actually working and
which one isn’t. The problem is that nobody (except Jesse and me) is
interessted in hacking on RT2 unless they can set it to production
today.

Appart from the fact that my personal opinion is that XEmacs is the better
branch I think with RT we could keep the same CVS repository. I mean are
there fundamental reasons to really split instead of making a branch,
and releasing it ASAP? This makes code transfers much easier than manual
merges. And looking ar the release numbers 1.0 and 2.0 I see lots of
empty space inbetween. Note that Linux also jumped to 0.93 or so to
indicate the approaching 1.0 final release. So how about 1.8—leaving
the step 1.9 as a last resort?

To quote RMS (gratuitously), I would rather use stable, well-thought-out,
“Done-right-the-first-time” GNU tools than the more feature-rich,

Do you know JWZ’s article “worse is better”?

bug-full, downright scandalous offerings of those who want to ship their
product ASAP and let the user base debug it for them.

I see no problem if that is clearly marked as e.g. in the even/odd
numbering scheme of the Linux kernels.

If this is true, you should continue to hack on it together.

That’s not up to me anymore.

Sorry if I’m poking to much into the feelings of you and Jesse but
is everything settled?

It is my
opinion that software is best produced slowly and deliberately, not by
piling ugly hack upon ugly hack.

I’m really prefering to improve a system that I can actually use, than to
build on a system that will be ready some time in the future. When using
a product, you know a bit better what have to be done, why and how.

We should leave something to do for RT 3.0 :slight_smile:

Regards, TSa.
±-------------------- Thomas Sandlaß, Orthogon GmbH ------------------+
| Vaihinger Str. 169, 70567 Stuttgart |
| E-Mail: Thomas.Sandlass@orthogon.de |
±-------- Tel: +49-711-78 19 60-26, Fax: +49-711-78 19 60-21 ---------+

ORTHOGON and ODS Toolbox are registered trademarks of Orthogon GmbH

Appart from the fact that my personal opinion is that XEmacs is the better
branch I think with RT we could keep the same CVS repository. I mean are
there fundamental reasons to really split instead of making a branch,
and releasing it ASAP?

Jesse suggested branching out a FunRT for Funcom … while I disapprove
that idea (anything truely local should be kept truely local, any really
doubious features should be kept in the contrib dir, and I really have bad
experiences with the old FunRT branch), having a feature-rich work-now
branch might work out a little bit better than a complete fork. I’d say
“aye” to this option. Though, I’m a bit concerned that the current CVS
already is a bit stretched concerning branching … anyway, six numbered
revision codes are merely ugly. Jesse, what do you think?

One advantage with forking it to sourceforge is that it will be easy to
add developers to the project. I think it’s greatly time preserving to
have people contribute directly to the CVS instead of submitting a patch
that might already be outdated before anyone have the time to look through
it. Of course it’s dangerous to open it completely, but I don’t think
it’s that hard to track what’s happening in the CVS, weed out new bugs as
they come in, and eventually stop up a bit and have a major design
discussion when somebody does something rather odd to the CVS.

Anyway, I’m quite quick at incorporating patches.

Note that Linux also jumped to 0.93 or so to
indicate the approaching 1.0 final release. So how about 1.8—leaving
the step 1.9 as a last resort?

That might work. Actually I think it’s a good idea. Though I’d rather
like to see the version number 2.1 for my branch :slight_smile: As I feel it, RT 1.1
was also “almost ready” before RT 1.0 was official.

To quote RMS (gratuitously), I would rather use stable, well-thought-out,
“Done-right-the-first-time” GNU tools than the more feature-rich,

Do you know JWZ’s article “worse is better”?

Yeah, but I dislike it :wink:

bug-full, downright scandalous offerings of those who want to ship their
product ASAP and let the user base debug it for them.

I see no problem if that is clearly marked as e.g. in the even/odd
numbering scheme of the Linux kernels.

Clearly.

If this is true, you should continue to hack on it together.

That’s not up to me anymore.

Sorry if I’m poking to much into the feelings of you and Jesse but
is everything settled?

Maybe I’m a little bit bitter of beeing cutted off and asked to leave, but
anyway I think we can communicate rather freely.

Spell checkers are for wimps
(please send feedback on all typos)

|> I have to say that this saddens me quite a bit.
|
|Me too.

Yes, I don’t think this split is going to be very good for rt.
Both Tobias and Jesse add such different things to the product.

|Well, I’m quite surprised that so many actually is satisfied with RT1.
|Anyway, I feel that I’m daily answering feature requests at the rt-users
|mailinglist: “This is not feasible in RT1, but it exists in RT2”.

Actually, there are plenty of features I’d like to add to rt 1,
but it is still a great product.

|Have you read “The cathedral and the baazar”? The success of other beasts
|like Linux depends greatly on the user community. For RT2, there is no
|user community. My philosophy is that if a project actually is used, bugs
|will be weeded out quicker, and it will be quicker to spot what concepts
|is actually working and which one isn’t. The problem is that nobody
|(except Jesse and me) is interessted in hacking on RT2 unless they can set
|it to production today.

Come now, it isn’t as bad as all that. :wink: I’m interested in
hacking on rt 2, though I’m hampered by various outside
influences which slow me down. Other people occasionally hack on
the product. Partly the problem is that the user community –
people who staff help desks – are not always people with tons of
programming experience. The cleaner code jesse is advocating
will make it easier for people with less programming experience
to hack rt.

in any case, is there any way for the two of you to reconcile
your differences? For example, have Tobias work the 1.9 branch
which adds features, and Jesse work the 2.X branch which adds the
new code base. Or whatever numbering scheme works for you guys.
But this seems like something that will hurt us, the rt users, so
I’d selfishly like to ask y’all to do the hard work of learning
to work together again so I can benefit.

-deborah

My reply to deborah kaplan’s mail was:

|> I have to say that this saddens me quite a bit.
|
|Me too.

Yes, I don’t think this split is going to be very good for rt.
Both Tobias and Jesse add such different things to the product.

Greetings,

Tobix, on the other hand, is responsible for customizing
and maintaining rt at FunCom, and has dedicated countless hours
of his time to the project, in all areas. He is a practical,
hardworking person with a job to do and internal deadlines to meet,
promises to keep.

I often have a feeling that Jesse is the software developer that actually
designs and makes RT … while I’m the person that makes it work :slight_smile:

I guess that, due to the massive protests, Jesse and me will probably try
to find a better solution to this - branching instead of forking, that is.

Spell checkers are for wimps
(please send feedback on all typos)

I guess that, due to the massive protests, Jesse and me will probably try
to find a better solution to this - branching instead of forking, that is.

This sounds a far more sensible idea.

Regards
Jan Pompe
e-mail janp@aurema.com
Aurema P/L http://www.aurema.com/
79 Myrtle Street, Chippendale NSW 2008. Tel: 9698 2322