Re: SDK header translations licensing?
"Matthias Thoma" <[email protected]>
| Newsgroups | gmane.comp.lang.delphi.jedi |
|---|---|
| Message-ID | <00b001c403b1$66346120$0c00a8c0@pc2> |
Hello Peter,
> Of course, moreover it reduce the free time to create meaningful work.
At least here we agree :-)
> To discuss the problem in this forum can not change it, because the
> relevant libraries don't be JEDI libraries from sight of JEDI
> Steering.
I explicitely spoke about everything MPL/original author/copyright related
stuff which is also important to JEDI. The discussion has gone away from the
original problem to a more general discussion. This discussion is on-topic
here an can be continued.
> This is your opinion, the reality I have describe before.
It is unimportant if this is my opinion or not - it is the official position
of Project JEDI Steering team published on our homepage and posted here by a
member of the Project Steering team.
> If the statement is not the official position of JEDI Steering, why JEDI
Steering don't have
> contradict, although this issue was discussed many times in public.
Do you want me to repeat the above statement? That is our current position
regarding the API Library until we agree on something else...
> When do you want to improve your conversions?
> Currently you don't have enough free time to do your job in the JCL.
I have only one conversion which I always either updated myself or found
someone talented to update it... and I it is unfortunately true that I
currently have not the time I would like to have for the JCL. That is sad -
of course - but my time is pretty limited and currently my JEDI related
attention is somewhere else. If someone wants to step in for me, fill the
holes I have left and get the JCL forward feel free to send me mail...
> Nonsense. Unfortunately this is a example, how arrogance blindfold.
Compared with what you call your "old" JEDI+ thing our system is better.
> Meantime three years ago we both have discussed about the needed
> changes of JEDI's infrastructur and I have recommend the changes,
> which now are realized in a furthest unknown JEDI homepage.
Exactly, they now get realized - step by step. I also wished that things had
gone faster, but well, sometimes things do not get as fast as I or someone
else wants . I told you already why it is still unknown and as you wrote we
even agree on the reasons.
> Why do you believe, that I don't plan to create the some
> infrastructure on JEDI+ API?
Well, you reserve yourself the right to critize us on what we are now and
not on what we plan to do.
> BTW: In the last years, I have create new ideas, with other word, our
> system is not better.
;-)
> This claim, that the author want to be close to JEDI API Library.
It doesn't claim that. There are people which host their API stuff on our
homepage like Petr Vones, and others like for example you which don't. Petr
is closely related to JEDI and his fixes can be tracked. Yours are not - you
get an email and the bug gets an comment that the original author has been
notififed on x-y-z. In 90% of call cases the author will reply and let us
know if the bug is already fixed, will be fixed etc. I do not see a problem
here.
> If not, he get a mail and modify the conversion. But the bug is still
> open in JEDI's bug tracking system
People commonly reply if one sends them a mail.
> Because the new version is not available on the JEDI page
Says, who? In over 90% of all cases it will.
> There are more problems. How you can see, many users don't be able to
> use the bug tracking system in a correct manner. Therefore you need a
> people, which assign a bug to the correct project and category. Which
> person should do this?
I do not see a problem here. There are only two projects "API Library" and
"Linux API Library" - all other categories are monitored by their respective
teams and those people know how to move stuff out of their mantis project.
> Because the page is unmaintained JEDI could cause such branches. If a
> visitor of the JEDI API Library page don't see any reactions of a
> author, maybe he make a own bugfix and submit it to JEDI.
That is "as designed". Either the author responds or he doesn't. If he does
not its better to have a custom "bugfixed" version than none. That bug fixed
stuff will be forwarded to the original author as well. In that case we have
two entries in the API Library, one from the original author - a bugfixed
from a donator which is marked as such.
> > There are several mechanismens which are designed to prevent that.
>
> You are able to name and explain this mechanismens?
> I can not see any.
Well, most stuff is still in the works. It is a three layer strategy:
- Indirect feedback
- Direct feedback
- Automatic observation
- Human observation
Nonetheless, the most visible one is the comment feature. People can comment
on stuff. Commonly people searching for an API conversion look on more than
one place for the best solution - so if he or she finds one or a later one
he might report that back to us - he can even make it more or less direct
visible using the Submit API Library functionality. Furthermore for non JEDI
hosted stuff we always mention the homepage we link to. Most people will
also have a look at that homepage and hopefuly will report later version
back to us. (Indirect feedback based)
Direct feedback is feedback we try to get directly from the author. Inform
him about that he is listed, asking politely if he would be so kind to
inform us a not whenever he updates something and offer him to take care
about the link himself if he wants to, subscripe to newsletters, monitor
stuff etc. (direct feedback)
Automatic observation is more technical. In this section stuff like checking
the links, filesizes and filenames on a regular base. there is more planned
but I need to figure out what is feasonable and what isn't.
Human observation: Look at the links from time to time.
> Unfortunately Mister Marquardt scare potential helpers and JEDI
> Steering confirm his behavior as correct and praise Mister Marquardt
> instead to rebuke him.
No, this time I have the job to scare people. If someone wants to help
improve the homepage they will have to life with me...
> Now you need to live with the consequences. You know the way out from
> this problems, but you want to keep your job in Steering instead of
> real improvements.
I am already working on real improvements and my "job" in steering helps a
little bit to accomplish that task nonetheless I would have the some
wonderful life without it...
- Matthias
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/Delphi-JEDI/
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/