Robert Burrell Donkin írta:
1. i know that quite a lot of the IMAP/mailbox stuff is junk (both
mine code and the old stuff). IMAP/mailbox is most of trunk. so yes, a
substantial quantity of code in trunk is junk. a more important issue
is that it's difficult to gain consensus on the production quality of
the remaining code on trunk or make rational judgments about what's
basically sound but needs testing in production. i've only reviewed a
small proportion and some looks ok, some looks questionable but i'm
not enough of an expert to judge.
2. i want people to innovate on trunk rather than on their own
branches. innovating on branches is harmful to the community since
it's much harder to collaborate and entropy makes it difficult to
merge changes into trunk. we need to allow new ideas and we need to
allow it on trunk. IMHO modularisation is an inevitable consequence of
this approach. noel prefers to see this process as allowing anyone to
dump junk in trunk and i have no probably about that language but
that's not the way i see things.
- robert
First of all, I don't want to take your time, so this will be my last
post in this subject.
I feel the workflow above would require development capacity which is
rarely available in the James project.
Somebody must have the authority and long term commitment to decide what
can be used from the playing ground trunk and extract those and create a
production quality version himself. Unfortunately, because it is a
playing ground, nobody trusts in trunk. By consequence it is not used on
many production like servers. Therefore nobody has reliable information
about what is useable in trunk. Moreover, even committers don't develop
against trunk, because they cannot use the result on their production
machines. The function of this developer is more like a paying job and
not like the ad-hoc volunteer work, which is avalible for James.
Regarding modularized code, I had a glance at the trunk, it was nice and
easy to understand. But if you have 20 smaller playing grounds instead
of one larger playing ground that doesn't really help on the trust
problem above. Actually, if the modules indeed start to be developed
independently - but they will never be completely independent - then you
get a new, difficult task: coordinate the release of 20 modules at the
same time.
It seems that while the goal was to avoid innovation in long-term
branches, the current approach lead to the exactly opposite result:
everybody has his own long-term custom build. I haven't seen any change
which make the result different next time.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
