Request For Release

[Matt Darcy]

Hi all,

in light of the excellent change thats been pushed through recently to remove the clear field (big change in functionality!)

and the various other updates in the last 7 days, I'd like to suggest, from everything I've ready so far that it maybe a good place to actually tag a release, it would be the first one for a long time and give people a stable point in time to know where they are in comparison to development rather than a constant rolling master or feature branches.

Thoughts ?

Matt

[Sebastian Cabrera]

Hi Matt,

actually that's the case why no new features are added lately but just code cleanups AFAIK.
I suggest features should kept frozen and when the code seems clean and the documentation has been overworked we could tag a new release here...
I'm not doing much work to the Project at the moment as I'm stuck with other work...hopefully that will get better soon.

regards,

Sebastian

[Avleen Vig]

If we feel the code is stable (man, we should really have some unit tests!), then it should be OK to do so.

One of the things it would be nice to put some time into soon would definitely be testing.

[Matt Darcy]

I'm currently putting up a vexim.org site - with a locked down wiki that we can put some proper documentation on that can evolve securely, I agree for the need for good docs, things like changing the imap integration now that the clear field is gone, and the cypher changes will catch people out

Not sure what we can do about testing/unit tests, has there ever been work done on that before ?

[Rimas Kudelis]

Hi,

2015-09-16 11:18, Matt Darcy rašė:
> I'm currently putting up a vexim.org site - with a locked down wiki
> that we can put some proper documentation on that can evolve securely,
> I agree for the need for good docs, things like changing the imap
> integration now that the clear field is gone, and the cypher changes
> will catch people out

I can't remember if we talked about it, but perhaps you'd like to use
GitHub's wiki functionality for that?

> Not sure what we can do about testing/unit tests, has there ever been
> work done on that before ?

I don't think so. :)

Rimas

[Rimas Kudelis]

Hi,

There still are two things I'd like to see fixed before tagging 2.3:
- your pull request (https://github.com/avleen/vexim2/pull/45). We
should suggest reasonable SSL defaults for both OpenSSL and GnuTLS users
(or to just close the PR).
- the default configure file should be checked and updated as necessary.
At its current state, I'm not even sure that it works. That's
https://github.com/avleen/vexim2/issues/8 .

When these two points are addressed, and if no new bugs surface, I think
we would be good for release.

Rimas

[Rimas Kudelis]

Hi all,

when talking to Matt on IRC yesterday, I remembered one more thing that
would be really nice to have in the upcoming release: data migration
scripts!

Sooo... if anyone has an older version of Vexim running, now is the time
to test them. I've just committed them to a dedicated branch here:
https://github.com/avleen/vexim2/tree/migration_scripts

Please take a look and try them out if you have time.

While working on this, I've also noticed that even though our database
tables cross-reference each other, this is not specified at the DB
level, so I took time today and added a bunch of foreign key definitions
to our schema.

Also: I committed a newly exported schema file. By default, it will not
create the database from now on (which means you can use it with any
schema name you want, without editing it everywhere), but you can
uncomment four statements at the top of the file, and if you do, it will
create the `vexim` database as well, and add all tables to it.

I'm gonna do some light testing on all these changes today, but if
anyone else would want to test them, please do.

Rimas

[Avleen Vig]

Nice work setting up the website Matt! We used to have one, but now silverwraith.com/vexim just redirects to the github page :)

I'd like to also suggest using the github wiki, as it'll provide a lower barrier to entry for others (people new to the project, those who want to make quick fixes, etc) to make changes, vs a wiki on another website.

That said, any work that anyone wants to do is awesome and I won't try too hard to change your mind.

Nothing's been done with unit testing before, but it should be easy enough to do with PHPUnit, and later we can tie that into travis-ci to get tests running automatically on pull requests.

It will likely mean we need to refactor some code.

Especially things like breaking out the HTML into proper templates and things. But it's something we need to do eventually anyway!

[Avleen Vig]

Hi Rimas!

Are you going to add the foreign keys for both postgresql and mysql?

I'm wondering if we should have some kind of test bed for this.

It would probably be pretty easy to whip one up with virtualbox + chef to get us a base system that we can use for testing.

I'm getting on a plane shortly, so I'll play around with that idea today and see how feasible it is :)

[Rimas Kudelis]

Hi,

no, in fact, I completely forgot about Postgresql.

Having a test bed would definitely be fine. In fact, I myself have a
working Virtualbox with a linux VM, that's how I'm going to test my
migration scripts. :) But if you want to build a VM that anyone could
test with, I can only salute that!

BTW, I'm thinking perhaps you would want to create a Vexim organization
in GitHub and make it the owner of the vexim repo? I suppose this way it
would be easier to have more admins with full permissions.

Rimas

[Avleen Vig]

Good idea. I'll make a note of this and get it done soon :)