Re: [Postfixadmin-devel] Strategy for vacation script and vacation tables

[Christian B. <pos...@cb...>]

Hello,

Am Samstag, 30. Dezember 2017 schrieb Christoph Lechleitner:
> On 2017-12-30 14:08, Christian Boltz wrote:
> > Yes, that's the expected behaviour:
> > 0 = reply exactly once for the whole vacation period
> > 1 = reply to every mail
> > 2 = reply if the last reply was sent more than $seconds ago
> > 
> > The examples in config.inc.php will tell you the same ;-)
> 
> Sorry I didn't look there.
> 
> There was no need to touch that in years.

;-)

[vacation end date when doing database upgrades]
> > I just pushed a fixed upgrade.php to fix this, but there's a fine
> > print: 
> > - As I just found out, sqlite doesn't support to change the
> > field> 
> >   default later, so people with existing sqlite databases will have
> >   to
> >   live with the wrong default.
> > 
> > - Also, the new default only applies when adding the column, so if
> > you> 
> >   already have the activeuntil column, the 2000-01-01 values will
> >   survive. In theory the new default also applies when doing an
> >   INSERT
> >   without specifying activeuntil, but this won't happen with
> >   PostfixAdmin ;-)
> 
> So that's mostly a concern for custom or third-party tools.

That, and for people who upgraded with the buggy upgrade code - which 
basically means everybody who upgraded from 2.3.x (or older) to 3.x.

> > (Just wondering - should I do a final commit that deletes everything
> > and only puts a README with a pointer to github there?)
> 
> If you are interested in the long term change history I'd double check
> if the svn era history has survived the migration to github.
> 
> Otherwise the only argument against deleting would be eventual old
> deep links in issues, mailing list archives and the like.

Yes, we kept the history when migrating to github. Also, the SVN history 
won't vanish just because I "svn rm" all files and replace them with a 
README ;-)  (done now)

> I have the luxury of an internal instance (for our own domain, no
> customers) where nobody needs vacation.pl, so I can easily test it
> anyways.

Oh, I even have a full mailserver setup with Postfix, Dovecot and 
PostfixAdmin on my laptop. Actually I even have multipe PostfixAdmin 
instances - a "productive" one to manage the mailboxes I use as local 
IMAP storage, and a few with test databases for PostfixAdmin 
development.

> >> 3. A PHP script, currently PostgreSQL only (other limits, too):
> >> https://sourceforge.net/p/postfixadmin/patches/9/
> >> 
> >> 4. A python script, currently PostgreSQL only (other limits, too):
> >> https://sourceforge.net/p/postfixadmin/patches/10/
> > 
> > These are user contributions, but since they are incomplete, it's
> > unlikely that we pick them up. They can't completely replace the
> > current perl script because of their limitations and I'm not going
> > to maintain multiple vacation scripts.
> > 
> > Actually it might be a good idea to finally close these tickets as
> > rejected - having them hang around isn't useful for anybody.
> 
> I agree.

Both rejected now.

> Unless it's already there a link to the refurbished vacation.pl
> wouldn't hurt neither.

I'll just assume that people know how to download the latest tarball ;-)

> > The openSUSE build service might be another option. I'm already
> > building the RPM package there, and if someone gets me started with
> > building DEBs there, we'd have everything at one place, which would
> > make the release work easier.
> 
> I should be able to help here, we use debian packages for everthing
> for 7 years now (even for the windows crossbuilds).

:-)

We already have the debian/* files in git, so building a DEB on a Debian 
system is probably easy. However I never tried to build a DEB in the 
openSUSE build service, so help in this area is welcome ;-)

> But it might take me some time to get comfy with git, because we
> happily still use svn for our own commercial and open source
> projects.

I know this problem ;-)

The PostfixAdmin git is "boring" - for me, git commit, pull and push are 
enough, which also means I didn't need to learn more.

The salt repo for the openSUSE infrastructure uses a slightly more 
interesting git repo where I at least need to use branches. Also, 
AppArmor switched from bzr to gitlab recently - which finally forced me 
to learn some more things about git.

Oh, and I still have a small (non-public) project that uses CVS for 
historical reasons ;-)

If you have "silly questions" about git, feel free to ask ;-)


Regards,

Christian Boltz
-- 
Wer nur "geht nicht" schreit, kann als Antwort auch nur ein
"muß aber gehen" kriegen, denn Kristallkugeln haben wir nicht. :-)
[Peer Heinlein in postfixbuch-users]