On 11/12/2013 01:59 AM, Peter Peltonen wrote:
This really starts to sound like that many major components of the
toaster will be replaced by new ones.

Quite true. (And I should hope so!)

I would compare it to RedHat
replacing Xen virtualization (in CentOS 5) with KVM (In CentOS 6). If
you want to move to COS6 it will require quite a lot of work if you are
running many Xen VMs. Fortunately COS5 is supported for many years still
and you have time to prepare for this change.

That's a fair analogy. Of course we intend to automate changes as much as possible. In the case of custom scripts though, those will likely need to be redone for the new platform.

This is actually what would be ideal with toaster as well:

1) To have a stable branch with existing components for COS5 that will
receive security updates only and will not break any existing
functionality and that will be supported for as long as possible

2) To have a new "bleeding edge" branch with new components for COS6
that can break existing functionality

The only drawback here is of course the amount of work required. But I
think the package that mostly keeps receiving updates is just ClamAV?

This kind of solution would be optimal for me, how about others and how
do you Eric feel about keeping two branches, would it mean too much work
for you?

Sam C (of spamdyke fame) has a nice approach for this. When changes come along which "break existing functionality" (I would prefer the term "are not backwards compatible"), the major release number gets a bump. At this point, upgrading is simply not automatic. The amount of manual work is going to depend on what has changed.

I'd like to adopt the same approach with QMT. This way, there aren't multiple branches to maintain, but some users may prefer to stay where they are when major changes occur.

Clamav is indeed about the only thing that gets upstream updates these days (add spamdyke to that list soon). I expect to continue these updates regardless. This could be a challenge though if/when we get to the point of implementing amavisd-new in place of simscan.

I'll see if I can carry maildrop forward with the upcoming release. It may not be too bad, as only courier components it needs appear to be maildirmake and deliverquota. Maybe dovecot has something equivalent. We'll see how it goes.

--
-Eric 'shubes'


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to