Am Mittwoch, 14. Dezember 2005 08:59 schrieb Ralf S. Engelschall:
> On Thu, Dec 08, 2005, Bernhard Reiter wrote:
> > [...]
> > I believe that it has other reasons that the feedback form was not used
> > as planned. E.g. I saw the form, but I dislike forms like it so much,
> > that I did not use it, though I am quite happy to give you feedback.
>
> Well, you see, you are a classic user yourself, Bernhard: in theory you
> are happy to give feedback but practically you have not done it as you
> dislike feedback forms. That's the reason why we unfortunately had to
> use some more mandatory approaches...

The reasoning breaks in the "you have not done",
I gave examples below where I tried to give and gave feedback
to the project. If you type in my name in an internet search engine,
you will see that I gave feedback to many many Free Software projects.
I honor many project by giving them good bug reports and other things.

As to the number of systems and the feedback form,
I think it is a suboptimal way of getting feedback.
To be more contructive:

* explain better why this feedbackform is, and how the data is used.
Especially make believable 
that this is _not_ the classical feedback form to sell
email addresses to make money.
* advertise the feedback form and the results
* reward people somehow  (like showing that you have changed some
actions because of feedback).

> > You are asking for the number of users.
> > Usually download figures, as flawed as they are, good give
> > you a base to estimate this.
>
> Unfortunately, not really. We tried this multiple times but because of
> mirrors and proxies the numbers are such extremely distorted that even
> an estimation is too far away from the reality.

I see why this is really hard in this situation.

> > My recommendation would be to come worth with why this decision
> > is so time critical. So far it scheds general doubts on the future of
> > OpenPKG.
>
> The decisions are such time critical simply because Thomas and I (the
> main driving horses behind OpenPKG) are still under heavy personal time
> pressure as our full manpower sponsoring for OpenPKG (which was the
> equivalent of a full-time job until now) is terminating and to protect
> the future of OpenPKG we finally have to make decisions now. And those
> decisions unfortunately depend on whether the community is large and
> diverse enough or we would just waste lots of personal time and money.

Ah!
I think we probably have to continue the discussion internally
to find out if new sponsorship can be found and what the financial
alternatives are.

> > Our experience in the Kolab Project is that we get many people that
> > question our choice of OpenPKG and I expect introducing registration
> > to make it more difficult for us to put forth arguments for it.
>
> No, I see no real reason why your Kolab users _HAVE_ to register as
> OpenPKG users, although it would great for us. But you are using just
> a subset of OpenPKG for Kolab and for your users OpenPKG is just a
> sub-technology. Your users feel they are Kolab users and not OpenPKG
> users, so they will obviously refuse to register with OpenPKG, of
> course. That's ok.

Yes, I think you have stated one of the main problems that
as a sub-system, OpenPKG is not of enough importance to our users.
We are advertising this, though 
and after a while some people start to like it.
It is different so people emotionally are sceptical a lot in the beginning.
Some people will never like it, and hope to get it integrate in 
GNU/Linux distributions. This integration is a good development,
of course, but OpenPKG has shown its advantages for me already.


>
> > In some ways the system can be seen as being more restrictive
> > as  what some commercial distributors of operating systems do
> > (free and non-free).
>
> Restrictive? Hmmm. 

[will be addressed in a different email]

> > [...]
> > Just to give you an idea what I tried to get feedback for
> > a) Bugtracker link not working; Status: Still unfixed, no feedback
> > aafter three ttempts or so.
>
> Accepted. It is a shame

[discussion forked.]


> > b) Berkeley DB stability decision for OpenPKG 2.4 migration of Kolab.
> > Status: I have had communications with Thomas about this before, but
> > this mail went unanswered and we took a decision without answer.
> > (Maybe because I was not properly subscribed to an openpkg -list.)
>
> Sorry, I don't know the details here, so cannot say anything.

[ I will pull out my emails and submit it again to users. I think Thomas L. 
got it personally, too, but was on vacation during this period. ]

> > c) Long term maintenance ideas regarding GNU/Linux Enterprise
> > distributions. Status: I probably will have to resend the email.
>
> Here I don't know your question, 

[ I will resend the email to make it clearer. ]

> but in general we usually support those 
> distributions for which inside the OpenPKG Foundation we have both a
> valid license, a hardware (physical or virtual) and at least someone
> who maintains this setup. So, for instance RHEL3 we kicked out as our
> license expired, nobody donated a renewal and the underlying machine was
> already more reasonably used with RHEL4.

Good to know: So if we get distributions to get you a license,
you or somebody else finds a machine, and we find somebody to keep the 
installation going, OpenPKG would support it.
I could at least ask RedHat and we could look for contacts within Novell
and Mandriva.

> > > I personally think that the free of charge one-time registration should
> > > be no problem at all for any serious OpenPKG user.
> >
> > I doubt it.
> > You now force the Kolab Project to decide if we run a mirror (which you
> > describe as unfair) or force the registration decision on our users.
> > For the Kolab Project this is not a nice situation.
> > Most users would want us as feedback station first
> > and not have a heartbeat with OpenPKG.
> > [...]
>
> Wait, wait. Kolab uses a *sub-set* of just about 50 OpenPKG packages.
> First, you don't need a full-size OpenPKG mirror for this. Making your
> sub-set of OpenPKG packages available to everyone on your server in the
> form of a your "Kolab distribution" is both fair, license compliant and
> fully ok from my point of view. Second, as I said, your Kolab users
> don't _have_ to register with OpenPKG. We would like that you tell them
> that in order to support OpenPKG they _should_ register, but there is no
> requirement.

Okay, if we can work with mirroring without mandatory registration
and you (and whole OpenPKG) considers this fair, it takes a burden off me!

As for security updates: We need to route them more through Kolab then,
as we were encouraging people to directly get the updates from OpenPKG
once they are available. But this is fine.

Bernhard

______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
User Communication List                      [email protected]

Reply via email to