[Kolab-devel] Closing Call: KEP #9

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Fri Sep 2 14:23:53 CEST 2011


Georg C. F. Greve wrote:
> On Friday 02 September 2011 10.51:15 Jeroen van Meeuwen wrote:
> > > I'm uncertain about what gets stored in "/vendor/tarent/syncpref" and
> > > "/vendor/x-toltec/test". "/vendor/kolab/h-share-attr-desc" is most
> > > likely unused (though I would have to check when and why it was
> > > exactly added).
> > 
> > I feel we need another (few) informational KEP(s) to explain the other
> > annotations currently deployed through Kolab.
> 
> I would strongly advocate that the *Kolab* Enhancement Proposals focus on
> the /vendor/*kolab*/ namespace. That namespace is open, and anyone can put
> forward a KEP, so there is no limit as to who can participate in it.
> 

Let's note that it is Kolab that ships /etc/imapd.annotations.conf, which is 
where the annotations need to be configured in order for Cyrus IMAP to pick 
them up and allow them to be set.

We are currently shipping a file in which, apparently, some entries have 
little to no rationale, its purpose may be unknown, with namespaces added that 
do not have an owner, lacking the necessary documentation, and some of which 
the probable owners fail to see the continued use.

I think it is necessary to document the current annotations we ship in said 
configuration file, and allow for a level of critical review. This should be a 
simple and quick process.

> But I'm not sure this needs to get too much emphasis for the KEP process
> and resources spent by the Kolab community, especially if the people who
> have defined those attributes don't consider it worthwhile themselves.
> 

If the KEP process is too lengthy / too much overhead / killing a fly with a 
nuclear missile for the creation of a status quo document, I think the flaw is 
in the KEP process.

<sillyness>
I would be more then happy to withdraw KEP #10 and just ship it as a topic in 
the authoritative documentation shipped with our product. Perhaps I can 
squeeze some other topics past the KEP process using the same route as well.

Alternatively, I could remove everything we do not have a clearly defined use 
and owner for, and require the "enhancements" for adding them back go through 
the KEP process.
</sillyness>

Seriously though, if not the KEP process, can we require somebody takes 
ownership of every annotation shipped, and document it's purpose to say the 
very least?

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20110902/39c6efed/attachment.html>


More information about the format mailing list