On Thu, Apr 17, 2008 at 2:23 PM, Hontvari Jozsef <[EMAIL PROTECTED]> wrote: > > > 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.
post as much as you want: feedback's good > 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. one of the community issues facing JAMES is that almost every developer has different interests. production means fit to run live on the internet. some developers run production servers, others are more interested in intranet ready solutions. JAMES serves on my intranet. trunk is fine for me. > 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. i intentionally propose not to coordinate component releases: let components be released when they are ready. release early, release often. > 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. long terms branches are a community issue for me. sharing our code and ideas more intimately will help to bring the community together. i'm not bothered about code people choose to use for their main mail server. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
