On 4/28/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > On Mon, Apr 28, 2008 at 7:21 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> Robert Burrell Donkin ha scritto: > >>> who's interested in releasing IMAP? not me, for one. i can live very > >>> happily enough without any releases for the forseeable future. > >>> releases attract users, not developers. > >>> > >> True. Just take into consideration that many JAMES developers knew JAMES > as > >> users and then decided to start hacking the code. > >> 1) Releases attract users that could be future developers > >> 2) Releases give some developers motivations/satisfaction to keep > working. > > > > i don't have the energy to cope with users. even developers are > > difficult since the codebase is in flux... > > Even if I lost my motivation in coping with the PMC I think I'm still > doing user support as much as possible. Yes, I reduced my activity there > too, but I try to keep running with users as I think they are the only > key for JAMES issues: we need new users, new developers, a new community > driven by new smart people. Since I joined james (2005) I replied almost > an average of 1 message per day on james-user. This does not catch up > with user questions, but this is A LOT. Norman also helped in the last > years. Danny, Serge and expecially Noel worked very hard on the > james-user list in the previous years. Unfortunately I guess both the > users community and the developers community has been reduced since > 2002-2003 by a 5 factor.
I was just talking about my motivation. I understand other developers feel differently. I am interested in helping the JAMES community heal itself but do not share all the same goals. > > >> I, for one, started as an user of the 2.1 and then 2.2 and then I've had > to > >> fix/change a lot of code and decided to try to be a developer, I'm very > >> happy for 2.3.0, and then I stopped because I had no enough > >> energy/motivation to make another release like that one and I see no way > to > >> release again. But this is me. And this is past. > > > > i don't have the energy to do everything. i can see a route towards > > new JAMES releases involving considerable code from trunk if not trunk > > itself. i just can't see any chance of releasing trunk at all. but if > > no one else who wants releases has energy to contribute then i'm not > > going waste my time. > > I would +1 any attempt to branch or release milestones from trunk even > tomorrow. I would test the resulting milestone, I would report bugs, I > would *probably* report patches, too. But I won't push this, as I've > been accused to push things and I'll wait for others to push now :-) > I hope you get me as an "opinionist" and not as a contender: I really > admire your work and your motivation (I've been there) and I hope you > understand that in practice I will rarely use my -1, but I now like to > scream as loud as I can because most of our PMC tends to sleep, and I > want them to hear and take reasoned decisions ;-) Inappropriate inaction is as bad as inappropriate action > > >>> IMAP is orthogonal to the community issues surrounding trunk. IMAP is > >>> not tightly coupled to the rest of JAMES. if the community issues > >>> remain unresolved when IMAP is ready for release, the easiest approach > >>> would be to backport to a uncontroversial version. > >>> > >>> the only way that trunk is going to get released is if someone steps > >> forward > >> I agree. What I didn't agree is that removing IMAP is a step forward and > >> that this is a community opinion. > > > > i never said removing IMAP is the majority opinion: it's bound to be > unpopular > > You are right, I made a conclusion based on a couple of sentences and > maybe I was wrong. > I told: > "IMHO there is no shame in releasing code marked as unstable together > with stable code. We introduced modules also for this, didn't we?" and > you replied: > "yes but IMHO that's not an opinion shared by the majority of those > with binding VOTEs." > > If I understood this was what made you decide to start removing IMAP, > but maybe I misunderstood. > I just want to tell you "please check that someone else in the PMC, in > addition to Noel, thinks that releasing unstable modules from trunk is a > shame", because I only count him from my mailing list archive lookups, > and I really hope we don't still count Noel as the majority ;-) > > I could accept to give *yours* idea (as active developers against > speak-only people, including me) the power of majority, but not Noel's ;-) > Please try not to dredge in the distant past. The problem is that the passive majority have no ability to review the changes made. So there is no prospect of releasing trunk without Noel's active support. > >> But I already said that I trust you on > >> this. I will not -1 this. > >> If this is needed then let's make another "top level" project, > >> svn/james/imapserver (with no weird trees, please ;-) ), or let's push > back > >> to sandbox (I would hate this, but if THE COMMUNITY think it is better, I > >> will not vote down this too). > > > > JAMES suffers from everyone doing anything interesting in the sandbox. > > this is bad. the reasoning behind the modular build is that anyone > > should be able to try new stuff without having to fork JAMES. that's > > now easy in trunk. > > ATM JAMES suffers from everyone doing nothing :-( > The sandbox ERA is already past.. it lasted few months... > As I said I would hate moving IMAP to sandbox. It was simply a statement > to tell you what I would "accept" without a -1. If I understood it > correctly you was fine with keeping IMAP in trunk or moving it to > svn/james/imapserver, am I wrong? (I just didn't like the > svn/james/server/imapserver solution, but I hope this is a minor > technical detail) Just a detail > > >>> i think that the lack of releases is unhealthy for the community. i > >>> also understand that many developers feel frustrated. i see no reasons > >>> why JAMES couldn't release a couple of components a month for the next > >>> year or so provided that the people who want more releases step > >>> forward. > >>> > >> I think you understand that when this community try for real and > concretely > >> to release something I always try to help someway (site stuff, release > >> tests, maven issues). Just don't ask me to push things. I gave up with > >> pushing :-) . I will join when I see something I consider concrete and > >> realistic. > > > > if no one's willing to push forward releases then they aren't going to > > happen. previously, you were pushing against too many in the community > > to have a realistic chance of success. the art is to approach from a > > different perspective. > > Have you understood WHO was against and WHY? I'm still waiting to > understand why and to get counterproposal or to get some "sorry, I was > wrong, please try again now". Sometimes it is good to read again that > old messages. Read the motivations.. people was scared because they need > some more months to complete their work... I guess they had their months > now, maybe now everything is ok to release ;-) > I still hope you will try to push, because if you don't do this, no one > else will do now. I don't expect anymore the community that complained > me and Norman at the end of 2006 to get a better solution to our > proposal (I checked my spam folder and is not there ;-) ). It's not my fight. I have too much code I need to write both in JAMES and elsewhere. > > > i think releasing mailet-api, mailet-base, std-mailet and crypto-mail > > in the next month is not unrealistic if someone else were to step > > forward to act as release manager so we can spread the load. we will > > then have started to release the 3.0 code base in a way that allow > > it's encorporation within the 2.x codebase. > > I will not do the release manager, but I can try helping with mailets > and coping with dependencies and code analysis as I did in the original > message identifying what mailets/matchers can be moved or not and why. That is useful. How about coming up with some solutions for the rest? Also, IIRC you also produced a list of new features in trunk. I wonder whether you could work out which could be delivered as library extensions. > > there is a lot of interest in lightweight, embeddable protocol > > handling libraries. one way to reassemble JAMES would be to extract > > our popular protocol into separate products. we then build the > > headline JAMES server from loosely coupled components with separate > > versioning. the more i look at the codebase, the more i think that if > > only avalon were not so intrusive this would be a realistic > > possibility. this would allow SMTP to be released when it were ready > > and arguments about that protocol to be restricted just to that > > codebase. it would also allow JAMES components to be easily reused in > > other projects (there are several who would be interested if only > > JAMES were not so monolithic). > > > > - robert > > I don't consider JAMES a so big monolithic application. IMHO JAMES has a > small-medium codebase. I'm used to work on much larger source trees and > I don't feel this need to break things apart (but I guess you already > got t JAMES is too monolithic to work well as an open source project with only volunteer developers. Commercial trees are much bigger but they are organized differently. Big, monolithic codebases prevents code sharing and is a major barrier to new developers who are interested only in a limited feature set. Open source projects work best when they are bushy: a small kernel plus modules. > That said I'm working on avalon free, seda based, protocols libraries > outside ASF/JAMES so I really agree on the rest of your sentence. > > The more we talk, the more I think you're simply late (wrt JAMES > involvement) and that if you was here 2 years ago we would have james > *4.0* out now! Not sure. Increasingly I think most of the improvements made in trunk could be added as pluggable extensions to the 2.x codebase. > > Stefano > > PS: OK, I realize I should not consume so much of your time. My "bar > discussions" are not concrete steps to release. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
