RE: [qmailadmin-devel] Show stoppers to making a stable release

[Benjamin T. <bto...@so...>]

> Ken has dropped the ball on the vpopmail 5.3.21 release, and it may
> soon end up on SourceForge as well.
>
Sorry to hear this, though it doesn't surprise me given the current economy.

> 1) A tool to go through all .qmail-user files in all domains and
> convert aliases to forwards (i.e., Maildir delivery to &us...@do...
> format).
>
> Does anyone want to tackle number 1?  Do you think a Perl script is
> appropriate, or would it have to be a compiled C program?  I can
> probably whip up some Perl in a few hours to get the job done, but C
> could take 2-3 times as long.
>
This should be a relatively easy script to write.  I was going to suggest a
shell script alternative, but I think the parsing will be complicated enough
(from a generic standpoint) that PERL probably would be better.
Unfortunately, I don't know PERL.  From a high-level, all that should occur
is this:
-command invoked with the domain in question (use vdominfo -d domain.com to
get the full path)
-from a shell script standpoint, do a "grep Maildir .qmail*" from the
domain's base directory -- does this need to be recursive, too, for some
reason?  would aliases have been created in users' directories?
-for each file that has Maildir in it, take the field directly proceeding
/Maildir and the field following domain/ (or whatever the common root is --
this might need to be parsed for commonality from the first line)
-with the two fields determined, they should be easily reformatted into
&us...@do... format

> Is there anything else that should go on this list?  Counting of
> forwards was broken in 1.0.24, but I already have a fix in 1.0.25.
>
After this release tree is completed, I like to see a new branch started
(perhaps with a new/modified name?) that a) ports over the compiled CGI to
PHP, b) integrated vqadmin functions, and c) provides the ability to make
authenticated curl-type calls with commandline parms that would work better
with automated, self-provisioning systems (since I don't like relying on
ssh-keyed CLI methods right now).  Putting this all into PHP would go a long
way toward solving some of my integration problems which thus far have been
worked around with iframes, but really, that's not a full-blown solution.

> Should we set up CVS on SourceForge?  If someone can give me simple
> directions, I'd be willing to push my current in-progress work up to
> CVS on a regular basis, and could accept patches posted to the
> repository as well.
>
I'm not a developer, so I can't speak to this, but CVS seems to be the thing
to do, and so it probably wouldn't be a bad idea.

> I think that all of the other feature requests can wait for the next
> development cycle, which I plan on opening up as soon as QA is stable.
> I'm even willing to declare 1.0.25 (or maybe 1.0.26) stable and open up
> 1.1 before vpopmail is stable.  We can continue to patch the 1.0 series
> with bugfixes, while adding new features and rewriting parts of 1.1.
>
Yes, this makes sense, it's time to close out features for this release tree
and start looking ahead to the next version.