Re: [Postfixadmin-devel] Do we need a 2.2.1 release?

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

Hello,

Am Sonntag, 15. Juni 2008 schrieb David Goodwin:
> I'm getting the feeling that we need a 2.2.1 release, which would be
> effectively :
>
> a) All the fixes we've made to trunk since 2.2.0 was released
> b) A Fix for the MySQL table creation problem (collation stuff)

Sounds like a good idea.

I'd like to add
c) go through all open bugs and check if they are release critical.

Unfortunately SF doesn't have a "severity" field, so we'll have to abuse 
the priority ;-)
Proposal:
- new bugs have prio 5 by default, which is something like a "needs 
  review" flag for me
- major and critical bugs get a higher prio - 6, 7 or 8
- blocker bugs get priority 9
- not-so-important bugs get prio 4 or lower
- prio 1 should be reserved for "do it on some rainy day" bugs ;-)
  and maybe also for things we probably won't include, but that 
  shouldn't be lost (like alternative vacation scripts)

Do you like this method? Or should we find another way?

While we are at it - should we force people to login before submitting 
something to the tracker? Anonymous items are often problematic if we 
need more information from the reporter...
I don't see a real problem with this - the forum also enforces login and 
nobody complained about this yet ;-)

> 'a' probably involves everything in trunk, except the merge of the
> domain alias patch.

I would not exclude it - it's a feature that is requested quite often.

However, we should think about adding an option to disable it via a 
$CONF switch - and maybe it should be disabled by default in 2.2.*.

I have to admit that I didn't test domain aliases on a real server, but 
at least the code in postfixadmin seems to work ;-)

> What's the issue with the MySQL vacation table stuff - do we need to
> find out what collation type the table is before creating it, so it
> matches with existing ones, or not manually specify it? I don't fully
> understand what's wrong.....

I checked the 2.1 release again and found out that there was no 
collation specified in the MySQL dump. This means that the collation 
2.1 users have in their database depends on the local MySQL settings. 
From our point of view, we can just call it "random"...
(also added this note to bug 1990191)

This means I should really change it within upgrade.php. (For users who 
already have the correct charset there won't be a change of course, 
even if the ALTER TABLE statements are executed.)

I'll probably have to setup a 2.1 database and manually alter the 
collation to make sure the upgrade works (and additionally don't have 
much time currently), so this "small" change might take some days.


If you have some time, could you please update the changelog?
If I get debian/changelog right, 2.2.0 was SVN r356. This means you'll 
have to pick the most important changes since then:
    svn log -r 356:379

Please also add the SVN revision to CHANGELOG.txt in all (future) 
releases and a $Id$ header (needs "svn propset svn:keywords 
CHANGELOG.txt") so that we can always see when the changelog was last 
updated.


Regards,

Christian Boltz
-- 
XSLT ist eine Art awk auf Bäumen und hat alle Nachteile von awk.
Wenn man vorher nur Shell konnte, ist es allerdings die Erleuchtung.
[Kristian Köhntopp in suse-linux-faq]