Hi,
does anyone know where Timo is around lately? I haven't seen a post from him for some weeks now and "normally" Timo is quite active when it comes to supporting his 'dovecot' warp drive :-)
Udo Rader
-- bestsolution.at EDV Systemhaus GmbH http://www.bestsolution.at
He's made a few CVS commits in last couple of weeks, including a start on a new mailbox format called "dbox". If you're not on the CVS mailing list, look at http://www.dovecot.org/nightly/ChangeLog
He seems to go through his Dovecot "Inbox" once every few weeks answering all our questions ;) but it's been a while!
He's also been active on the IRSSI2 project http://dovecot.org/cgi-bin/viewcvs.cgi/irssi2/ChangeLog?rev=HEAD&view=auto
Chris
Udo Rader wrote:
Hi,
does anyone know where Timo is around lately? I haven't seen a post from him for some weeks now and "normally" Timo is quite active when it comes to supporting his 'dovecot' warp drive :-)
Udo Rader
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
----- Original Message ----- From: "Chris Wakelin" c.d.wakelin@reading.ac.uk To: "Udo Rader" udo.rader@bestsolution.at Cc: dovecot@dovecot.org Sent: Tuesday, November 29, 2005 1:07 PM Subject: Re: [Dovecot] Is Timo OK?
He's made a few CVS commits in last couple of weeks, including a start on a new mailbox format called "dbox". If you're not on the CVS mailing list, look at http://www.dovecot.org/nightly/ChangeLog
He seems to go through his Dovecot "Inbox" once every few weeks answering all our questions ;) but it's been a while!
He's also been active on the IRSSI2 project http://dovecot.org/cgi-bin/viewcvs.cgi/irssi2/ChangeLog?rev=HEAD&view=auto
Chris <snip>
I had wondered where Timo was (he usually reply's very prompt).
I have posted 2 requests for help re lock files on mbox but nobody has replied.
3rd time of posting
FC3 and dovecot1.0 stable using mbox files under /var/spool/mail/username where username is the mbox file.
I have 1 user who has a lock file username.lock
Why does this happen and how do i remove the lock so the mails held in the queue get delivered to the mbox
Please Please help or point me in the right direction.
Mark
On Tue, 2005-11-29 at 15:26 +0000, Obantec Support wrote:
I had wondered where Timo was (he usually reply's very prompt).
I have posted 2 requests for help re lock files on mbox but nobody has replied.
3rd time of posting
I didn't realize that the paid support from ProConsult was available already. I guess I must have missed it. But oh well, I'm not a supporter...
On 29.11.2005, at 22:45, Mark Rosenstand wrote:
I didn't realize that the paid support from ProConsult was available already. I guess I must have missed it. But oh well, I'm not a supporter...
Actually it looks like the support will come from Movial (www.movial.fi). Currently you can already buy development (although I'm probably too busy for next few months to take any more..)
On Tue, 2005-11-29 at 15:26 +0000, Obantec Support wrote: [...]
I had wondered where Timo was (he usually reply's very prompt).
I have posted 2 requests for help re lock files on mbox but nobody has replied.
Well, then nobody is interested in it. Or no one is available. Or Timo and all other usually helpful people are busy doing other things. Or there are lots of other possibilities.
3rd time of posting
Perhaps it helps, probably not since posting it two times didn't help ....
[...]
Please Please help or point me in the right direction.
There are lots of companies out there which can write you an offer since
according to the Fron: address - there should be sufficient budget somewhere to train the supproters or buy their next level of support.
Bernd
Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services
On 29.11.2005, at 15:18, Tomi Hakala wrote:
Udo Rader wrote:
does anyone know where Timo is around lately?
I had a meeting with him today, he's fine, just busy with school and his paying job.
Right. For a few weeks I had one deadline or another in every few days, and whenever I had some time left I just didn't have enough energy to read this list. Since there always are bug reports here I always have to spend a lot of time debugging etc..
On Fri, Dec 02, 2005 at 12:29:15PM +0200, Timo Sirainen wrote:
On 29.11.2005, at 15:18, Tomi Hakala wrote:
Udo Rader wrote:
does anyone know where Timo is around lately?
I had a meeting with him today, he's fine, just busy with school and his paying job.
Right. For a few weeks I had one deadline or another in every few days, and whenever I had some time left I just didn't have enough energy to read this list. Since there always are bug reports here I always have to spend a lot of time debugging etc..
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that?
Glenn
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that?
Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that.
So, would it be Bugzilla then? It seems to nowadays support PostgreSQL and it's kind of a standard everywhere. :)
On Tue, 2005-12-06 at 20:09 +0200, Timo Sirainen wrote:
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that?
Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that.
So, would it be Bugzilla then? It seems to nowadays support PostgreSQL and it's kind of a standard everywhere. :)
I don't know what exact requirements you have for a bugtracking system, but we would be willing to host the dovecot bugtracker on one of our hosts.
We are using mantis (http://www.mantisbt.org) extensively for our own projects (both open and closed source). It can be easily configured to interact with both CVS and SVN and we like the straightforward approach it offers.
Regards
Udo Rader
-- bestsolution.at EDV Systemhaus GmbH http://www.bestsolution.at
On Tue, Dec 06, 2005 at 08:09:09PM +0200, Timo Sirainen wrote:
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that?
Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that.
So, would it be Bugzilla then? It seems to nowadays support PostgreSQL and it's kind of a standard everywhere. :)
If that's what you're comfortable with, then that sounds great to me. I know that a lot of us are certainly experienced with *using* it.
Glenn
On Tue, 6 Dec 2005, Glenn Leavell wrote:
On Tue, Dec 06, 2005 at 08:09:09PM +0200, Timo Sirainen wrote:
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that? Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that. So, would it be Bugzilla then? It seems to nowadays support PostgreSQL and it's kind of a standard everywhere. :) If that's what you're comfortable with, then that sounds great to me. I know that a lot of us are certainly experienced with *using* it.
Please, no bugzilla. It's top-heavy and really cumbersome to use.
Mantis has a much better interface, and is much more straightforward to configure and use. Please save the database elitism for the linux-vs-freebsd and atari-vs-commodore flame lists where those discussions belong.
I've used and setup a _lot_ of different bugtrackers extensively and mantis sucks the least. And I have used some which _really_ suck.
-Dan
Mantis has a much better interface, and is much more straightforward to configure and use. Please save the database elitism for the linux-vs-freebsd and atari-vs-commodore flame lists where those discussions belong.
umm are you kidding?
mantis screen shot: http://linux.duke.edu/~skvidal/misc/mantis-screenshot.png
bugzilla screen shot: http://linux.duke.edu/~skvidal/misc/bugzilla-screenshot.png
trac screen shot: http://linux.duke.edu/~skvidal/misc/trac-screenshot.png
mantis is a pain in the arse to navigate, by far
-sv
On Tue, 6 Dec 2005, seth vidal wrote:
Mantis has a much better interface, and is much more straightforward to configure and use. Please save the database elitism for the linux-vs-freebsd and atari-vs-commodore flame lists where those discussions belong. umm are you kidding? mantis screen shot: http://linux.duke.edu/~skvidal/misc/mantis-screenshot.png bugzilla screen shot: http://linux.duke.edu/~skvidal/misc/bugzilla-screenshot.png trac screen shot: http://linux.duke.edu/~skvidal/misc/trac-screenshot.png mantis is a pain in the arse to navigate, by far
no seth, I am not kidding.
try _USING_ the freaking things. bugzilla is cumbersome (and this is well and widely known). it is also pretty freaking ugly.
http://bugs.mantisbt.org/view.php?id=6254 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24004
http://bugs.mantisbt.org/view_all_bug_page.php http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&bug_status=UNCONFIRMED
when you have a lot of bugs upen and juggling a lot of bugs simultaneously (not uncommon for a development session), mantis is a lot easier and more convenient to use than bugzilla.
please, please. anything _EXCEPT_ bugzilla. the "zilla" part of the name does very aptly fit.
no, mantis is not perfect. neither is trac. but they both suck less than bugzilla.
fwiw, svn is nicer than cvs too. svn warts and all.
-Dan
On Tue, 2005-12-06 at 13:22 -0800, Dan Hollis wrote:
On Tue, 6 Dec 2005, seth vidal wrote:
Mantis has a much better interface, and is much more straightforward to configure and use. Please save the database elitism for the linux-vs-freebsd and atari-vs-commodore flame lists where those discussions belong. umm are you kidding? mantis screen shot: http://linux.duke.edu/~skvidal/misc/mantis-screenshot.png bugzilla screen shot: http://linux.duke.edu/~skvidal/misc/bugzilla-screenshot.png trac screen shot: http://linux.duke.edu/~skvidal/misc/trac-screenshot.png mantis is a pain in the arse to navigate, by far
no seth, I am not kidding.
try _USING_ the freaking things. bugzilla is cumbersome (and this is well and widely known). it is also pretty freaking ugly.
I've used mantis unfortunately more than I'd like with centos and I find the interface confusing and cumbersome. Maybe with some interface design work it could be okay but it's excruciating as-is. Beyond that there is the pain that it is b/c it is php-based. I'm positive I'm not the only sysadmin here who cringes whenever asked for access to some other php application.
http://bugs.mantisbt.org/view.php?id=6254 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24004
the second one is much much easier to follow - less kludgy and confusing box colors to distract you from the content.
http://bugs.mantisbt.org/view_all_bug_page.php http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&bug_status=UNCONFIRMED
Same as above.
when you have a lot of bugs upen and juggling a lot of bugs simultaneously (not uncommon for a development session), mantis is a lot easier and more convenient to use than bugzilla.
It adds more whizbang things in the interface and makes it MORE confusing.
focus on lesscode and less confusion.
-sv
i guess we will have to agree to disagree seth. i've been using both mantis and bugzilla for about as long as both have existed, and i simply find bugzilla very cumbersome to use -- and i'm not the only one with this opinion of bugzilla. it is very common. surely it's not some huge secret conspiracy by the illuminati to defame bugzilla... is it? :)
i find mantis' interface streamlined in comparison, especially when juggling lots of bugs simultaneously. to you it's objections about eyecandy. well, you can edit mantis' css to make it equally an eyesore as bugzilla -- but why?
to me it's about efficiency and usability.
as for security issues -- both bugzilla and mantis have had vulnerabilities. bugzilla is not an automatic win simply because it's not php.
-Dan
On Tue, 6 Dec 2005, seth vidal wrote:
as for security issues -- both bugzilla and mantis have had vulnerabilities. bugzilla is not an automatic win simply because it's not php. all things that don't use php are a win.
as stated before, this elitism belongs on an linux-vs-freebsd list. by logical extension of your assertion, dovecot should be written in java. please, let's not go there.
-Dan
On Tue, 2005-12-06 at 14:12 -0800, Dan Hollis wrote:
On Tue, 6 Dec 2005, seth vidal wrote:
as for security issues -- both bugzilla and mantis have had vulnerabilities. bugzilla is not an automatic win simply because it's not php. all things that don't use php are a win.
as stated before, this elitism belongs on an linux-vs-freebsd list. by logical extension of your assertion, dovecot should be written in java. please, let's not go there.
umm, what the hell? It's not elitism. It has nothing to do with being elite or better. It has to do with picking languages based on their security history and development style. Php has a bad security history and a kinda scary development style. And I have no idea why you'd think I'd suggest anything EVER be written in java.
I'll gladly back the hell away from this conversation as you appear to have gone 'round the twist.
-sv
On Tue, Dec 06, 2005 at 12:34:56PM -0800, Dan Hollis wrote:
On Tue, 6 Dec 2005, Glenn Leavell wrote:
On Tue, Dec 06, 2005 at 08:09:09PM +0200, Timo Sirainen wrote:
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that? Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that. So, would it be Bugzilla then? It seems to nowadays support PostgreSQL and it's kind of a standard everywhere. :) If that's what you're comfortable with, then that sounds great to me. I know that a lot of us are certainly experienced with *using* it.
Please, no bugzilla. It's top-heavy and really cumbersome to use.
Mantis has a much better interface, and is much more straightforward to configure and use. Please save the database elitism for the linux-vs-freebsd and atari-vs-commodore flame lists where those discussions belong.
I've used and setup a _lot_ of different bugtrackers extensively and mantis sucks the least. And I have used some which _really_ suck.
I agree that Bugzilla can be cumbersome. But I'm most interested in there being *some* bug tracking system in place. If Timo is going to be managing the system, his preference will probably carry the most weight. That being said, it sounds like you've got a lot of experience in this area, and perhaps Timo would be wise to listen! After all, Dovecot is a great product, so we'll probably be using whatever system gets put in place for a long time to come.
Glenn
Am Dienstag, den 06.12.2005, 15:46 -0500 schrieb Glenn Leavell:
On Tue, Dec 06, 2005 at 12:34:56PM -0800, Dan Hollis wrote:
On Tue, 6 Dec 2005, Glenn Leavell wrote:
On Tue, Dec 06, 2005 at 08:09:09PM +0200, Timo Sirainen wrote:
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that? Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that. So, would it be Bugzilla then? It seems to nowadays support PostgreSQL and it's kind of a standard everywhere. :) If that's what you're comfortable with, then that sounds great to me. I know that a lot of us are certainly experienced with *using* it.
Please, no bugzilla. It's top-heavy and really cumbersome to use.
Mantis has a much better interface, and is much more straightforward to configure and use. Please save the database elitism for the linux-vs-freebsd and atari-vs-commodore flame lists where those discussions belong.
I've used and setup a _lot_ of different bugtrackers extensively and mantis sucks the least. And I have used some which _really_ suck.
I agree that Bugzilla can be cumbersome. But I'm most interested in there being *some* bug tracking system in place. If Timo is going to be managing the system, his preference will probably carry the most weight. That being said, it sounds like you've got a lot of experience in this area, and perhaps Timo would be wise to listen! After all, Dovecot is a great product, so we'll probably be using whatever system gets put in place for a long time to come.
You are absolutely right. Introducing a bugtracker is always a major decision and should be well considered (and I am glad that there is only one person in charge :-)
On point against trac (though it looks very nice and seems to be the "one tool for everything") is that it _is_ a tool for everything (integrated wiki, documentation manager, ...). It can complicate things a lot if the "everything" fails or breaks for whatever reason.
One of the major reasons why some time ago we chose not to use trac was the fact that it lacks finegrained access controls on bugs. Just go to the trac homepage, open the "issues" or "tickets" page and edit any bug you like (close it, fix it, whatever). If you have the right to add a comment on some bug, it implicitly means that you can also close/fix/... it.
Well, as you see, I have some "issues" with trac ;-)
Udo Rader
-- BestSolution.at EDV Systemhaus GmbH http://www.bestsolution.at
On Tue, Dec 06, 2005 at 08:09:09PM +0200, Timo Sirainen wrote:
Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that.
There is also RT, which is the standard in the Perl world; here's some screenshots:
http://www.bestpractical.com/rt/screenshots/3.0/and can use MySQL, PostgreSQL, *and* Oracle as a backend. There are pre-built packages for most distros:
http://wiki.bestpractical.com/index.cgi?InstallationGuidesand I would be happy to perform a custom install if so desired (I might even be able to act as a host).
However, I'd also like to throw in a good word for Subversion. Unlike CVS, Subversion handles renames and moves, which makes it very easy to reorganize a large project like dovecot. Subversion is much easier to mirror (using tools like SVK), so that other people can easily develop local patches for submission to the main development stream. SVK (a Perl-based front-end to Subversion) also handles automatic merging from branches (Subversion has better merging than CVS, too, but it isn't automated).
There is a standalone application, cvs2svn, which can convert a CVS repository (including tags and branches) into a Subversion repository, so no history would be lost. Again, I am happy to act as support for Subversion on the dovecot list.
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On Tue, 6 Dec 2005, John Peacock wrote:
Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that. There is also RT, which is the standard in the Perl world; here's some screenshots: http://www.bestpractical.com/rt/screenshots/3.0/ and can use MySQL, PostgreSQL, *and* Oracle as a backend. There are pre-built
On Tue, Dec 06, 2005 at 08:09:09PM +0200, Timo Sirainen wrote: packages for most distros: http://wiki.bestpractical.com/index.cgi?InstallationGuides and I would be happy to perform a custom install if so desired (I might even be able to act as a host).
Yeah, i'd much prefer RT to bugzilla. But if dovecot plans to ever switch to svn, trac might be a better choice.
-Dan
Dan Hollis wrote:
Yeah, i'd much prefer RT to bugzilla. But if dovecot plans to ever switch to svn, trac might be a better choice.
Jesse Vincent has already written an RT <=> SVN layer:
http://search.cpan.org/~jesse/RT-Integration-SVN-0.03/so there isn't anything that trac can do that RT can't do now or soon (there has been recent discussion on integrating KWiki with RT, or rather RTFM).
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On Tue, 6 Dec 2005, John Peacock wrote:
Dan Hollis wrote:
Yeah, i'd much prefer RT to bugzilla. But if dovecot plans to ever switch to svn, trac might be a better choice. Jesse Vincent has already written an RT <=> SVN layer: http://search.cpan.org/~jesse/RT-Integration-SVN-0.03/ so there isn't anything that trac can do that RT can't do now or soon (there has been recent discussion on integrating KWiki with RT, or rather RTFM).
code browser? changeset viewer?
not that you can't graft something on like svnweb, but it's nice to have it cleanly integrated.
anything except bugzilla :)
-Dan
--On Tuesday, December 06, 2005 5:03 PM -0800 Dan Hollis test3943395@anime.net wrote:
Yeah, i'd much prefer RT to bugzilla. But if dovecot plans to ever switch to svn, trac might be a better choice.
Did Trac ever add dependencies? I work on a project using Trac and I thought that was noticably missing. One can't make one bug depend on another, as one can do with Bugzilla, so one can't create a tracking bug hierarchy that enumerates all bugs that must be fixed to make a particular release.
I've used Mantis with the TeamSpeak project and Bugzilla for Red Hat, Mozilla, and SpamAssassin. So far the only advantages I saw in Trac were svn integration (no longer a discriminating factor) and an integrated wiki.
On Tue, 2005-12-06 at 19:23 -0500, John Peacock wrote:
On Tue, Dec 06, 2005 at 08:09:09PM +0200, Timo Sirainen wrote:
Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that.
There is also RT, which is the standard in the Perl world; here's some screenshots:
I've used RT quite a lot, but can it be actually useful for bug tracking? It seems to have been designed for some kind of support requests. Slightly different than bug tracking :)
However, I'd also like to throw in a good word for Subversion.
I've thought about skipping Subversion and instead using one of those distributed versioning systems, as soon as I can figure out which of them are here to stay..
GIT, Mercurial, Darcs or Bazaar-NG probably..
On Wed, 7 Dec 2005, Timo Sirainen wrote:
However, I'd also like to throw in a good word for Subversion. I've thought about skipping Subversion and instead using one of those distributed versioning systems, as soon as I can figure out which of
On Tue, 2005-12-06 at 19:23 -0500, John Peacock wrote: them are here to stay.. GIT, Mercurial, Darcs or Bazaar-NG probably..
The advantage of subversion is that if you know already cvs, it only takes about 30 seconds to learn subversion.
And svk already does distributed, if you really need that.
-Dan
Timo Sirainen wrote:
I've used RT quite a lot, but can it be actually useful for bug tracking? It seems to have been designed for some kind of support requests. Slightly different than bug tracking :)
rt.cpan.org seems to work fine for bug tracking (I just closed two this morning vs one of CPAN modules). The key is intelligently choosing the queues, so that you have some sane structure. It's probably best to see how the RT project itself handles their own bugs:
http://rt3.fsck.com/?user=guest&pass=guestI've thought about skipping Subversion and instead using one of those distributed versioning systems, as soon as I can figure out which of them are here to stay..
GIT, Mercurial, Darcs or Bazaar-NG probably..
I am not aware of the depth of the conversion tools from CVS to any of those (I see only Tailor, which was written for Darcs and can do conversions between the others), and I could make some comment about the lack of usage history behind all of those (they are all less than a year or two old). I can say that the team of programmers behind Subversion have borderline OCD (or over the border sometimes ;) so that the code quality is very high.
Philosophically speaking, Dovecot is basically one person - you - and so the utility of a fully distributed VCS is really questionable. Making it easier to have others mirror your code and provide patches is, as far as I am concerned, secondary to providing you with the tools you need to manage the project. I'd be happy to take this offline and set up a testbed for Subversion from a converted CVS repository so you could try it out.
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On Wed, 2005-12-07 at 08:04 -0500, John Peacock wrote:
I've thought about skipping Subversion and instead using one of those distributed versioning systems, as soon as I can figure out which of them are here to stay..
GIT, Mercurial, Darcs or Bazaar-NG probably..
I am not aware of the depth of the conversion tools from CVS to any of those (I see only Tailor, which was written for Darcs and can do conversions between the others), and I could make some comment about the lack of usage history behind all of those (they are all less than a year or two old).
That's pretty much why I haven't yet changed to anything. They're all pretty new and I can wait a bit more to see which ones will actually work.
Philosophically speaking, Dovecot is basically one person - you - and so the utility of a fully distributed VCS is really questionable. Making it easier to have others mirror your code and provide patches is, as far as I am concerned, secondary to providing you with the tools you need to manage the project.
I'm happy with using CVS, so the only reason why I'd want to switch to something else is if it benefits other potential developers. And since I'm not going to give direct commit access to anyone anytime soon, distributed versioning systems would be the best choice.
I'd be happy to take this offline and set up a testbed for Subversion from a converted CVS repository so you could try it out.
I use Subversion all the time at work. I haven't seen any practical benefits for it over CVS. Changesets are nice, but not important enough to bother with switching to SVN temporarily.
On Wed, 7 Dec 2005, Timo Sirainen wrote:
I've thought about skipping Subversion and instead using one of those distributed versioning systems, as soon as I can figure out which of them are here to stay..
GIT, Mercurial, Darcs or Bazaar-NG probably..
Btw, I've already set up an arch (bazaar) repository for the debian packages of dovecot. I'll gladly give you access if you like.
http://arch.debian.org/arch/pkg-dovecot/
-- Jaldhar H. Vyas jaldhar@debian.org La Salle Debain - http://www.braincells.com/debian/
On Tuesday 06 Dec 2005 18:09, Timo Sirainen wrote:
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that?
Still would be a good idea. Hmm.
Merits of various bug tracking systems besides (please not another Bugzilla), I think part of the issue is release cycle.
Not my job to tell Timo how to do his, but a lot of the responses to the list seem to be along the lines of "use the CVS version". Suggests to me that there is a need for more releases, or at least point releases, whenever new features have been integrate. The website has some daily builds, but they don't obviously encapsulate what the author(s) believe is working in that tar ball.
That said I use the Debian stable package of dovecot, which is based on ancient code (well a couple of years according to the Wiki), and haven't really experienced any issues, except with mbox, so maybe I underestimate how much effort Timo puts into producing/testing formal releases. Perhaps we should just stare blankly at the people using mbox with dovecot (in anger) and ask "why?" in a particularly disdainful tone of voice till the next full release.
Wietse tends to release postfix (either full releases for security fixes, or point development releases) with every significant bug fix. Alongside an accurate, and verbose change log this seems to work well. Sometimes the point release will have a fix for bug X, but only half of new feature Y, because it is a work in progress, but that is fine for people who really need to fix X, the fact that Y is in a mess doesn't matter if you don't use Y.
I have a horrible feeling I've suggested this before.
Whether on top of that Timo feels the need for more formal bug tracking, is another issue, but I'd be surprised if it had much relevance for the "average" end user. Looking at the few bugs recorded in Debian's bug tracking system against dovecot, they are primarily packaging related, or wishlist items, plus a couple related to more complex integrations of dovecot. i.e. for many Debian users (at least those experienced enough to report bugs through formal channels) Dovecot "just works".
On Wed, 2005-12-07 at 08:56 +0000, Simon Waters wrote:
Not my job to tell Timo how to do his, but a lot of the responses to the list seem to be along the lines of "use the CVS version". Suggests to me that there is a need for more releases, or at least point releases, whenever new features have been integrate.
I know. I would have already released alpha5, but I always fear a bit that my recent changes have broken something badly, so I decide to wait for a few more days.. and then I forgot it until I change things again, and then I again think I should wait a few more days..
But since this is still being alpha, maybe I should just go and release the new ones whenever something important gets fixed and just quickly get a new alpha released if something gets badly broken :)
Hmm. I think I'll do that now. It's only the LDAP code that might have broken.
Check Jira (www.atlassian.com). It's free for Open Source projects and we've been using it for quite some time now.
On 06/12/05, Timo Sirainen tss@iki.fi wrote:
On Fri, 2005-12-02 at 10:57 -0500, Glenn Leavell wrote:
Back in April, there was a little discussion about the possibility of using a bug tracking system for Dovecot (Bugzilla, Trac, and Mantis were mentioned). Do you think it might be time to revisit that?
Still would be a good idea. Hmm. Last I tried, Trac didn't want to get installed without SVN. Mantis requires MySQL and I'd rather avoid that.
So, would it be Bugzilla then? It seems to nowadays support PostgreSQL and it's kind of a standard everywhere. :)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBDldPFyUhSUUBViskRApQdAKCOE9aefDjK8S54qIM3dAJngHJ/zgCfRKI4 07/ogrfQmlCg6iFLM4ZzZCU= =3cMt -----END PGP SIGNATURE-----
On 2005-12-12 13:47:07 +0000, Neil Quiogue wrote:
Check Jira (www.atlassian.com). It's free for Open Source projects and we've been using it for quite some time now.
i wonder if cras would like to setup a tomcat and all that just for a bugtracker. :)
darix
There is a standalone version that tomcat included except for the database (though you'll set this up for any other bug tracking system anyhow). Relatively straightforward IMHO. ;-)
On 12/12/05, Marcus Rueckert rueckert@informatik.uni-rostock.de wrote:
On 2005-12-12 13:47:07 +0000, Neil Quiogue wrote:
Check Jira (www.atlassian.com). It's free for Open Source projects and we've been using it for quite some time now.
i wonder if cras would like to setup a tomcat and all that just for a bugtracker. :)
darix
On Tuesday 2005-November-29 06:52, Udo Rader wrote:
from him for some weeks now and "normally" Timo is quite active when it comes to supporting his 'dovecot' warp drive :-)
Yes, but I don't think this is unusual for him.
BTW I am having problems with your posts. GPG hangs because it tries every time to retrieve your key from a keyserver, and they don't have it. If you're going to sign posts, please submit your key to the keyservers. Thanks.
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: headerAm Dienstag, den 29.11.2005, 13:05 -0600 schrieb /dev/rob0:
BTW I am having problems with your posts. GPG hangs because it tries every time to retrieve your key from a keyserver, and they don't have it. If you're going to sign posts, please submit your key to the keyservers. Thanks.
Well, it all depends on which keyserver _you_ have set up. My public key is distributed among many keyservers, eg. www.keyserver.net. And also BTW, there are also quite a few corporate people that don't have their public keys published on public keyservers but on their corporate webpages instead. Automatic validation of signatures is a bad thing, IMHO.
-- BestSolution.at EDV Systemhaus GmbH http://www.bestsolution.at
Udo Rader wrote:
Am Dienstag, den 29.11.2005, 13:05 -0600 schrieb /dev/rob0:
BTW I am having problems with your posts. GPG hangs because it tries every time to retrieve your key from a keyserver, and they don't have it. If you're going to sign posts, please submit your key to the keyservers. Thanks.
Well, it all depends on which keyserver _you_ have set up. My public key is distributed among many keyservers, eg. www.keyserver.net. And also BTW, there are also quite a few corporate people that don't have their public keys published on public keyservers but on their corporate webpages instead. Automatic validation of signatures is a bad thing, IMHO.
Apparently not among *the* keyserver network (pgpkeys.mit.edu, subkeys.pgp.net et. al.), which exchange keys among themselves so that your readers don't have to travel the galaxy to find your public key.
PGP security is built around the web of trust, relying on key owners to get their keys cross-signed by other key owners, rather than having everyone publish their key on their, often not even SSL-protected, website.
Blindly trusting all keys on one's public keyring is in any case bad, if that's what you mean with "automatic validation".
-- Magnus Holmgren
participants (18)
-
/dev/rob0
-
Bernd Petrovitsch
-
Chris Wakelin
-
Dan Hollis
-
Glenn Leavell
-
Jaldhar H. Vyas
-
John Peacock
-
Kenneth Porter
-
Magnus Holmgren
-
Marcus Rueckert
-
Mark Rosenstand
-
Neil Quiogue
-
Obantec Support
-
seth vidal
-
Simon Waters
-
Timo Sirainen
-
Tomi Hakala
-
Udo Rader