Both look very promissing, but you know... we like roundcube because it's simple to install and maintain, simple to use, nice features and beautiful. And that's some work to be proud of. If we'd like a gmail clone we'd be using gmail instead. Yes gmail is the best e-mail ou there, but not only because of its interface but because of its service.

For me, choosing roundcube as webmail for a mail server is still the best thing to do. Roundcube needs a little more features and bug fixes to become perfect. Gmail is awesome, but it's something else.

It's moments like these that make me wish I'd could develop.

Regards,

Eden

On 12/20/06, Brennan Stehling brennan@offwhite.net wrote:

Thomas,

I am willing to give some of my time to organize project tasks. I am not a PHP developer (I know a little) but I do web development all the time so I know much of the technology involved, such as js, xhtml and css as well as the nuances of http and the application hosting environment. I could do the work to break down the incoming bug and feature requests into the various components and drop emails to the developers who may be able to claim and work on each ticket.

But I would like some help from other volunteers as I cannot do this 8 hours a day. Perhaps once the tasks are broken out by component we can make use of component team leaders who will coordinate efforts at that level.

I would ensure that tasks are broken out into 2 to 4 hour work units so that contributors can knock out some tickets in their spare time. I would like to make it possible for 30 contributors to contribute 2 hours of work a week instead of what is currently more likely less than 10 people contributing most of the work. I would rather have those 10 take on more of a mentor and code review role to better accelerate development. As we get interested contributors we can get them aligned with the component team leads and get them started.

As a part of the mentoring, we could make use of screencast recordings and tools like Skype/Unyte. These are all free tools.

http://www.debugmode.com/wink/ (screencast recording and editing) http://www.unyte.net/ (screen sharing) http://www.skype.com/ (IM and voice communications)

These tools will help the team leads put together the materials necessary to have the team members communicate with each other when we are working on a visual interface like RC. The Wink recorder can also be used to document a UI bug so that the developers can see what is happening so they can more readily correct it.

The team leads can also record a walk through for their component at the start of each major cycle to show the developers on that team the current architecture and explain the coming feature enhancements and strategies for making the necessary changes.

Brennan (www.smallsharptools.com)

On Wed, 20 Dec 2006 22:30:50 +0100, Thomas Bruederli roundcube@gmail.com wrote:

...

Hi everybody,

Looks like the others are getting closer:

Gmail like AJAX powered Web 2.0 version of IMP http://janschneider.de/news/25/252

Duroty System (BETA) is the open source Gmail http://www.duroty.com/en/index.jsp

The main problem of RoundCube is the project manager's lack of time and as a consequence of that the bad project organization, both my faults. If somebody thinks he or she could afford some time (actually it's a full-time job) and who has some experience in project management, I'm willing to give away the "power" and become a regular developer (that's what I really am).

Regards, Thomas

-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net

Jim,

You can learn more about the ticket reports here...

http://trac.roundcube.net./trac.cgi/wiki/TracReports

You can see how to add new queries. You can also set the priority and severity as well as associating it with a milestone. Among those 3 pivot points there is a good deal of planning we can do. I think the voting idea would work but we can simply put up a vote on specific issues occasionally. On Apache projects they do it simply by posting an email to the list and letting everyone vote on each item. The team lead keeps track of it and adjust the priorities based on the results. That way it stays within the team.

I do like the idea of a few test environments. I think we can do it all on the same server. It just needs a separate website per install with a separate db for each one. I have a FreeBSD server and could set up a test environment. Perhaps you could help me with an automatic provisioning system to deploy updates daily or weekly and automate some tests using Selenium. Dropping the db and rebuilding it with the latest update, generating a series of test emails and loading up the Selenium tests would not be all that difficult. And that does not require programming experience, but with your SA background you would know what to do.

What I do not know yet is how to run the Selenium scripts on a server like FreeBSD or Linux. I suppose I could have a job run on a Windows server which has FireFox and MSIE installed so it can run the Selenium scripts. Of course someone could start the Selenium tests manually.

But I also do not have time till mid January.

Brennan

On Wed, 20 Dec 2006 20:17:59 -0500, Jim Pingle lists@pingle.org wrote:

Thomas Bruederli wrote:

...

Looks like the others are getting closer:

Gmail like AJAX powered Web 2.0 version of IMP http://janschneider.de/news/25/252

Duroty System (BETA) is the open source Gmail http://www.duroty.com/en/index.jsp

They may be getting closer, but they'll never be RoundCube. :)

...

The main problem of RoundCube is the project manager's lack of time and as a consequence of that the bad project organization, both my faults. If somebody thinks he or she could afford some time (actually it's a full-time job) and who has some experience in project management, I'm willing to give away the "power" and become a regular developer (that's what I really am).

I've been trying to contribute time where I can, checking the trouble tickets for dupes, tickets that should have been closed long ago, and trying to get more information out of the people who opened the tickets. (Not to mention while doing that I have run across a few other bugs.) The less duplicate/invalid tickets that are out there, the easier the job is for the developers.

On occasion, I get into coding a bit. Unfortunately, getting enough free time to get that far into a project is rare during this time of year. I had a course in college on project management (I have a BS in Information Systems), but in my day job I am a sysadmin at an ISP and to a lesser degree a developer. I could help a little with project management, but not enough to take on the whole thing. I can probably help contribute more in some other areas, though.

My boss loves RoundCube and so does every user I've let try it. Due to that, I *might* be able to provide some sandbox setups for testing different IMAP server/OS combinations if people think it's worth it and my boss approves. Hardware isn't a problem.

I also do a bit of tech writing. If there are areas of documentation that anyone thinks could use some work, I'd be happy to help out there, too.

I think it would be a big help if the ticket system was used more effectively. An unfortunate limitation of Trac (or my knowledge of it) is that it doesn't allow you to order the tickets by their last update. The timeline is nice, but tickets can sort of get lost if they're not checked periodically. I have been "babysitting" a few tickets to see if anyone responds to them. If I update a ticket a year after someone opens it, odds are they aren't going to be responding soon with more information.

Also, it would be nice if there were some sort of a rating/grading on the tickets (Though I suppose this more of an issue for the people who make Trac...). Something to the effect of voting for a ticket, or a button someone can push to say "me too" without having to actually post to the ticket. If enough people vote, it might get nudged higher in priority.

Also, the tickets are listed by priority, but is it documented anywhere if 1 is the highest (as in most important) priority or 10?

Let me know if you need anything,

Jim

Jim,

I would not be concerned with testing multiple versions of Apache, PHP or MySQL with RC. I think most bugs we will encounter will be related to coding errors which will work universally the same in various hosting combinations. The same goes for browsers to a lesser degree. I would expect that the developers working on the project are already skillful enough to avoid the browser-specific problems that are well known at this point. That said, I think testing FireFox and MSIE on Windows will cover a vast majority of user environments. It would be nice to test Opera and Safari, but in my experience those browsers track pretty well with features in FireFox, such as a very similar AJAX system. When I develop something advanced with Javascript I do it test it FireFox during development and when I am wrapping it up I test it on Safari and very infrequently have a problem. And most of the time it is an easy fix.

As sending out test messages for the automatically updated RC installs, you could just use the mail command on Linux/FreeBSD server. It is something like...

cat message1.txt | mail -t person@here.com

The text file just has the contents of an email message including the mail headers. I would expect we can set it up to do attachments as well as add spam headers for that sort of testing. I think we just need to configure the mail server to bypass the spam filter so that we can set our own headers specifically for testing purposes.

As for RC versions, I would track the current development and the active branches. Right now I believe we do not have a major releases. I do not see specific releases under branches yet.

http://trac.roundcube.net./trac.cgi/browser/branches

Here is how I do releases...

http://svn.offwhite.net/trac/SmallSharpTools.ImageResizer/browser/branches

Once we get past the 0.1 release we can track 0.1 for a while until we have 0.2 and 0.1 goes inactive. So we just need 2 actively running test environments. However, if you want to try out multiple IMAP backends and databases I do see a reason to do that. There are significant differences between MySQL and Postgres and the various IMAP servers. That is where multiple servers could be useful. In the short term I would focus on the most actively used db and IMAP server and expand as the project grows. I think the testing of the IMAP and db communications could be done outside the confines of a full web deployment. Adding layers of functionality on top of these core integration points will make it harder to get at the root cause of a problem. If we can discover that RC has trouble talking to a specific db version before it goes out to the full RC setup than we will save a good deal of time and effort.

Brennan

On Wed, 20 Dec 2006 22:08:18 -0500, Jim Pingle lists@pingle.org wrote:

Brennan Stehling wrote:

...

You can learn more about the ticket reports here... http://trac.roundcube.net./trac.cgi/wiki/TracReports

...

I think the voting idea would work but we can simply put up a vote on

specific

...

issues occasionally. On Apache projects they do it simply by posting an

email

...

to the list and letting everyone vote on each item. The team lead keeps

track

...

of it and adjust the priorities based on the results. That way it stays

within

...

the team.

What I had in mind was to use the voting as a means to measure how much of the RoundCube user-base is affected by a given ticket. The periodic posting may work well for feature requests, but keeping the voting within the team doesn't necessarily help with checking how widespread a problem is with the users.

...

I do like the idea of a few test environments. I think we can do it all

on the

...

same server. It just needs a separate website per install with a

separate db

...

for each one.

One server may be enough, but some situations may require some odd configurations to make that work. I'd prefer to minimize the customization needed, and to keep it closer to a standard user install. It might be possible to do using jails or just multiple IPs. However, when you start talking about all of the configuration possibilities, obviously there would need to be limits as to just how far we'd have to go. Apache (1.3.x, 2.x), PHP (4.x, 5.x), MySQL (4.x, 5.x), Postgres, not to mention IMAP servers: Courier, Dovecot, etc, etc. It could get out of hand fast no matter how it is done. :) The most popular are the most important though (Apache 2, PHP 5, MySQL 4, etc)

...

I have a FreeBSD server and could set up a test environment.

I have quite a few active servers at work (~20), and a lot more sitting around collecting dust. Most of the ones collecting dust are at least dual CPU PIII-800s with a GB or two of ram. Not speed demons by today's standards, but for what needs done here it wouldn't have to be fast.

...

Perhaps you could help me with an automatic provisioning system to

deploy

...

updates daily or weekly and automate some tests using Selenium.

Dropping the db

...

and rebuilding it with the latest update, generating a series of test

emails and

...

loading up the Selenium tests would not be all that difficult. And that

does

...

not require programming experience, but with your SA background you

would know

...

what to do.

I haven't messed with Selenium at all, but getting the backends in place shouldn't be that hard. If you're just talking about getting a current SVN revision in a directory and wiping/reloading the DB, that's really easy.

The test e-mail would be a little tougher to do, but still not hard. Copying the messages into the right place is easy, but coming up with all of the test cases might be rough. There are a lot of test cases that will need to be considered (Plain vs HTML, MIME/base64, Attachments of all shapes and sizes and each of those cases from multiple clients.)

...

What I do not know yet is how to run the Selenium scripts on a server

like

...

FreeBSD or Linux. I suppose I could have a job run on a Windows server

which

...

has FireFox and MSIE installed so it can run the Selenium scripts. Of

course

...

someone could start the Selenium tests manually.

Because Selenium is a UI testing package, I'm not sure if there is a way to automate it on a remote box unless you have VNC access or something similar, because the tests run inside a browser. It might be best to have tests for all platforms, though I do not have access to any Mac hardware. (And either their page is out of date or their browser support is really lagging... Only Opera 8 and Firefox 1.5?)

...

But I also do not have time till mid January.

I'm not even sure when my schedule will clear up, but at this rate, probably early January. I still find time now and then to poke around the trouble tickets, I just wish I was more familiar with the code so I could jump in and help out more directly. Coding isn't a problem, it's knowing where to look and the how it all flows, which takes time to get into.

And of course you also have to consider the delicate balance where all of this extra testing and overhead stops being helpful and starts being a burden to developers. That's where making it quick, easy, and painless would really help. The last thing we'd want is to discourage someone from coding because they don't want to go through all the "trouble" of testing... (I'm as guilty of putting off testing because of that as anyone!)

Jim

I couldn't have said it any better - I totally agree. I like the way how roundcube is developing very much, we are making slow but steady progress.

If you think we need a "cleanup offensive" of the code or the ticket system, just call for it, maybe lay out some rules (like, which tickets to keep, delete or tag in which way) and I'll be happy to help out.

Or a drive to write up some more/revised documentation or vamp up the wiki - I'm sure that if you announced a major task, there will be enough people willing to help out.

Cheers, ~Mik

I am all for a scheduled push for contributors to meet online to work on the tickets for the next release. Perhaps we can schedule something for January for all of us to meet online using a IM client which supports a group chat. (Skype, GTalk, etc)

Thomas, you could walk us through your plans and each of us could volunteer to work on specific tickets. Perhaps after a few of these sessions we will be past the next release.

Brennan

On Thu, 21 Dec 2006 15:17:46 +0100, Michael Bueker m.bueker@berlin.de wrote:

I couldn't have said it any better - I totally agree. I like the way how roundcube is developing very much, we are making slow but steady progress.

If you think we need a "cleanup offensive" of the code or the ticket system, just call for it, maybe lay out some rules (like, which tickets to keep, delete or tag in which way) and I'll be happy to help out.

Or a drive to write up some more/revised documentation or vamp up the wiki

• I'm sure that if you announced a major task, there will be enough people

willing to help out.

Cheers, ~Mik

Tor Bendiksen wrote:

Kudos to you Thomas, and all the other developers for this. Fantastic stuff.

Ditto. Big Ditto.

This type of work can be left to the rest of us. I am certain that there are loads of people on the list that have both time and willingness to do these things. I am a sysadmin, and not a coder, so I can't really help out with javascript part. Perhaps I can help out with some php stuff at a push, but only when I need to. Therefore I would be much happier to help out with stuff I know. Be that helping out other users, doing documentation, or offering hardware/software/bandwidth or anything else that can help the project in any way. I am sure I am not the only one that is in the same boat here.

I'm in the just about the exact same position, cant help a whole lot w/ javascript, but php software/hardware/bandwidth, documention, testing, etc I'd love to help with and have a fair amount of time to do this in.

Keep up the great work!

-Ryan

-- Network Administrator Goshen College (574) 535-7004