On Mon, Apr 28, 2008 at 7:21 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > > > > On Mon, Apr 28, 2008 at 1:20 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > > > > > > This make sense, BUT, who will be interested in releasing trunk after > IMAP > > > is removed? > > > > > > > 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... > 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. > > 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 > 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. > > 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. 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. 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
