Use of the Calligra name

[todd rme]

On Wed, Dec 29, 2010 at 12:10 PM, Sven Langkamp <sven.langkamp at gmail.com> wrote:
> On Wed, Dec 29, 2010 at 5:25 PM, todd rme <toddrme2178 at gmail.com> wrote:
>> So you are saying Linux distributions cannot even fix compilation
>> errors without getting approval from Calligra devs?  I cannot see any
>> benefit to this particular policy, it will really slow down packaging
>> considerably with no benefit to users.
>
> Read again. "Light patched" version are allowed, so things like compilation
> errors are ok.

It says "light patched" is allowed, so long as the patch "has been
approved for a future stable release of the Calligra branch it was
applied to."  I read this to say that distributions have to wait to
get their compilation error patches accepted upstream before they can
use them.

>> What does "new feature" mean?  Is this a totally independent feature,
>> or does it include features accepted into future versions of calligra
>> and backported?
>>
>> Have you discussed this policy with Linux distributions?  Different
>> distributions have different targeted user groups and thus different
>> approaches to backports and such.  I think the issue of backports
>> should be up to the distributions to decide, since they know their
>> targeted demographic better than we do.
>>
>> Does this ban the release of binary development releases?  If not, are
>> people required to use one "official" development tree?  What about
>> people making their own git branch, then using something like OBS to
>> build binaries for it for testing?  Is this banned?  Won't this
>> restrict people from testing development versions or experimental
>> features?  A good example is the experimental opengl marble branch,
>> which exists outside the main marble source tree but the developer is
>> asking for help testing.  Under this policy, would distributions be
>> banned from providing binaries of such testing versions in order to
>> help the developer make the feature as good as possible?  And who
>> would enforce it?  Are you going to go after individual users, or will
>> you expect OBS moderators to check every version of calligra in the
>> entire system to make sure it is the "correct" version.
>>
>> You should also think about the effects this has on development by
>> distributions.  As an example, openSUSE developed KDE 4 integration
>> features for firefox.  They got them working first, but they were ugly
>> and not suitable for upstream.  So over time intended to clean them up
>> and submit them upstream.  This does not seem to be an uncommon
>> approach, but your policy would prevent it entirely.  I am concerned
>> this will limit contributions from distributions.
>>
>> How do you plan to enforce this?  Are you really going to start suing
>> linux distributions if they don't follow this policy?  The absolute
>> worst thing you could do is have a restrictive policy that everyone
>> ignores.  That is the best way to make people lose all respect for you
>> and all of your other policies.  You either need to enforce it, or
>> have a policy people are likely to follow.  Considering how much this
>> policy diverges from accepted practices, and the experiences KDE had
>> with distributions ignoring requests not to use KDE 4.0, I think it is
>> unlikely this policy will be followed universally without strict
>> enforcement.
>
> Remember when Debian modified OpenSSL and created a big security hole by
> that?

Yes, it causes problems.  It also leads to a lot of useful features,
like the firefox one I mentioned.  Others include KDE/openoffice
integration and openoffice video support.

>The job of a distribution is to distribute the software. If they want
> to develop the software they should do it upstream.

That is easy to say, but this is often not how it works in practice.
Developing patches in-house then pushing them upstream later seems
pretty standard.  You are demanding developers change the work flow
they use for all the other software they work on just for you.  I
think that would serve to discourage contributions.

> Features that can't go
> upstream because they are too ugly should not be released by distributions.

But if that was the case a lot of beneficial patches would not happen
at all, or take much, much longer, and would not have received
appropriate testing when they do appear. Is that really a good thing?
Things like the KDE/firefox interactions very well might not have
happened at all if all distributions followed your rules.

What happens if a distribution does this against your wishes?  Will
you reject the patches when they are perfected?  Or will you ignore
the fact that the patch was developed in a manner contrary to your
policy?  If the former, then you hurt your users by denying them good
features.  If the latter, then you send the message even you don't
care about your own policies, so why should any else?  That will serve
to not only hurt respect for this policy, but all your other policies
as well.  I don't think either is a good outcome.

> I know that some distributions like to patch (and break) software, but we
> can't really prevent that.

So in other words you are making a policy that you don't actually
expect to make any difference?  Distributions that will follow this
policy do so without you needing to tell them, and distributions that
don't already do this are unlikely to follow the policy.  So what is
the point in having the policy at all, other than alienating
packagers?

I understand the theory behind the policy, but considering existing
distribution practices and the development work-flow used in many
distributions I don't think it will work in practice, and may even
serve to stifle development.

And you still haven't explained how the policy effects binaries of
development releases, which is an important issue that effects your
ability to do testing.

-Todd