[Kolab-devel] I'm frustrated because my patches where not included in RC1

[Gunnar Wrobel]

Hi Alain,

"Alain Spineux" <aspineux at gmail.com> writes:

> The subject is lying, but catched your attention :-)

It did ;)

> I'm frustrated because I dont know _why_  they where not include in
> the next release.
>
> I thing someone from the Kolab Team should take actions about the existing
> roundup's issue at https://intevation.de/roundup/kolab !
>
> Existing roundup's issues should be:
>
> - closed because: unrealistic, definitely not in the objective of software ...

I'm working through old bugs occasionaly, request feedback if
appropriate and close them after two weeks of no response if I see no
hope for the point made in the bug.

The interesting thing about this is, that I frequently was proven
wrong. Even if the bug was older than two years, I got feedback that
it is still a valid issue and there were reasons to keep it open.

I will continue to browse through the list of open issues at a slow
pace but I think there is no need to rush on the old bugs.

> - postponed to a future release; this imply the existence of a more
> detailed road map.

We do indeed still have problems getting a decent roadmap together. We
could probably do better here. But on the other hand the development
team is still small and we depend a lot on the contracts we get for
the server.

Fact is: If a customer comes along and requests a feature that he
needs in a time frame of two months, then this feature will suddenly
appear on the internal roadmap and be implemented in that time. So
there is not that much planning beforehand.

> - "incomplete"; the feature has some interest but need more work from
> the contributors
> to be scheduled in a future release.
> - chatting; like too much issues in roundup now. After 6month without
> update an issue
> should be
> - work in progress: someone from the kolab team is working on it.

I would say that "incomplete" is the current "chatting" state, or not?
Marking an issue "in-progress" only makes sense if somebody is really
working on it. And it is a fact that not every of the issues finds a
developer working on it after six months. This is a question of man
power :)

>
> The roadmap is incomplete. It include only some unclear objective for
> the next release.
> It should include more release, 2.3, 2.4, 3.0 ...
> They are crucial points like the rewrite of the ldap structure to have
> a better support of
> multi-domain configuration (at least a separate contact list per domain),
> and support for grey-listing and black-list. They are not in the schedule!
>
> I will give you a sample of the consequence of your "hesitation".
> One year ago (January 2007) jhf posted all the patches required
> to include support for grey and black listing management in Kolab.
> Some chatting followed until August 2007, I invested myself in
> this discussion! But nothing until then! Why this crucial issue was
> not, a least, updated until then ?
> Some time ago someone filled some issue about the same
> subject, I even didn't read them because I was sure they will not
> have more consequence than the first one!

Of course I agree that it would be nice if we could pick up these
issues and get them into the server. But as I already mentioned
concerning your squirrelmail extension: Any additional core
functionality in the server needs to be actively supported by the
developers and the Kolab consortium.

The server as it exists right now already has quite a number of
features that are hard to maintain and keep in good shape. There is a
reason why there are so many open bugs in the tracker after all :)

As I already mentioned when we discussed squirrelmail: We'd need a
decent extension framework for the Kolab server that would allow to
packages external extensions more easily.

Probably the current install-kolab.sh script would be a good target
for that (though, as you are well aware, this script still has some
peculiar problems). So maybe another script "extend-kolab.sh" would be
needed.

Once we have that we could create a central storage space where you
could upload the squirrelmail and greylisting extensions without
making it necessary for the developers to fully support these
extensions.

> With a better respect of the rules above, the Kolab project could
> get a better support from the users and from the contributor and
> then become better.

I definitely think that the project is in general on a good track
since development activity is also steadily increasing. So I hope we
will be able to respond quicker to open bugs in the future and further
grow the community.

> I'm ready to read carefully your comment.

Okay, one last personal comment: I *wanted* Horde in Kolab. I was told
that the Horde code had been analyzed and it was considered unlikely
that it could *ever* be made into a stable Kolab client. But I'm
stubborn by nature and invested some time into this project to get
what I wanted. This is how the free software world works for me: If I
really want it and invest the required time most things will be
possible.

My personal 2 cents ;)

Cheers,

Gunnar


-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~