From: "Gordon Rowell" <[EMAIL PROTECTED]>
> Hang on a moment. We try, as much as possible, to maintain backwards
> compatibility and provide smooth upgrades. I happen to think we've
> done a pretty good job of this over many releases.
"Pretty good" doesn't work in production environments. I don't find
you at fault here - backwards compatibility is a horrible thing to even
try to get right and you have done all anyone could expect. However
once you have a complex system running such that many people rely
on it, you can't just replace it wholesale without expecting things to
break. Some showstopper examples I hit were the change in what
'everybody' means in ibay samba permissions in one update and the
inability to add 'local networks' using the default route in another.
These things can be found and fixed, but in practice the fact that
you have to deal with things that break working systems means that
you often can't upgrade things when you want. I don't want to belabor
this issue because I don't want you to waste more time on this end
of the problem. You won't be able to avoid breaking more things
in the future and I don't want you to. Instead I want to keep up with
whatever RedHat is tossing out these days because doing otherwise will
just make the problem worse next time around. In other words I
don't want to install anything new today knowing that it has backwards
compatibility compromises compared to RedHat's version, and the
more I know about where the product will be next year, the better.
> When we intentionally
> break compatibility for some reason (e.g. moving from Obtuse SMTPD to
> mailfront), we give clear prior warning to devinfo.
I consider deviating from RedHat's base product a much more serious
issue than your own backward compatibility problems here. For the
moment, MimeDefang appears to be the nicest mail add-on you can
find - and it needs sendmail to work. The concept of being able to
take advantage of many other peoples' work vs. just a few is the point
here more than the specific example but this is the reason one server
isn't running SME.
> > No one knows when you will release your next version or what it
> > will contain - and you have made that policy very clear.
> > [...]
>
> I stand by that policy and it's true of most other vendors. We provide
> developer previews which show what is likely to be in the coming
> release. The roadmap for future releases is influenced by many factors,
> internal and external.
Would the initial decision to use RedHat as the base for e-smith have
been the same without access to the rawhide site and the ability to
see work in progress - and the knowledge that many other people
had the same access and ability to contribute changes? It is one
thing to reserve the right to make last-minute changes, but something
else to keep people who want to help in the dark.
> The best way to get your feature on that roadmap is to contribute
> packages which are sufficiently developed to easily integrate - Dan
> Brown's IMP/horde/turba contribs are one such example - they slotted
> into 5.5 with minimal integration effort. I know you want better LDAP
> integration. So do we, but it's more likely to happen if you contribute
> the code in a close to production ready state. Why don't you start up
> an LDAP integration project on devinfo?
I'd like to do that but aside from not being sure I could complete it,
this would have to be tightly integrated into many other components.
That is, it would have to be tied to any forms that updated account
or email information, and all system and samba authentication and
email delivery mechanisms. And everything needs to know if it is
the master, allowed to update the master, or just a slave system.
Our developers here use CVS for everything and the first thing they
learn is that before doing any work they must update their workspace
to pull in what everyone else has done recently to avoid conflicts and
duplicated work. I assume you use some version control mechanism
internally, so I have to ask if you would assign such a job to an internal
developer while denying him any access to concurrent development by
others. I think the answer will clarify the relationship you really want
with outside developers.
----
Les Mikesell
[EMAIL PROTECTED]
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org
