What I could see so far since reading mails of this list is that there are a lot of bugs found by all of us and a lot of bug fixes are also shared through this list and last but not least the developers are really trying to fix (following their priorities) all those things quickly. I like this webmail client and I think it has a very good potential to start a small revolution within the open source webmail area. What I also see is that, there is still a long way to go to reach "stable" status, but forgive me if I am wrong: All of us want to see this product getting there as soon as possible due to lack of good (and more important nice looking) alternatives.
As I am not a very experienced software developer, especially when it comes to DHTML, I am unfortunatly not able to contribute in that way. What I and for many other _users_ could do is testing, reporting bugs and verifying bugfixes in a proper way.
I would suggest to create some fixed test procedures with corresponding check lists, which every release should be tested against.
Some examples:
I think, if we create a "things to be tested" catalogue, which every _user_ could follow and check things which passed or not passed and do good reporting to developers afterwards, will make live easier for all users (administrators) adn especially for the developers (saving valuable time).
If you wish I could assist / support you (the developers) with creating and more important maintaining such a catalogue and even could do some controlling.
Let me know your thaughts about this issue.
Regards,
Robert
As I didn't receive any feedback, I am sending this one again to the mailing list and I would really like someone posting comment/criticism or what ever else on this topic.
Regards,
Robert
On Sat, 22 Oct 2005 14:24:46 +0200, Robert Landes r.landes@clixel.net wrote:
What I could see so far since reading mails of this list is that there are a lot of bugs found by all of us and a lot of bug fixes are also shared through this list and last but not least the developers are really trying to fix (following their priorities) all those things quickly. I like this webmail client and I think it has a very good potential to start a small revolution within the open source webmail area. What I also see is that, there is still a long way to go to reach "stable" status, but forgive me if I am wrong: All of us want to see this product getting there as soon as possible due to lack of good (and more important nice looking) alternatives.
As I am not a very experienced software developer, especially when it comes to DHTML, I am unfortunatly not able to contribute in that way. What I and for many other _users_ could do is testing, reporting bugs and verifying bugfixes in a proper way.
I would suggest to create some fixed test procedures with corresponding check lists, which every release should be tested against.
Some examples:
- Sending / receiving mails with attachements (zip, rar, 7zip, ace, jpeg,
gif, etc) 2) Front-end functionality (very important to have fixed test prodcure here i.e. testing all things, which can be done with front-end, this should also be done with all major browsers following a defined priority) 3) Back-end functionality (testing on different platforms and IMAP servers i.e. deleting, moving mails, status unread / read mails ...)
I think, if we create a "things to be tested" catalogue, which every _user_ could follow and check things which passed or not passed and do good reporting to developers afterwards, will make live easier for all users (administrators) adn especially for the developers (saving valuable time).
If you wish I could assist / support you (the developers) with creating and more important maintaining such a catalogue and even could do some controlling.
Let me know your thaughts about this issue.
Regards,
Robert
Hi Robert,
Please be patient when expecting answers to your postings. Not everybody can afford to read and post to the mailing list all day long.
I like your idea with the "release test procedure" and that's what I usually do when updating any productive systems. I have my couple of testes I usually do before releasing RC but because these releases are just alpha-builds, that list is not very long. There are also some issues that I can't test on my environment because I don't have several IMAP servers and databases installed to test them all.
We're currently working on a new wiki-based website which would then provide enough space to publish and edit such a testing list. I will keep this in mind and will set it up once the wiki is ready.
Regards, Thomas
Robert Landes wrote:
What I could see so far since reading mails of this list is that there are a lot of bugs found by all of us and a lot of bug fixes are also shared through this list and last but not least the developers are really trying to fix (following their priorities) all those things quickly. I like this webmail client and I think it has a very good potential to start a small revolution within the open source webmail area. What I also see is that, there is still a long way to go to reach "stable" status, but forgive me if I am wrong: All of us want to see this product getting there as soon as possible due to lack of good (and more important nice looking) alternatives.
As I am not a very experienced software developer, especially when it comes to DHTML, I am unfortunatly not able to contribute in that way. What I and for many other _users_ could do is testing, reporting bugs and verifying bugfixes in a proper way.
I would suggest to create some fixed test procedures with corresponding check lists, which every release should be tested against.
Some examples:
- Sending / receiving mails with attachements (zip, rar, 7zip, ace, jpeg, gif, etc)
- Front-end functionality (very important to have fixed test prodcure here i.e. testing all things, which can be done with front-end, this should also be done with all major browsers following a defined priority)
- Back-end functionality (testing on different platforms and IMAP servers i.e. deleting, moving mails, status unread / read mails ...)
I think, if we create a "things to be tested" catalogue, which every _user_ could follow and check things which passed or not passed and do good reporting to developers afterwards, will make live easier for all users (administrators) adn especially for the developers (saving valuable time).
If you wish I could assist / support you (the developers) with creating and more important maintaining such a catalogue and even could do some controlling.
Let me know your thaughts about this issue.
Regards,
Robert