[pkg-kolab] Kolab Systems (ISV) requirements (was: cyrus-imapd 2.3.16)

Fri Sep 3 20:11:20 UTC 2010

Philip Hands wrote:
> Hi Jeroen,
> 

Hey Philip ;-)

> On Wed, 1 Sep 2010 15:49:21 +0200, "Jeroen van Meeuwen (Kolab Systems)" 
<vanmeeuwen at kolabsys.com> wrote:
> > For example, Kolab Systems may be required to support customer deployments 
of 
> > kolab-2.3 series for a number of years, while nobody in the community 
cares 
> > about it anymore some time after kolab-3.0 hits the fan.
> 
> If you care about it, then someone in the community cares about it.
> 

Of course, if not just by the fact that there is plenty of people.

> We even have a section "oldlibs" specifically for library packages that
> are obsolescent but which some packages still need to rely on for some
> reason (generally ISV binaries that depend on that version of the
> library, as Debian packages can just be rebuilt on the whole)
> 
> So, if you want to package old versions, as long as you do it in a way
> that is policy compliant (which might involve renaming the package to
> have the version number in it, say).  If you think it's useful for
> that package to be in Debian, then you're probably right.  Very few
> people's requirements are totally unique.
> 

I myself don't require kolab-X.Y to be part of the Debian distribution after 
kolab-(X+1).Z has been released. In fact, I would argue that long(er) term 
support would be a KSP for Kolab Systems. Then again if the community can 
provide what we are trying to sell... what is it exactly we're trying to sell? 
I would consider such an interesting question for Kolab Systems, and I would 
challenge Kolab Systems to renew it's business model. Luckily, long(er) term 
support isn't the only thing a Free Software ISV sells.

Customers however may (will) require support for kolab-X.Y in newer Debian 
releases, on newer Red Hat Enterprise Linux releases, until way after 
kolab-(X+2).Z has been released. Well, like I said, $$$ steers the engineer, 
not vice-versa. Luckily, this engineer works for a company that has a vast 
understanding of the Free Software ecosystem top-to-bottom ;-)

If the community, which in effect in this case is the parties with access to 
actually commit/upload to Debian repositories -myself not included- wishes to 
keep around old versions of Kolab with new releases of Debian, of course I am 
more then happy to help with that effort and make it so any customers of ours 
get kick-ass Free Software Kolab Systems itself may have had relatively little 
to nothing to do with. More power to us! I'll be looking for ways to return 
the favor starting this moment in anticipation of that happening, which is why 
I'm on this mailing list -and the other one- to begin with.

> > On a related topic, Kolab Systems -inherent to it all being supported and 
> > such- requires its own distribution channels; sometimes we may need to 
quickly 
> > solve one or the other issue and can not allow ourselves the risk of being 
> > held back by community distribution policies or access levels our 
engineers 
> > may or may not have. On a related note, we cannot allow ourselves the risk 
of 
> > a community member breaking our supported version of the product.
> 
> It would be entirely reasonable for you to add an additional APT source
> on systems that you support, with /etc/apt/preferences indicating that
> versions from your archive should be favoured even if higher numbered
> versions are available from the Debian archive.
> 

Yup, I know.

> This would not require you to do anything that might be deemed
> community-hostile.  You just put up an archive with the versions that
> you prefer your customers to use, and the settings on their systems will
> ensure that they use your versions.  If you patch the packages locally,
> just add something like ~kolabsys.1 to the end of the version number.
> The tilde(~) sorts below something with that bit missing, so if your
> package makes it into the wild, it will not be used by other people by
> mistake:   http://lwn.net/Articles/194664/
> 

I would argue that this is an upstream, kolab.org effort, if I were not 
stunned by your remark that I might do some or the other thing hostile to the 
community. I am community (see Google).

kolab.org still uses OpenPKG to distribute their product, which I'm trying to 
solve; something tangible could be found at, for example;

  http://git.kolabsys.com/

Which is my work to make something as simple as the perl library or web admin 
interface for Kolab releasable as a tarball. Note that it happens using Kolab 
Systems' infrastructure, and in time paid for by Kolab Systems, while pushing 
stuff upstream or blocking them downstream as much as I can -if anything, 
would the result blessed by Kolab Systems not be in accordance to the 
community's wishes, it would be Kolab Systems running in circles in my 
opinion. This wouldn't be hostile, this would be a certain type of humor -
irony.

You know the people behind Kolab Systems, and so I assume you know that a 
thriving community is key to success in their opinion as well. I'd like to 
think that Kolab users, through Debian and other distributions, can hugely 
benefit from the fact that resources have been assigned to Make Shit 
Happen(TM). I'm working to make that happen at a little past 10pm on a Friday 
evening -like so many others.

Of course what we need to get done *now* in light of Kolab Systems customer 
demand influences what I do *today*, but I'm trying to work with the people 
that have been providing native packaging since the dawn of mankind -hence I'm 
here on this mailing list taking my first few steps into the Debian packaging 
world.

Packages being out there "in the wild" as you put it, is exactly what I had in 
mind when I created the public mirror for native packages, and the public GIT 
repositories for our native packaging efforts. I'm used to doing X.Y-0.1rcZ 
releases where I come from, but sure X.Y~rc1-Z works for me as well.

> > Other times we have to release something that is not quite ready yet to 
what 
> > is considered to be a stable distribution release -adjacent to unstable 
> > distribution versions. We wouldn't want to burden the community members on 
the 
> > receiving end of bugs with such volatility.
> > 
> > Another example would be, that for the Kolab product, we touch 
configuration 
> > files from other packages. Most commonly, such is not allowed to be 
included 
> > in native packages included in a distribution's package repositories.
> 
> Doing that is generally a mistaken approach to doing what you want.
> It's generally better to either use something like puppet to control
> the systems, or to make the bits of the packages that you want to
> tweak something that can be selected in debconf at install time, and
> then perhaps providing preseed values so that your preferred defaults get
> applied automatically.
> 

Have I mentioned I'm the person behind puppetmanaged.org, 
git.puppetmanaged.org, puppetmanaged.org/documentation?

(Indeed, I'm not taking care of it the way I should, having to give you three 
links rather then one.)

While you may think I'm making some kind of arguably stupid argument here, 
please consider I may just know what's what exactly, and in full detail.

> > Either way, however, this would all be related to Kolab Systems more so 
then 
> > Debian specifically.
> 
> True, but over the years I've found that doing the apparently quick and
> easy thing comes back and bites you in the end, so when you're tempted
> to wander into policy violation, it's worth checking if there's not a
> nice way of achieving the same thing, even if it takes a little more
> effort up front.
> 

Been there, too, at some point in the past decade. It's one of the reasons I 
joined Kolab Systems, in fact. In the interest of full disclosure, the other 
reason was I needed a dayjob that enabled me to live in the UK -for reasons 
which I'll be happy to tell you all about over a beer ;-)

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08