Home » General (non-technical) » Eclipse Foundation » [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues
[GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #8776] |
Sat, 01 January 2005 10:04 |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
I ask the relevant organs within the eclipse foundation to intervent.
Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core in a way
which results in a false reflection of the current status of the issues
and their dependencies.
-
Reviewing the J2SE 5.0 implementation status, i've found information
that was out of synch:
this huge "Issue":
https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
an outdated and inprecise plan, mostly without links to filed known
issues within bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
-
This "out-of-synch" problem would be reduced, if the plan was created
out of the bugzilla database, as suggested in this thread:
[PROJECT] [BUGZILLA] - Dependency Feature
http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
-
I've entered within Buzilla (the eclipse Issue Tracking System) the
following Issue [using current title, initial title was different]:
[Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
-
this Issue depends on the implementation (within JDT.Core) of the
following JSR's:
JSR-201 (contains several parts), JSR-175, JSR-014
Whilst using the dependency-feature of Bugzilla, I've filed (after
looking for duplicates) the further top-level Issues:
JSR-014 Generics
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
Implement JSR-175 Metadata Facility (Annotations)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
Implement JSR-201 (enumerations, autoboxing, varargs, enhanced loops,
static imports)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
Implement JSR-201, part "static imports"
https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
-
I've interlinked existing issues (and the newly filed documented known
issues) with use of the dependency feature.
-
You will see within the issues, that Mr. Kent Johnson (IBM) _closes_ the
issues as INVALID - and as the last action, removing dependencies
without any justifying comments.
What happens when a users searches for JSR-175 within Bugzilla?
Or JSR-176?
He finds obfuscated data.
-
It looks to me that the team is not intrested in real transparency, but
just in keeping the open issues as low as possible.
Until the JSR's were fully implemented within JDT.Core, the filed Issues
remain _open_.
This is a _fact_ - and I ask you to keep the Issue tracking transparent
and honest, whilst reflecting the _real_ status.
I've not the time to continue those close/open games from Mr. Kent
Johnson (IBM).
-
"JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
implemented fully within eclipse JDT.Core - and Bugzilla should reflect
the correct status.
Any JSR is worth a dedicated Issue within Buzilla, thus users hit on
this information after a search.
..
--
http://lazaridis.com
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9303 is a reply to message #8776] |
Mon, 03 January 2005 09:51 |
Philippe Mulet Messages: 229 Registered: July 2009 |
Senior Member |
|
|
The JDT/Core team is maintaining an accurate status of J2SE 5.0 support on
its web page:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
We use the bugzilla databse to track specific defects, and do not really
need an extra (after the fact) dependency tree to mimick the web page.
At this stage in our development cycle, we are trying to solve all remaining
problems in J2SE 5.0 front, and need specific defects to help us; we have a
couple non specific defects which are representing committed 3.1 plan items,
and do not need extra ones to simply reformulate them (yes I agree in a
clearer way, but still duplicates).
Basically, your effort should have occurred when the J2SE 5.0 effort
started, and you should have better communicated with the JDT Core team so
as not to be disrupting our effort.
I appreciate your no longer reopening unnecessary defects, since they are
inducing false hits in mail notifications; and thanks for your interest in
our J2SE 5.0 effort.
"ilias" <ilias@lazaridis.com> wrote in message
news:cr5sji$i45$1@www.eclipse.org...
> I ask the relevant organs within the eclipse foundation to intervent.
>
> Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core in a way
> which results in a false reflection of the current status of the issues
> and their dependencies.
>
> -
>
> Reviewing the J2SE 5.0 implementation status, i've found information
> that was out of synch:
>
> this huge "Issue":
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>
> an outdated and inprecise plan, mostly without links to filed known
> issues within bugzilla:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>
> -
>
> This "out-of-synch" problem would be reduced, if the plan was created
> out of the bugzilla database, as suggested in this thread:
>
> [PROJECT] [BUGZILLA] - Dependency Feature
>
http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>
> -
>
> I've entered within Buzilla (the eclipse Issue Tracking System) the
> following Issue [using current title, initial title was different]:
>
> [Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>
> -
>
> this Issue depends on the implementation (within JDT.Core) of the
> following JSR's:
>
> JSR-201 (contains several parts), JSR-175, JSR-014
>
> Whilst using the dependency-feature of Bugzilla, I've filed (after
> looking for duplicates) the further top-level Issues:
>
> JSR-014 Generics
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>
> Implement JSR-175 Metadata Facility (Annotations)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>
> Implement JSR-201 (enumerations, autoboxing, varargs, enhanced loops,
> static imports)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>
> Implement JSR-201, part "static imports"
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>
> -
>
> I've interlinked existing issues (and the newly filed documented known
> issues) with use of the dependency feature.
>
> -
>
> You will see within the issues, that Mr. Kent Johnson (IBM) _closes_ the
> issues as INVALID - and as the last action, removing dependencies
> without any justifying comments.
>
> What happens when a users searches for JSR-175 within Bugzilla?
>
> Or JSR-176?
>
> He finds obfuscated data.
>
> -
>
> It looks to me that the team is not intrested in real transparency, but
> just in keeping the open issues as low as possible.
>
> Until the JSR's were fully implemented within JDT.Core, the filed Issues
> remain _open_.
>
> This is a _fact_ - and I ask you to keep the Issue tracking transparent
> and honest, whilst reflecting the _real_ status.
>
> I've not the time to continue those close/open games from Mr. Kent
> Johnson (IBM).
>
> -
>
> "JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
> implemented fully within eclipse JDT.Core - and Bugzilla should reflect
> the correct status.
>
> Any JSR is worth a dedicated Issue within Buzilla, thus users hit on
> this information after a search.
>
> .
>
> --
> http://lazaridis.com
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9327 is a reply to message #9303] |
Mon, 03 January 2005 14:31 |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
Philippe Mulet wrote:
[moved down into context]
> "ilias" <ilias@lazaridis.com> wrote in message
> news:cr5sji$i45$1@www.eclipse.org...
>
>> I ask the relevant organs within the eclipse foundation to
>> intervent.
Awaiting a reaction.
Please ensure the transparency of the development process.
>> Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core in
>> a way which results in a false reflection of the current status of
>> the issues and their dependencies.
>>
>> -
>>
>> Reviewing the J2SE 5.0 implementation status, i've found
>> information that was out of synch:
>>
>> this huge "Issue":
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>
>> an outdated and inprecise plan, mostly without links to filed known
>> issues within bugzilla:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
> The JDT/Core team is maintaining an accurate status of J2SE 5.0
> support on its web page:
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
The status _was_ not accurate (see provided links above, which proof this).
The status _is_ not accurate:
* The open and the known issues are not filed.
* links were not provided within the plan.
* Interdependencies were not shown.
[I am wondering if the team uses an internal system, which is hidden
from public.]
>> This "out-of-synch" problem would be reduced, if the plan was
>> created out of the bugzilla database, as suggested in this thread:
>>
>> [PROJECT] [BUGZILLA] - Dependency Feature
> http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>
>
>> -
>>
>> I've entered within Buzilla (the eclipse Issue Tracking System) the
>> following Issue [using current title, initial title was
>> different]:
>>
>> [Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>
>> -
>>
>> this Issue depends on the implementation (within JDT.Core) of the
>> following JSR's:
>>
>> JSR-201 (contains several parts), JSR-175, JSR-014
>>
>> Whilst using the dependency-feature of Bugzilla, I've filed (after
>> looking for duplicates) the further top-level Issues:
>>
>> JSR-014 Generics
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>
>> Implement JSR-175 Metadata Facility (Annotations)
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>
>> Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
>> loops, static imports)
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>
>> Implement JSR-201, part "static imports"
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>
>> -
>>
>> I've interlinked existing issues (and the newly filed documented
>> known issues) with use of the dependency feature.
> We use the bugzilla databse to track specific defects, and do not
> really need an extra (after the fact) dependency tree to mimick the
> web page.
Your team-driven [users have no influence], out-dated and
non-referencing status-report within the projects website is not that
relevant.
Bugzilla must inform the users, which search there for known issues.
The dependecy-tree clarifies the issue-interdependencies, enabling users
to detect relevant locations where they can contribute if they like to
boost development.
Please remember that this is an open-source project.
> At this stage in our development cycle, we are trying to
> solve all remaining problems in J2SE 5.0 front, and need specific
> defects to help us; we have a couple non specific defects which are
> representing committed 3.1 plan items,
are you refering to this joke of an [plan item] issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
which I would personally be ashamed to show to the public?
> and do not need extra ones to
> simply reformulate them (yes I agree in a clearer way, but still
> duplicates).
So, you really want to continue this arrogant behaviour?
I could expect from an experienced team that it understands the
difference between "duplicate" and "depending on" relation.
>> You will see within the issues, that Mr. Kent Johnson (IBM)
>> _closes_ the issues as INVALID - and as the last action, removing
>> dependencies without any justifying comments.
>>
>> What happens when a users searches for JSR-175 within Bugzilla?
>>
>> Or JSR-176?
>>
>> He finds obfuscated data.
>>
>> -
>>
>> It looks to me that the team is not intrested in real transparency,
>> but just in keeping the open issues as low as possible.
>>
>> Until the JSR's were fully implemented within JDT.Core, the filed
>> Issues remain _open_.
>>
>> This is a _fact_ - and I ask you to keep the Issue tracking
>> transparent and honest, whilst reflecting the _real_ status.
>>
>> I've not the time to continue those close/open games from Mr. Kent
>> Johnson (IBM).
>>
>> -
>>
>> "JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from
>> beeing implemented fully within eclipse JDT.Core - and Bugzilla
>> should reflect the correct status.
> Basically, your effort should have occurred when the J2SE 5.0 effort
> started, and you should have better communicated with the JDT Core
> team so as not to be disrupting our effort.
I think it's a good moment to file the open J2SE 5.0 Issues, which will
take a few months to finish.
I'm not disrupting your effort (to implement J2SE 5.0 within JDT.Core)
But you do disrupt mine (to organize and interlink the known issues)
>> Any JSR is worth a dedicated Issue within Buzilla, thus users hit
>> on this information after a search.
> I appreciate your no longer reopening unnecessary defects, since they
> are inducing false hits in mail notifications; and thanks for your
> interest in our J2SE 5.0 effort.
So, you think honestly that an JSR is not worth an dedicated Issue?
Feel free.
As I will feel free to reopen the _perfectly_ valid Issues.
The arrogant behaviour [ignoring facts and rationales] of the JDT.Core
team (IBM) will not hinder me to increase transparency of the
development, whilst using the resources of this project.
....
except:
You could state what should become obvious to every reader:
"We (IBM) do not want too much transparency within the JDT.Core. That's
the reason why everything is kept so terribly unorganized within _one_
component "Core", including the whole compiler [yes, really! the
compiler is not an seperated organisational unit]. So, don't expect that
we will allow you to create a transparent dependency-tree, thus everyone
is able to understand within minutes the status and the
interconnections. We will fight this, whilst risking to look like dumbs
who do not understand the difference between a duplicate and a
depending-on relation. We will even take the risk to state that an JSR
is not worth an dedicated issue within bugzilla - and has to be marked
as invalid."
then I would possibly stop to insist on a transparent issue filing
within this project.
..
--
http://lazaridis.com
|
|
| |
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9375 is a reply to message #9351] |
Wed, 05 January 2005 19:18 |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
Mike Milinkovich wrote:
> I am not sure who you expect to intervene or what you expect "...the
> relevant organs within the eclipse foundation..." to do.
Resolving.
"abuse of power and position"
[I do not accept this silently, like other users.]
> Everything you have complained about is perfectly transparent. You
> opened several duplicative and unnecessary bug reports which we
> closed by the developer(s).
"duplicative" => false (see [1])
"unnecessary" => false (see [2])
> They were well within their rights to do so.
of course not. [see my requoted rationales below]
> I am satisfied that Kent did the right thing.
I am unsatisfied which your way to ignore the given rationales.
> Here's a suggestion. Rather than trying to convert the Eclipse open
> source project to work the way to wished it did, why don't you try
> learning how it actually does work and participating using the same
> rules of engagement as everyone else?
I know how this weak and non-integrated planning system works, and I've
already suggested some changes (which you are free to ignore once more):
see [3]
> Eclipse is an open source project. It is run by developers for
> developers. The Eclipse Foundation is a member-supported
> not-for-profit organization which is focused on meeting the needs of
> its members and supporting the requirements of the project
> developers.
I understand.
> For users to be effective in promoting their interests,
> they need to communicate using the channels and processes which are
> in place. Agitating for separate channels that better suit your
> personal desires for information is just a waste of everyone's time.
I don't agitate for separate channels.
I _insist_ to file dedicated issues for JSR's.
see [4]
> In this case you have seriously misunderstood how the development
> process works. Bug reports are not plans. They are inputs to making
> plans.
This information is false.
Plan items were kept within bugzilla - one example:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
Can anyone within this project explain me, why an _JSR_ is not worth an
dedicated issue?
One was 'accepted', see [5]
> Philippe did you the courtesy of providing you a link to the planning
> document --- which is available to all --- and you return the favour
by pointing out deficiencies within the plan, see [6]
> by implying that he is hiding information and maintaining hidden
> plans.
I've implied that _IBM_ is doing this, see [7] and [8]
[Btw: did you ever worked for IBM?]
> That is *not* how you win friends with anyone.
I don't want to win friends.
I just want that this ungentle IBM team stops hindering my efforts to
file issues for the JSR's, similar to other filed plan items.
[9]
> In any case, this matter is closed --- as are the bug reports.
neither this matter, nor the bug reports were closed.
I just reopened them, having now again the real dependency tree and status:
https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
I ask you friendly to not further ignore my rationales.
> /mike
>
> "ilias" <ilias@lazaridis.com> wrote in message
> news:crbl08$gjo$1@www.eclipse.org...
>
>>>> I ask the relevant organs within the eclipse foundation to
>>>> intervent.
>>
>> Awaiting a reaction.
>>
>> Please ensure the transparency of the development process.
-
> ilias wrote:
>> Philippe Mulet wrote: [moved down into context]
>>
>>> "ilias" <ilias@lazaridis.com> wrote in message
>>> news:cr5sji$i45$1@www.eclipse.org...
>>>
>>>> I ask the relevant organs within the eclipse foundation to
>>>> intervent.
>>
>>
>> Awaiting a reaction.
>>
>> Please ensure the transparency of the development process.
>>
>>>> Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
>>>> in a way which results in a false reflection of the current
>>>> status of the issues and their dependencies.
>>>>
>>>> -
>>>>
[6]
>>>> Reviewing the J2SE 5.0 implementation status, i've found
>>>> information that was out of synch:
>>>>
>>>> this huge "Issue":
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>
>>>> an outdated and inprecise plan, mostly without links to filed
>>>> known issues within bugzilla:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>>
>>> The JDT/Core team is maintaining an accurate status of J2SE 5.0
>>> support on its web page:
>>> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
>>>
>>>
>>
>>
>> The status _was_ not accurate (see provided links above, which
>> proof this).
>>
>> The status _is_ not accurate:
>>
>> * The open and the known issues are not filed. * links were not
>> provided within the plan. * Interdependencies were not shown.
>>
[7]
>> [I am wondering if the team uses an internal system, which is
>> hidden from public.]
>>
[3]
>>>> This "out-of-synch" problem would be reduced, if the plan was
>>>> created out of the bugzilla database, as suggested in this
>>>> thread:
>>>>
>>>> [PROJECT] [BUGZILLA] - Dependency Feature
>>>
>>> http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
[4]
>>>> I've entered within Buzilla (the eclipse Issue Tracking System)
>>>> the following Issue [using current title, initial title was
>>>> different]:
[5]
>>>> [Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>>>
>>>> -
>>>>
>>>> this Issue depends on the implementation (within JDT.Core) of
>>>> the following JSR's:
>>>>
>>>> JSR-201 (contains several parts), JSR-175, JSR-014
>>>>
>>>> Whilst using the dependency-feature of Bugzilla, I've filed
>>>> (after looking for duplicates) the further top-level Issues:
>>>>
>>>> JSR-014 Generics
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>>>
>>>> Implement JSR-175 Metadata Facility (Annotations)
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>>>
>>>> Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
>>>> loops, static imports)
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>>>
>>>> Implement JSR-201, part "static imports"
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>>>
>>>> -
>>>>
>>>> I've interlinked existing issues (and the newly filed
>>>> documented known issues) with use of the dependency feature.
>>
>>
>>> We use the bugzilla databse to track specific defects, and do not
>>> really need an extra (after the fact) dependency tree to mimick
>>> the web page.
>>
>> Your team-driven [users have no influence], out-dated and
>> non-referencing status-report within the projects website is not
>> that relevant.
>>
>> Bugzilla must inform the users, which search there for known
>> issues.
>>
>> The dependecy-tree clarifies the issue-interdependencies, enabling
>> users to detect relevant locations where they can contribute if
>> they like to boost development.
>>
>> Please remember that this is an open-source project.
>>
>>> At this stage in our development cycle, we are trying to solve
>>> all remaining problems in J2SE 5.0 front, and need specific
>>> defects to help us; we have a couple non specific defects which
>>> are representing committed 3.1 plan items,
>>
>> are you refering to this joke of an [plan item] issue:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>
>> which I would personally be ashamed to show to the public?
>>
>>> and do not need extra ones to simply reformulate them (yes I
>>> agree in a clearer way, but still duplicates).
>>
>> So, you really want to continue this arrogant behaviour?
[1]
>> I could expect from an experienced team that it understands the
>> difference between "duplicate" and "depending on" relation.
>>
>>>> You will see within the issues, that Mr. Kent Johnson (IBM)
>>>> _closes_ the issues as INVALID - and as the last action,
>>>> removing dependencies without any justifying comments.
>>>>
[9]
>>>> What happens when a users searches for JSR-175 within Bugzilla?
>>>>
>>>>
>>>> Or JSR-176?
>>>>
>>>> He finds obfuscated data.
>>>>
>>>> -
>>>>
>>>> It looks to me that the team is not intrested in real
>>>> transparency, but just in keeping the open issues as low as
>>>> possible.
>>>>
>>>> Until the JSR's were fully implemented within JDT.Core, the
>>>> filed Issues remain _open_.
>>>>
>>>> This is a _fact_ - and I ask you to keep the Issue tracking
>>>> transparent and honest, whilst reflecting the _real_ status.
>>>>
>>>> I've not the time to continue those close/open games from Mr.
>>>> Kent Johnson (IBM).
>>>>
>>>> -
>>>>
>>>> "JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from
>>>> beeing implemented fully within eclipse JDT.Core - and Bugzilla
>>>> should reflect the correct status.
>>
>>
>>> Basically, your effort should have occurred when the J2SE 5.0
>>> effort started, and you should have better communicated with the
>>> JDT Core team so as not to be disrupting our effort.
>>
>> I think it's a good moment to file the open J2SE 5.0 Issues, which
>> will take a few months to finish.
>>
>> I'm not disrupting your effort (to implement J2SE 5.0 within
>> JDT.Core)
>>
>> But you do disrupt mine (to organize and interlink the known
>> issues)
>>
[2]
>>>> Any JSR is worth a dedicated Issue within Buzilla, thus users
>>>> hit on this information after a search.
>>
>>> I appreciate your no longer reopening unnecessary defects, since
>>> they are inducing false hits in mail notifications; and thanks
>>> for your interest in our J2SE 5.0 effort.
>>
>> So, you think honestly that an JSR is not worth an dedicated Issue?
>>
>> Feel free.
>>
>> As I will feel free to reopen the _perfectly_ valid Issues.
>>
>> The arrogant behaviour [ignoring facts and rationales] of the
>> JDT.Core team (IBM) will not hinder me to increase transparency of
>> the development, whilst using the resources of this project.
>>
>> ....
>>
>> except:
>>
[8]
>> You could state what should become obvious to every reader:
>>
>> "We (IBM) do not want too much transparency within the JDT.Core.
>> That's the reason why everything is kept so terribly unorganized
>> within _one_ component "Core", including the whole compiler [yes,
>> really! the compiler is not an seperated organisational unit]. So,
>> don't expect that we will allow you to create a transparent
>> dependency-tree, thus everyone is able to understand within minutes
>> the status and the interconnections. We will fight this, whilst
>> risking to look like dumbs who do not understand the difference
>> between a duplicate and a depending-on relation. We will even take
>> the risk to state that an JSR is not worth an dedicated issue
>> within bugzilla - and has to be marked as invalid."
>>
>> then I would possibly stop to insist on a transparent issue filing
>> within this project.
..
--
http://lazaridis.com
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9399 is a reply to message #9375] |
Wed, 05 January 2005 23:34 |
Eclipse User |
|
|
|
Originally posted by: myname(with.between names).lombardisoftware.com
I hate to spend time on arguing about this, since Ilias obviously don't
listen to any form of reason, but I seem to be sucked in anyway.
I'm not going to argue who's method in question (JDT teams or Ilias') is
more transparent or better, because frankly it is totally irrelevant.
The main responsibility of a bugtracking system (regardles of where) is to
let the developers and testers know what is broken/wanted enhancements,
what has been fixed and when it was fixed. If any developer deems two
reports they got to be the same, it is to his/her discression alone to join
these two bugs as the tool is for him/her and not the end users (like
myself). If an end user disagrees he/she can state that and explain why
they think so (I've done so several times), but in the end its the
developers who knows if they need both issues open or not to get things
done right, not me or you. In our company, the support group, pre-sellers
and others that has access to our bug tracking system, often gets their
issues closed or duped when they don't think its right, but that's up to me
(or other developers) and not them.
I can complain all I want that an issue is closed or they wont fix it. If I
want something done I always have the possibility to create a patch myself.
And even if they don't like my patch, I can always take the source and
patch it myself. That's the joy of open source.
Reporting/updating of progress, requirements, plans is also not something
anyone _have_ to do either. Again, this is in the sole discression of the
people working on the open source project, not the end user. End users can
suggest changes, but you cannot demand (you can try, but it's the best way
to be ignored fast, I'm sure you have some experience in that :D ). People
mostly do this in their spare time, and they can work on what they want,
not what you want. In fact, if Kent keeps the status of the Java5 project
on a whiteboard in inner Mongolia, that is up to him, not you or me (not
that that's being done, it is just an example). If I wanted more details,
I'll either ask on a group for info (like eclipse.tools.jdt), or send the
people involved an email. If they get enough requests for something, I'm
sure they would make it publically available instead of responding to
everyone individually. But how they keep track of their own progress is not
up to me or you, it is up to them (and whoever they work for if any).
In any case, to sum up:
* Bugzilla is mainly for developers and testers. They can organize it the
way they want, not the way you or I might want.
* Status updates is done when the people involved developing wants to in
the granularity they want to, not when/what you or I want.
* How/If to keep status is up to the developers, not me or you.
- Morten Moeller
Lombardi Software
http://www.lombardisoftware.com/
ilias wrote:
> Mike Milinkovich wrote:
>> I am not sure who you expect to intervene or what you expect "...the
>> relevant organs within the eclipse foundation..." to do.
>
> Resolving.
>
> "abuse of power and position"
>
> [I do not accept this silently, like other users.]
>
>> Everything you have complained about is perfectly transparent. You
>> opened several duplicative and unnecessary bug reports which we
>> closed by the developer(s).
>
> "duplicative" => false (see [1])
> "unnecessary" => false (see [2])
>
>> They were well within their rights to do so.
>
> of course not. [see my requoted rationales below]
>
>> I am satisfied that Kent did the right thing.
>
> I am unsatisfied which your way to ignore the given rationales.
>
>> Here's a suggestion. Rather than trying to convert the Eclipse open
>> source project to work the way to wished it did, why don't you try
>> learning how it actually does work and participating using the same
>> rules of engagement as everyone else?
>
> I know how this weak and non-integrated planning system works, and I've
> already suggested some changes (which you are free to ignore once more):
>
> see [3]
>
>> Eclipse is an open source project. It is run by developers for
>> developers. The Eclipse Foundation is a member-supported
>> not-for-profit organization which is focused on meeting the needs of
>> its members and supporting the requirements of the project
>> developers.
>
> I understand.
>
>> For users to be effective in promoting their interests,
>> they need to communicate using the channels and processes which are
>> in place. Agitating for separate channels that better suit your
>> personal desires for information is just a waste of everyone's time.
>
> I don't agitate for separate channels.
>
> I _insist_ to file dedicated issues for JSR's.
>
> see [4]
>
>> In this case you have seriously misunderstood how the development
>> process works. Bug reports are not plans. They are inputs to making
>> plans.
>
> This information is false.
>
> Plan items were kept within bugzilla - one example:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>
> Can anyone within this project explain me, why an _JSR_ is not worth an
> dedicated issue?
>
> One was 'accepted', see [5]
>
>> Philippe did you the courtesy of providing you a link to the planning
>> document --- which is available to all --- and you return the favour
>
> by pointing out deficiencies within the plan, see [6]
>
>> by implying that he is hiding information and maintaining hidden
>> plans.
>
> I've implied that _IBM_ is doing this, see [7] and [8]
>
> [Btw: did you ever worked for IBM?]
>
>> That is *not* how you win friends with anyone.
>
> I don't want to win friends.
>
> I just want that this ungentle IBM team stops hindering my efforts to
> file issues for the JSR's, similar to other filed plan items.
>
> [9]
>
>> In any case, this matter is closed --- as are the bug reports.
>
> neither this matter, nor the bug reports were closed.
>
> I just reopened them, having now again the real dependency tree and
> status:
>
> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>
> I ask you friendly to not further ignore my rationales.
>
>> /mike
>>
>> "ilias" <ilias@lazaridis.com> wrote in message
>> news:crbl08$gjo$1@www.eclipse.org...
>>
>>>>> I ask the relevant organs within the eclipse foundation to
>>>>> intervent.
>>>
>>> Awaiting a reaction.
>>>
>>> Please ensure the transparency of the development process.
>
> -
>
>> ilias wrote:
>>> Philippe Mulet wrote: [moved down into context]
>>>
>>>> "ilias" <ilias@lazaridis.com> wrote in message
>>>> news:cr5sji$i45$1@www.eclipse.org...
>>>>
>>>>> I ask the relevant organs within the eclipse foundation to
>>>>> intervent.
>>>
>>>
>>> Awaiting a reaction.
>>>
>>> Please ensure the transparency of the development process.
>>>
>>>>> Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
>>>>> in a way which results in a false reflection of the current
>>>>> status of the issues and their dependencies.
>>>>>
>>>>> -
>>>>>
>
> [6]
>
>>>>> Reviewing the J2SE 5.0 implementation status, i've found
>>>>> information that was out of synch:
>>>>>
>>>>> this huge "Issue":
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>
>>>>> an outdated and inprecise plan, mostly without links to filed
>>>>> known issues within bugzilla:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>>>>
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>>>
>>>> The JDT/Core team is maintaining an accurate status of J2SE 5.0
>>>> support on its web page:
>>>>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
>>>>
>>>>
>>>
>>>
>>> The status _was_ not accurate (see provided links above, which
>>> proof this).
>>>
>>> The status _is_ not accurate:
>>>
>>> * The open and the known issues are not filed. * links were not
>>> provided within the plan. * Interdependencies were not shown.
>>>
>
> [7]
>
>>> [I am wondering if the team uses an internal system, which is
>>> hidden from public.]
>>>
>
> [3]
>
>>>>> This "out-of-synch" problem would be reduced, if the plan was
>>>>> created out of the bugzilla database, as suggested in this
>>>>> thread:
>>>>>
>>>>> [PROJECT] [BUGZILLA] - Dependency Feature
>>>>
>>>>
http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>
> [4]
>
>>>>> I've entered within Buzilla (the eclipse Issue Tracking System)
>>>>> the following Issue [using current title, initial title was
>>>>> different]:
>
> [5]
>
>>>>> [Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>>>>
>>>>> -
>>>>>
>>>>> this Issue depends on the implementation (within JDT.Core) of
>>>>> the following JSR's:
>>>>>
>>>>> JSR-201 (contains several parts), JSR-175, JSR-014
>>>>>
>>>>> Whilst using the dependency-feature of Bugzilla, I've filed
>>>>> (after looking for duplicates) the further top-level Issues:
>>>>>
>>>>> JSR-014 Generics
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>>>>
>>>>> Implement JSR-175 Metadata Facility (Annotations)
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>>>>
>>>>> Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
>>>>> loops, static imports)
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>>>>
>>>>> Implement JSR-201, part "static imports"
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>>>>
>>>>> -
>>>>>
>>>>> I've interlinked existing issues (and the newly filed
>>>>> documented known issues) with use of the dependency feature.
>>>
>>>
>>>> We use the bugzilla databse to track specific defects, and do not
>>>> really need an extra (after the fact) dependency tree to mimick
>>>> the web page.
>>>
>>> Your team-driven [users have no influence], out-dated and
>>> non-referencing status-report within the projects website is not
>>> that relevant.
>>>
>>> Bugzilla must inform the users, which search there for known
>>> issues.
>>>
>>> The dependecy-tree clarifies the issue-interdependencies, enabling
>>> users to detect relevant locations where they can contribute if
>>> they like to boost development.
>>>
>>> Please remember that this is an open-source project.
>>>
>>>> At this stage in our development cycle, we are trying to solve
>>>> all remaining problems in J2SE 5.0 front, and need specific
>>>> defects to help us; we have a couple non specific defects which
>>>> are representing committed 3.1 plan items,
>>>
>>> are you refering to this joke of an [plan item] issue:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>
>>> which I would personally be ashamed to show to the public?
>>>
>>>> and do not need extra ones to simply reformulate them (yes I
>>>> agree in a clearer way, but still duplicates).
>>>
>>> So, you really want to continue this arrogant behaviour?
>
> [1]
>
>>> I could expect from an experienced team that it understands the
>>> difference between "duplicate" and "depending on" relation.
>>>
>>>>> You will see within the issues, that Mr. Kent Johnson (IBM)
>>>>> _closes_ the issues as INVALID - and as the last action,
>>>>> removing dependencies without any justifying comments.
>>>>>
>
> [9]
>
>>>>> What happens when a users searches for JSR-175 within Bugzilla?
>>>>>
>>>>>
>>>>> Or JSR-176?
>>>>>
>>>>> He finds obfuscated data.
>>>>>
>>>>> -
>>>>>
>>>>> It looks to me that the team is not intrested in real
>>>>> transparency, but just in keeping the open issues as low as
>>>>> possible.
>>>>>
>>>>> Until the JSR's were fully implemented within JDT.Core, the
>>>>> filed Issues remain _open_.
>>>>>
>>>>> This is a _fact_ - and I ask you to keep the Issue tracking
>>>>> transparent and honest, whilst reflecting the _real_ status.
>>>>>
>>>>> I've not the time to continue those close/open games from Mr.
>>>>> Kent Johnson (IBM).
>>>>>
>>>>> -
>>>>>
>>>>> "JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from
>>>>> beeing implemented fully within eclipse JDT.Core - and Bugzilla
>>>>> should reflect the correct status.
>>>
>>>
>>>> Basically, your effort should have occurred when the J2SE 5.0
>>>> effort started, and you should have better communicated with the
>>>> JDT Core team so as not to be disrupting our effort.
>>>
>>> I think it's a good moment to file the open J2SE 5.0 Issues, which
>>> will take a few months to finish.
>>>
>>> I'm not disrupting your effort (to implement J2SE 5.0 within
>>> JDT.Core)
>>>
>>> But you do disrupt mine (to organize and interlink the known
>>> issues)
>>>
>
> [2]
>
>>>>> Any JSR is worth a dedicated Issue within Buzilla, thus users
>>>>> hit on this information after a search.
>>>
>>>> I appreciate your no longer reopening unnecessary defects, since
>>>> they are inducing false hits in mail notifications; and thanks
>>>> for your interest in our J2SE 5.0 effort.
>>>
>>> So, you think honestly that an JSR is not worth an dedicated Issue?
>>>
>>> Feel free.
>>>
>>> As I will feel free to reopen the _perfectly_ valid Issues.
>>>
>>> The arrogant behaviour [ignoring facts and rationales] of the
>>> JDT.Core team (IBM) will not hinder me to increase transparency of
>>> the development, whilst using the resources of this project.
>>>
>>> ....
>>>
>>> except:
>>>
>
> [8]
>
>>> You could state what should become obvious to every reader:
>>>
>>> "We (IBM) do not want too much transparency within the JDT.Core.
>>> That's the reason why everything is kept so terribly unorganized
>>> within _one_ component "Core", including the whole compiler [yes,
>>> really! the compiler is not an seperated organisational unit]. So,
>>> don't expect that we will allow you to create a transparent
>>> dependency-tree, thus everyone is able to understand within minutes
>>> the status and the interconnections. We will fight this, whilst
>>> risking to look like dumbs who do not understand the difference
>>> between a duplicate and a depending-on relation. We will even take
>>> the risk to state that an JSR is not worth an dedicated issue
>>> within bugzilla - and has to be marked as invalid."
>>>
>>> then I would possibly stop to insist on a transparent issue filing
>>> within this project.
>
> .
>
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9424 is a reply to message #9375] |
Thu, 06 January 2005 01:25 |
Mike Milinkovich Messages: 260 Registered: July 2009 |
Senior Member |
|
|
Ilias,
Please read Morten's excellent summary of how bug reporting gets done.
Doing their job is not an "abuse of power and position". Like I said, I am
satisfied that Kent did the right thing.
If you persist in re-opening bug reports which have been closed by the
developers, I will unfortunately have no recourse but to look into
terminating your access to our Bugzilla systems.
/mike
"ilias" <ilias@lazaridis.com> wrote in message
news:crheh8$sda$1@www.eclipse.org...
> Mike Milinkovich wrote:
>> I am not sure who you expect to intervene or what you expect "...the
>> relevant organs within the eclipse foundation..." to do.
>
> Resolving.
>
> "abuse of power and position"
>
> [I do not accept this silently, like other users.]
>
>> Everything you have complained about is perfectly transparent. You
>> opened several duplicative and unnecessary bug reports which we
>> closed by the developer(s).
>
> "duplicative" => false (see [1])
> "unnecessary" => false (see [2])
>
>> They were well within their rights to do so.
>
> of course not. [see my requoted rationales below]
>
>> I am satisfied that Kent did the right thing.
>
> I am unsatisfied which your way to ignore the given rationales.
>
>> Here's a suggestion. Rather than trying to convert the Eclipse open
>> source project to work the way to wished it did, why don't you try
>> learning how it actually does work and participating using the same
>> rules of engagement as everyone else?
>
> I know how this weak and non-integrated planning system works, and I've
> already suggested some changes (which you are free to ignore once more):
>
> see [3]
>
>> Eclipse is an open source project. It is run by developers for
>> developers. The Eclipse Foundation is a member-supported
>> not-for-profit organization which is focused on meeting the needs of
>> its members and supporting the requirements of the project
>> developers.
>
> I understand.
>
>> For users to be effective in promoting their interests,
>> they need to communicate using the channels and processes which are
>> in place. Agitating for separate channels that better suit your
>> personal desires for information is just a waste of everyone's time.
>
> I don't agitate for separate channels.
>
> I _insist_ to file dedicated issues for JSR's.
>
> see [4]
>
>> In this case you have seriously misunderstood how the development
>> process works. Bug reports are not plans. They are inputs to making
>> plans.
>
> This information is false.
>
> Plan items were kept within bugzilla - one example:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>
> Can anyone within this project explain me, why an _JSR_ is not worth an
> dedicated issue?
>
> One was 'accepted', see [5]
>
>> Philippe did you the courtesy of providing you a link to the planning
>> document --- which is available to all --- and you return the favour
>
> by pointing out deficiencies within the plan, see [6]
>
>> by implying that he is hiding information and maintaining hidden
>> plans.
>
> I've implied that _IBM_ is doing this, see [7] and [8]
>
> [Btw: did you ever worked for IBM?]
>
>> That is *not* how you win friends with anyone.
>
> I don't want to win friends.
>
> I just want that this ungentle IBM team stops hindering my efforts to file
> issues for the JSR's, similar to other filed plan items.
>
> [9]
>
>> In any case, this matter is closed --- as are the bug reports.
>
> neither this matter, nor the bug reports were closed.
>
> I just reopened them, having now again the real dependency tree and
> status:
>
> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>
> I ask you friendly to not further ignore my rationales.
>
>> /mike
>>
>> "ilias" <ilias@lazaridis.com> wrote in message
>> news:crbl08$gjo$1@www.eclipse.org...
>>
>>>>> I ask the relevant organs within the eclipse foundation to intervent.
>>>
>>> Awaiting a reaction.
>>>
>>> Please ensure the transparency of the development process.
>
> -
>
>> ilias wrote:
>>> Philippe Mulet wrote: [moved down into context]
>>>
>>>> "ilias" <ilias@lazaridis.com> wrote in message
>>>> news:cr5sji$i45$1@www.eclipse.org...
>>>>
>>>>> I ask the relevant organs within the eclipse foundation to intervent.
>>>
>>>
>>> Awaiting a reaction.
>>>
>>> Please ensure the transparency of the development process.
>>>
>>>>> Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
>>>>> in a way which results in a false reflection of the current
>>>>> status of the issues and their dependencies.
>>>>>
>>>>> -
>>>>>
>
> [6]
>
>>>>> Reviewing the J2SE 5.0 implementation status, i've found information
>>>>> that was out of synch:
>>>>>
>>>>> this huge "Issue":
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>
>>>>> an outdated and inprecise plan, mostly without links to filed
>>>>> known issues within bugzilla:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>>>>
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>>>
>>>> The JDT/Core team is maintaining an accurate status of J2SE 5.0 support
>>>> on its web page:
>>>> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
>>>>
>>>>
>>>
>>>
>>> The status _was_ not accurate (see provided links above, which
>>> proof this).
>>>
>>> The status _is_ not accurate:
>>>
>>> * The open and the known issues are not filed. * links were not
>>> provided within the plan. * Interdependencies were not shown.
>>>
>
> [7]
>
>>> [I am wondering if the team uses an internal system, which is
>>> hidden from public.]
>>>
>
> [3]
>
>>>>> This "out-of-synch" problem would be reduced, if the plan was created
>>>>> out of the bugzilla database, as suggested in this
>>>>> thread:
>>>>>
>>>>> [PROJECT] [BUGZILLA] - Dependency Feature
>>>>
>>>> http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>
> [4]
>
>>>>> I've entered within Buzilla (the eclipse Issue Tracking System)
>>>>> the following Issue [using current title, initial title was
>>>>> different]:
>
> [5]
>
>>>>> [Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>>>>
>>>>> -
>>>>>
>>>>> this Issue depends on the implementation (within JDT.Core) of
>>>>> the following JSR's:
>>>>>
>>>>> JSR-201 (contains several parts), JSR-175, JSR-014
>>>>>
>>>>> Whilst using the dependency-feature of Bugzilla, I've filed
>>>>> (after looking for duplicates) the further top-level Issues:
>>>>>
>>>>> JSR-014 Generics
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>>>>
>>>>> Implement JSR-175 Metadata Facility (Annotations)
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>>>>
>>>>> Implement JSR-201 (enumerations, autoboxing, varargs, enhanced loops,
>>>>> static imports) https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>>>>
>>>>> Implement JSR-201, part "static imports"
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>>>>
>>>>> -
>>>>>
>>>>> I've interlinked existing issues (and the newly filed
>>>>> documented known issues) with use of the dependency feature.
>>>
>>>
>>>> We use the bugzilla databse to track specific defects, and do not
>>>> really need an extra (after the fact) dependency tree to mimick
>>>> the web page.
>>>
>>> Your team-driven [users have no influence], out-dated and
>>> non-referencing status-report within the projects website is not
>>> that relevant.
>>>
>>> Bugzilla must inform the users, which search there for known
>>> issues.
>>>
>>> The dependecy-tree clarifies the issue-interdependencies, enabling
>>> users to detect relevant locations where they can contribute if
>>> they like to boost development.
>>>
>>> Please remember that this is an open-source project.
>>>
>>>> At this stage in our development cycle, we are trying to solve
>>>> all remaining problems in J2SE 5.0 front, and need specific defects to
>>>> help us; we have a couple non specific defects which
>>>> are representing committed 3.1 plan items,
>>>
>>> are you refering to this joke of an [plan item] issue:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>
>>> which I would personally be ashamed to show to the public?
>>>
>>>> and do not need extra ones to simply reformulate them (yes I
>>>> agree in a clearer way, but still duplicates).
>>>
>>> So, you really want to continue this arrogant behaviour?
>
> [1]
>
>>> I could expect from an experienced team that it understands the
>>> difference between "duplicate" and "depending on" relation.
>>>
>>>>> You will see within the issues, that Mr. Kent Johnson (IBM) _closes_
>>>>> the issues as INVALID - and as the last action,
>>>>> removing dependencies without any justifying comments.
>>>>>
>
> [9]
>
>>>>> What happens when a users searches for JSR-175 within Bugzilla?
>>>>>
>>>>>
>>>>> Or JSR-176?
>>>>>
>>>>> He finds obfuscated data.
>>>>>
>>>>> -
>>>>>
>>>>> It looks to me that the team is not intrested in real
>>>>> transparency, but just in keeping the open issues as low as
>>>>> possible.
>>>>>
>>>>> Until the JSR's were fully implemented within JDT.Core, the
>>>>> filed Issues remain _open_.
>>>>>
>>>>> This is a _fact_ - and I ask you to keep the Issue tracking
>>>>> transparent and honest, whilst reflecting the _real_ status.
>>>>>
>>>>> I've not the time to continue those close/open games from Mr.
>>>>> Kent Johnson (IBM).
>>>>>
>>>>> -
>>>>>
>>>>> "JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
>>>>> implemented fully within eclipse JDT.Core - and Bugzilla
>>>>> should reflect the correct status.
>>>
>>>
>>>> Basically, your effort should have occurred when the J2SE 5.0
>>>> effort started, and you should have better communicated with the
>>>> JDT Core team so as not to be disrupting our effort.
>>>
>>> I think it's a good moment to file the open J2SE 5.0 Issues, which
>>> will take a few months to finish.
>>>
>>> I'm not disrupting your effort (to implement J2SE 5.0 within
>>> JDT.Core)
>>>
>>> But you do disrupt mine (to organize and interlink the known
>>> issues)
>>>
>
> [2]
>
>>>>> Any JSR is worth a dedicated Issue within Buzilla, thus users
>>>>> hit on this information after a search.
>>>
>>>> I appreciate your no longer reopening unnecessary defects, since
>>>> they are inducing false hits in mail notifications; and thanks
>>>> for your interest in our J2SE 5.0 effort.
>>>
>>> So, you think honestly that an JSR is not worth an dedicated Issue?
>>>
>>> Feel free.
>>>
>>> As I will feel free to reopen the _perfectly_ valid Issues.
>>>
>>> The arrogant behaviour [ignoring facts and rationales] of the
>>> JDT.Core team (IBM) will not hinder me to increase transparency of
>>> the development, whilst using the resources of this project.
>>>
>>> ....
>>>
>>> except:
>>>
>
> [8]
>
>>> You could state what should become obvious to every reader:
>>>
>>> "We (IBM) do not want too much transparency within the JDT.Core.
>>> That's the reason why everything is kept so terribly unorganized
>>> within _one_ component "Core", including the whole compiler [yes,
>>> really! the compiler is not an seperated organisational unit]. So,
>>> don't expect that we will allow you to create a transparent
>>> dependency-tree, thus everyone is able to understand within minutes
>>> the status and the interconnections. We will fight this, whilst
>>> risking to look like dumbs who do not understand the difference
>>> between a duplicate and a depending-on relation. We will even take
>>> the risk to state that an JSR is not worth an dedicated issue
>>> within bugzilla - and has to be marked as invalid."
>>>
>>> then I would possibly stop to insist on a transparent issue filing
>>> within this project.
>
> .
>
> --
> http://lazaridis.com
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9450 is a reply to message #9424] |
Thu, 06 January 2005 10:44 |
Philippe Mulet Messages: 229 Registered: July 2009 |
Senior Member |
|
|
I closed all offending PRs again. Leaving only one which provides actual
value (https://bugs.eclipse.org/bugs/show_bug.cgi?id=81974).
"Mike Milinkovich" <mike.milinkovich@eclipse.org> wrote in message
news:cri431$q2$1@www.eclipse.org...
> Ilias,
>
> Please read Morten's excellent summary of how bug reporting gets done.
>
> Doing their job is not an "abuse of power and position". Like I said, I am
> satisfied that Kent did the right thing.
>
> If you persist in re-opening bug reports which have been closed by the
> developers, I will unfortunately have no recourse but to look into
> terminating your access to our Bugzilla systems.
>
> /mike
>
> "ilias" <ilias@lazaridis.com> wrote in message
> news:crheh8$sda$1@www.eclipse.org...
> > Mike Milinkovich wrote:
> >> I am not sure who you expect to intervene or what you expect "...the
> >> relevant organs within the eclipse foundation..." to do.
> >
> > Resolving.
> >
> > "abuse of power and position"
> >
> > [I do not accept this silently, like other users.]
> >
> >> Everything you have complained about is perfectly transparent. You
> >> opened several duplicative and unnecessary bug reports which we
> >> closed by the developer(s).
> >
> > "duplicative" => false (see [1])
> > "unnecessary" => false (see [2])
> >
> >> They were well within their rights to do so.
> >
> > of course not. [see my requoted rationales below]
> >
> >> I am satisfied that Kent did the right thing.
> >
> > I am unsatisfied which your way to ignore the given rationales.
> >
> >> Here's a suggestion. Rather than trying to convert the Eclipse open
> >> source project to work the way to wished it did, why don't you try
> >> learning how it actually does work and participating using the same
> >> rules of engagement as everyone else?
> >
> > I know how this weak and non-integrated planning system works, and I've
> > already suggested some changes (which you are free to ignore once more):
> >
> > see [3]
> >
> >> Eclipse is an open source project. It is run by developers for
> >> developers. The Eclipse Foundation is a member-supported
> >> not-for-profit organization which is focused on meeting the needs of
> >> its members and supporting the requirements of the project
> >> developers.
> >
> > I understand.
> >
> >> For users to be effective in promoting their interests,
> >> they need to communicate using the channels and processes which are
> >> in place. Agitating for separate channels that better suit your
> >> personal desires for information is just a waste of everyone's time.
> >
> > I don't agitate for separate channels.
> >
> > I _insist_ to file dedicated issues for JSR's.
> >
> > see [4]
> >
> >> In this case you have seriously misunderstood how the development
> >> process works. Bug reports are not plans. They are inputs to making
> >> plans.
> >
> > This information is false.
> >
> > Plan items were kept within bugzilla - one example:
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
> >
> > Can anyone within this project explain me, why an _JSR_ is not worth an
> > dedicated issue?
> >
> > One was 'accepted', see [5]
> >
> >> Philippe did you the courtesy of providing you a link to the planning
> >> document --- which is available to all --- and you return the favour
> >
> > by pointing out deficiencies within the plan, see [6]
> >
> >> by implying that he is hiding information and maintaining hidden
> >> plans.
> >
> > I've implied that _IBM_ is doing this, see [7] and [8]
> >
> > [Btw: did you ever worked for IBM?]
> >
> >> That is *not* how you win friends with anyone.
> >
> > I don't want to win friends.
> >
> > I just want that this ungentle IBM team stops hindering my efforts to
file
> > issues for the JSR's, similar to other filed plan items.
> >
> > [9]
> >
> >> In any case, this matter is closed --- as are the bug reports.
> >
> > neither this matter, nor the bug reports were closed.
> >
> > I just reopened them, having now again the real dependency tree and
> > status:
> >
> > https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
> >
> > I ask you friendly to not further ignore my rationales.
> >
> >> /mike
> >>
> >> "ilias" <ilias@lazaridis.com> wrote in message
> >> news:crbl08$gjo$1@www.eclipse.org...
> >>
> >>>>> I ask the relevant organs within the eclipse foundation to
intervent.
> >>>
> >>> Awaiting a reaction.
> >>>
> >>> Please ensure the transparency of the development process.
> >
> > -
> >
> >> ilias wrote:
> >>> Philippe Mulet wrote: [moved down into context]
> >>>
> >>>> "ilias" <ilias@lazaridis.com> wrote in message
> >>>> news:cr5sji$i45$1@www.eclipse.org...
> >>>>
> >>>>> I ask the relevant organs within the eclipse foundation to
intervent.
> >>>
> >>>
> >>> Awaiting a reaction.
> >>>
> >>> Please ensure the transparency of the development process.
> >>>
> >>>>> Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
> >>>>> in a way which results in a false reflection of the current
> >>>>> status of the issues and their dependencies.
> >>>>>
> >>>>> -
> >>>>>
> >
> > [6]
> >
> >>>>> Reviewing the J2SE 5.0 implementation status, i've found information
> >>>>> that was out of synch:
> >>>>>
> >>>>> this huge "Issue":
> >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
> >>>>>
> >>>>> an outdated and inprecise plan, mostly without links to filed
> >>>>> known issues within bugzilla:
> >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
> >>>>>
> >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
> >>>
> >>>> The JDT/Core team is maintaining an accurate status of J2SE 5.0
support
> >>>> on its web page:
> >>>>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
> >>>>
> >>>>
> >>>
> >>>
> >>> The status _was_ not accurate (see provided links above, which
> >>> proof this).
> >>>
> >>> The status _is_ not accurate:
> >>>
> >>> * The open and the known issues are not filed. * links were not
> >>> provided within the plan. * Interdependencies were not shown.
> >>>
> >
> > [7]
> >
> >>> [I am wondering if the team uses an internal system, which is
> >>> hidden from public.]
> >>>
> >
> > [3]
> >
> >>>>> This "out-of-synch" problem would be reduced, if the plan was
created
> >>>>> out of the bugzilla database, as suggested in this
> >>>>> thread:
> >>>>>
> >>>>> [PROJECT] [BUGZILLA] - Dependency Feature
> >>>>
> >>>>
http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
> >
> > [4]
> >
> >>>>> I've entered within Buzilla (the eclipse Issue Tracking System)
> >>>>> the following Issue [using current title, initial title was
> >>>>> different]:
> >
> > [5]
> >
> >>>>> [Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
> >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
> >>>>>
> >>>>> -
> >>>>>
> >>>>> this Issue depends on the implementation (within JDT.Core) of
> >>>>> the following JSR's:
> >>>>>
> >>>>> JSR-201 (contains several parts), JSR-175, JSR-014
> >>>>>
> >>>>> Whilst using the dependency-feature of Bugzilla, I've filed
> >>>>> (after looking for duplicates) the further top-level Issues:
> >>>>>
> >>>>> JSR-014 Generics
> >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
> >>>>>
> >>>>> Implement JSR-175 Metadata Facility (Annotations)
> >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
> >>>>>
> >>>>> Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
loops,
> >>>>> static imports) https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
> >>>>>
> >>>>> Implement JSR-201, part "static imports"
> >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
> >>>>>
> >>>>> -
> >>>>>
> >>>>> I've interlinked existing issues (and the newly filed
> >>>>> documented known issues) with use of the dependency feature.
> >>>
> >>>
> >>>> We use the bugzilla databse to track specific defects, and do not
> >>>> really need an extra (after the fact) dependency tree to mimick
> >>>> the web page.
> >>>
> >>> Your team-driven [users have no influence], out-dated and
> >>> non-referencing status-report within the projects website is not
> >>> that relevant.
> >>>
> >>> Bugzilla must inform the users, which search there for known
> >>> issues.
> >>>
> >>> The dependecy-tree clarifies the issue-interdependencies, enabling
> >>> users to detect relevant locations where they can contribute if
> >>> they like to boost development.
> >>>
> >>> Please remember that this is an open-source project.
> >>>
> >>>> At this stage in our development cycle, we are trying to solve
> >>>> all remaining problems in J2SE 5.0 front, and need specific defects
to
> >>>> help us; we have a couple non specific defects which
> >>>> are representing committed 3.1 plan items,
> >>>
> >>> are you refering to this joke of an [plan item] issue:
> >>>
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
> >>>
> >>> which I would personally be ashamed to show to the public?
> >>>
> >>>> and do not need extra ones to simply reformulate them (yes I
> >>>> agree in a clearer way, but still duplicates).
> >>>
> >>> So, you really want to continue this arrogant behaviour?
> >
> > [1]
> >
> >>> I could expect from an experienced team that it understands the
> >>> difference between "duplicate" and "depending on" relation.
> >>>
> >>>>> You will see within the issues, that Mr. Kent Johnson (IBM) _closes_
> >>>>> the issues as INVALID - and as the last action,
> >>>>> removing dependencies without any justifying comments.
> >>>>>
> >
> > [9]
> >
> >>>>> What happens when a users searches for JSR-175 within Bugzilla?
> >>>>>
> >>>>>
> >>>>> Or JSR-176?
> >>>>>
> >>>>> He finds obfuscated data.
> >>>>>
> >>>>> -
> >>>>>
> >>>>> It looks to me that the team is not intrested in real
> >>>>> transparency, but just in keeping the open issues as low as
> >>>>> possible.
> >>>>>
> >>>>> Until the JSR's were fully implemented within JDT.Core, the
> >>>>> filed Issues remain _open_.
> >>>>>
> >>>>> This is a _fact_ - and I ask you to keep the Issue tracking
> >>>>> transparent and honest, whilst reflecting the _real_ status.
> >>>>>
> >>>>> I've not the time to continue those close/open games from Mr.
> >>>>> Kent Johnson (IBM).
> >>>>>
> >>>>> -
> >>>>>
> >>>>> "JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
> >>>>> implemented fully within eclipse JDT.Core - and Bugzilla
> >>>>> should reflect the correct status.
> >>>
> >>>
> >>>> Basically, your effort should have occurred when the J2SE 5.0
> >>>> effort started, and you should have better communicated with the
> >>>> JDT Core team so as not to be disrupting our effort.
> >>>
> >>> I think it's a good moment to file the open J2SE 5.0 Issues, which
> >>> will take a few months to finish.
> >>>
> >>> I'm not disrupting your effort (to implement J2SE 5.0 within
> >>> JDT.Core)
> >>>
> >>> But you do disrupt mine (to organize and interlink the known
> >>> issues)
> >>>
> >
> > [2]
> >
> >>>>> Any JSR is worth a dedicated Issue within Buzilla, thus users
> >>>>> hit on this information after a search.
> >>>
> >>>> I appreciate your no longer reopening unnecessary defects, since
> >>>> they are inducing false hits in mail notifications; and thanks
> >>>> for your interest in our J2SE 5.0 effort.
> >>>
> >>> So, you think honestly that an JSR is not worth an dedicated Issue?
> >>>
> >>> Feel free.
> >>>
> >>> As I will feel free to reopen the _perfectly_ valid Issues.
> >>>
> >>> The arrogant behaviour [ignoring facts and rationales] of the
> >>> JDT.Core team (IBM) will not hinder me to increase transparency of
> >>> the development, whilst using the resources of this project.
> >>>
> >>> ....
> >>>
> >>> except:
> >>>
> >
> > [8]
> >
> >>> You could state what should become obvious to every reader:
> >>>
> >>> "We (IBM) do not want too much transparency within the JDT.Core.
> >>> That's the reason why everything is kept so terribly unorganized
> >>> within _one_ component "Core", including the whole compiler [yes,
> >>> really! the compiler is not an seperated organisational unit]. So,
> >>> don't expect that we will allow you to create a transparent
> >>> dependency-tree, thus everyone is able to understand within minutes
> >>> the status and the interconnections. We will fight this, whilst
> >>> risking to look like dumbs who do not understand the difference
> >>> between a duplicate and a depending-on relation. We will even take
> >>> the risk to state that an JSR is not worth an dedicated issue
> >>> within bugzilla - and has to be marked as invalid."
> >>>
> >>> then I would possibly stop to insist on a transparent issue filing
> >>> within this project.
> >
> > .
> >
> > --
> > http://lazaridis.com
>
>
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9473 is a reply to message #9399] |
Thu, 06 January 2005 12:41 |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
Morten Moeller wrote:
> I hate to spend time on arguing about this, since Ilias obviously don't
> listen to any form of reason, but I seem to be sucked in anyway.
?
> I'm not going to argue who's method in question (JDT teams or Ilias') is
> more transparent or better, because frankly it is totally irrelevant.
of course it is not irrelevant.
Transparency is a _requirement_ of the Eclipse Foundation.
> The main responsibility of a bugtracking system (regardles of where) is to
[...] - (general and personal project comments, not applicable to eclipse)
>
> Reporting/updating of progress, requirements, plans is also not something
> anyone _have_ to do either. Again, this is in the sole discression of the
> people working on the open source project, not the end user.
[...]
the above information is false.
plan _transparency_ is a requirement of the Eclipse Foundation.
[...] - (further comments not processed, as writer is missinformed about
the eclipse foundation development process).
you should read the bylaws and further documents of the Eclipse Foundation.
> In any case, to sum up:
>
> * Bugzilla is mainly for developers and testers. They can organize it the
> way they want, not the way you or I might want.
> * Status updates is done when the people involved developing wants to in
> the granularity they want to, not when/what you or I want.
> * How/If to keep status is up to the developers, not me or you.
You have really a _very_ false view of the eclipse Foundations
Development process.
They are much more liberal as they know.
..
--
http://lazaridis.com
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9495 is a reply to message #9424] |
Thu, 06 January 2005 13:32 |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
Mike Milinkovich wrote:
> Ilias,
>
> Please read Morten's excellent summary of how bug reporting gets done.
I've read it, but he's obivously very missinformed about the eclipse
foundations development process.
I'm wondering that you rate it as "excellent".
Didn't you detect that his writing were generally, and would violate
eclipse foundations tranparency directive?
or did you read just the final summary:
" * Bugzilla is mainly for developers and testers. They can organize
it the way they want, not the way you or I might want.
* Status updates is done when the people involved developing wants
to in the granularity they want to, not when/what you or I want.
* How/If to keep status is up to the developers, not me or you.
"
which is again not valid for the eclipse foundation.
> Doing their job is not an "abuse of power and position".
Declaring valid Issues (which affect JSR's) as invalid, whilst closing
them is not their job.
Disrupting a valid user contributed dependency tree, which reflects
reality, without any justifications is not their job:
https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
> Like I said, I am satisfied that Kent did the right thing.
To keep bugzilla saying that J2SE 5.0 is implemented within JDT.Core?
The right thing for whom?
For the users, which search for information within bugzilla?
Or for the IBM marketin machine?
> If you persist in re-opening bug reports which have been closed by the
> developers, I will unfortunately have no recourse but to look into
> terminating your access to our Bugzilla systems.
You are "satisfied" with the abusive behaviour of the JDT.Core team.
Thus I believe that you will not resist to abuse your power and position
to terminate my access.
I've just reopened the dedicated issues, thus a user which searches
within bugzilla sees the real status of the JSR's:
JSR-176 J2SE 5.0 (Tiger) Release Contents
Implement JSR-201 (enumerations, autoboxing, varargs, enhanced loops,
static imports)
Implement JSR-175 Metadata Facility (Annotations)
Implement JSR-014 Generics
The dependency shows now the correct status:
https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
[note to readers: I've not recreated the dependencies, which IBM
employees have removed, to showcase the reduced transparency]
-
btw: can you please answer the open questions below.
-
>>Plan items were kept within bugzilla - one example:
>>
>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>>
>>Can anyone within this project explain me, why an _JSR_ is not worth an
>>dedicated issue?
?
>>[Btw: did you ever worked for IBM?]
?
>>I ask you friendly to not further ignore my rationales.
>>>>Please ensure the transparency of the development process.
>>>>You could state what should become obvious to every reader:
..
--
http://lazaridis.com
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9519 is a reply to message #9450] |
Thu, 06 January 2005 13:47 |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
Philippe Mulet wrote:
> I closed all offending PRs again. Leaving only one which provides actual
> value (https://bugs.eclipse.org/bugs/show_bug.cgi?id=81974).
[...]
"offending"
What is "offending" with issues which subject JSR's?
Are they offending to users, which hit immedieatly on the JSR, whilst
seeing immediately the status _and_ the exact interconnection of the
issues (transparency)?
Or are they offending for the IBM JDT.Core team, as they show their
inability to fulfill the implementation?
JSR-176, JSR-175, JSR-014, JSR-201
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
4 entries for 4 JSR's.
The IBM team closes those issues, without those JSR's being fully
implemented within JDT.Core.
The eclipse foundation director supports this irrational behaviour,
which _violates_ the defined development proecesses of the foundation.
Once more my question: did the eclipse director worked in the past for IBM?
>>>Can anyone within this project explain me, why an _JSR_ is not worth an
>>>dedicated issue?
>>>
>>>One was 'accepted', see [5]
[...]
[ note to readers: as you can see, the IBM team has found again a lame
excuse to close this issue, too:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775#c14 ]
>>>[5]
>>>>>>>[Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
[...]
>>>>>You could state what should become obvious to every reader:
>>>>>
>>>>>"We (IBM) do not want too much transparency within the JDT.Core.
>>>>>That's the reason why everything is kept so terribly unorganized
>>>>>within _one_ component "Core", including the whole compiler [yes,
>>>>>really! the compiler is not an seperated organisational unit]. So,
>>>>>don't expect that we will allow you to create a transparent
>>>>>dependency-tree, thus everyone is able to understand within minutes
>>>>>the status and the interconnections. We will fight this, whilst
>>>>>risking to look like dumbs who do not understand the difference
>>>>>between a duplicate and a depending-on relation. We will even take
>>>>>the risk to state that an JSR is not worth an dedicated issue
>>>>>within bugzilla - and has to be marked as invalid."
>>>>>
>>>>>then I would possibly stop to insist on a transparent issue filing
>>>>> within this project.
..
--
http://lazaridis.com
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9545 is a reply to message #9450] |
Thu, 06 January 2005 14:03 |
Eclipse Webmaster Messages: 607343 Registered: July 2009 |
Senior Member |
|
|
Philippe,
Please feel free to log bugs in the Bugzilla component of the
"Community" product if you feel there is a bug with the Buzgilla
tracking system that affects the Community.
Denis
Philippe Mulet wrote:
> I closed all offending PRs again. Leaving only one which provides actual
> value (https://bugs.eclipse.org/bugs/show_bug.cgi?id=81974).
>
> "Mike Milinkovich" <mike.milinkovich@eclipse.org> wrote in message
> news:cri431$q2$1@www.eclipse.org...
>
>>Ilias,
>>
>>Please read Morten's excellent summary of how bug reporting gets done.
>>
>>Doing their job is not an "abuse of power and position". Like I said, I am
>>satisfied that Kent did the right thing.
>>
>>If you persist in re-opening bug reports which have been closed by the
>>developers, I will unfortunately have no recourse but to look into
>>terminating your access to our Bugzilla systems.
>>
>>/mike
>>
>>"ilias" <ilias@lazaridis.com> wrote in message
>>news:crheh8$sda$1@www.eclipse.org...
>>
>>>Mike Milinkovich wrote:
>>>
>>>>I am not sure who you expect to intervene or what you expect "...the
>>>> relevant organs within the eclipse foundation..." to do.
>>>
>>>Resolving.
>>>
>>>"abuse of power and position"
>>>
>>>[I do not accept this silently, like other users.]
>>>
>>>
>>>>Everything you have complained about is perfectly transparent. You
>>>>opened several duplicative and unnecessary bug reports which we
>>>>closed by the developer(s).
>>>
>>>"duplicative" => false (see [1])
>>>"unnecessary" => false (see [2])
>>>
>>>
>>>>They were well within their rights to do so.
>>>
>>>of course not. [see my requoted rationales below]
>>>
>>>
>>>>I am satisfied that Kent did the right thing.
>>>
>>>I am unsatisfied which your way to ignore the given rationales.
>>>
>>>
>>>>Here's a suggestion. Rather than trying to convert the Eclipse open
>>>>source project to work the way to wished it did, why don't you try
>>>>learning how it actually does work and participating using the same
>>>>rules of engagement as everyone else?
>>>
>>>I know how this weak and non-integrated planning system works, and I've
>>>already suggested some changes (which you are free to ignore once more):
>>>
>>>see [3]
>>>
>>>
>>>>Eclipse is an open source project. It is run by developers for
>>>>developers. The Eclipse Foundation is a member-supported
>>>>not-for-profit organization which is focused on meeting the needs of
>>>>its members and supporting the requirements of the project
>>>>developers.
>>>
>>>I understand.
>>>
>>>
>>>>For users to be effective in promoting their interests,
>>>>they need to communicate using the channels and processes which are
>>>>in place. Agitating for separate channels that better suit your
>>>>personal desires for information is just a waste of everyone's time.
>>>
>>>I don't agitate for separate channels.
>>>
>>>I _insist_ to file dedicated issues for JSR's.
>>>
>>>see [4]
>>>
>>>
>>>>In this case you have seriously misunderstood how the development
>>>>process works. Bug reports are not plans. They are inputs to making
>>>>plans.
>>>
>>>This information is false.
>>>
>>>Plan items were kept within bugzilla - one example:
>>>
>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>>>
>>>Can anyone within this project explain me, why an _JSR_ is not worth an
>>>dedicated issue?
>>>
>>>One was 'accepted', see [5]
>>>
>>>
>>>>Philippe did you the courtesy of providing you a link to the planning
>>>>document --- which is available to all --- and you return the favour
>>>
>>>by pointing out deficiencies within the plan, see [6]
>>>
>>>
>>>>by implying that he is hiding information and maintaining hidden
>>>>plans.
>>>
>>>I've implied that _IBM_ is doing this, see [7] and [8]
>>>
>>>[Btw: did you ever worked for IBM?]
>>>
>>>
>>>>That is *not* how you win friends with anyone.
>>>
>>>I don't want to win friends.
>>>
>>>I just want that this ungentle IBM team stops hindering my efforts to
>
> file
>
>>>issues for the JSR's, similar to other filed plan items.
>>>
>>>[9]
>>>
>>>
>>>>In any case, this matter is closed --- as are the bug reports.
>>>
>>>neither this matter, nor the bug reports were closed.
>>>
>>>I just reopened them, having now again the real dependency tree and
>>>status:
>>>
>>> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>>>
>>>I ask you friendly to not further ignore my rationales.
>>>
>>>
>>>>/mike
>>>>
>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>news:crbl08$gjo$1@www.eclipse.org...
>>>>
>>>>
>>>>>>>I ask the relevant organs within the eclipse foundation to
>
> intervent.
>
>>>>>Awaiting a reaction.
>>>>>
>>>>>Please ensure the transparency of the development process.
>>>
>>>-
>>>
>>>
>>>>ilias wrote:
>>>>
>>>>>Philippe Mulet wrote: [moved down into context]
>>>>>
>>>>>
>>>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>>>news:cr5sji$i45$1@www.eclipse.org...
>>>>>>
>>>>>>
>>>>>>>I ask the relevant organs within the eclipse foundation to
>
> intervent.
>
>>>>>
>>>>>Awaiting a reaction.
>>>>>
>>>>>Please ensure the transparency of the development process.
>>>>>
>>>>>
>>>>>>>Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
>>>>>>>in a way which results in a false reflection of the current
>>>>>>>status of the issues and their dependencies.
>>>>>>>
>>>>>>>-
>>>>>>>
>>>
>>>[6]
>>>
>>>
>>>>>>>Reviewing the J2SE 5.0 implementation status, i've found information
>>>>>>>that was out of synch:
>>>>>>>
>>>>>>>this huge "Issue":
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>>>
>>>>>>>an outdated and inprecise plan, mostly without links to filed
>>>>>>>known issues within bugzilla:
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>>>>>>
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>>>>>
>>>>>>The JDT/Core team is maintaining an accurate status of J2SE 5.0
>
> support
>
>>>>>>on its web page:
>>>>>>
>
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
>
>>>>>>
>>>>>
>>>>>The status _was_ not accurate (see provided links above, which
>>>>>proof this).
>>>>>
>>>>>The status _is_ not accurate:
>>>>>
>>>>>* The open and the known issues are not filed. * links were not
>>>>>provided within the plan. * Interdependencies were not shown.
>>>>>
>>>
>>>[7]
>>>
>>>
>>>>>[I am wondering if the team uses an internal system, which is
>>>>>hidden from public.]
>>>>>
>>>
>>>[3]
>>>
>>>
>>>>>>>This "out-of-synch" problem would be reduced, if the plan was
>
> created
>
>>>>>>>out of the bugzilla database, as suggested in this
>>>>>>>thread:
>>>>>>>
>>>>>>>[PROJECT] [BUGZILLA] - Dependency Feature
>>>>>>
>>>>>>
> http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>
>>>[4]
>>>
>>>
>>>>>>>I've entered within Buzilla (the eclipse Issue Tracking System)
>>>>>>>the following Issue [using current title, initial title was
>>>>>>>different]:
>>>
>>>[5]
>>>
>>>
>>>>>>>[Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>this Issue depends on the implementation (within JDT.Core) of
>>>>>>>the following JSR's:
>>>>>>>
>>>>>>>JSR-201 (contains several parts), JSR-175, JSR-014
>>>>>>>
>>>>>>>Whilst using the dependency-feature of Bugzilla, I've filed
>>>>>>>(after looking for duplicates) the further top-level Issues:
>>>>>>>
>>>>>>>JSR-014 Generics
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>>>>>>
>>>>>>>Implement JSR-175 Metadata Facility (Annotations)
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>>>>>>
>>>>>>>Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
>
> loops,
>
>>>>>>>static imports) https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>>>>>>
>>>>>>>Implement JSR-201, part "static imports"
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>I've interlinked existing issues (and the newly filed
>>>>>>>documented known issues) with use of the dependency feature.
>>>>>
>>>>>
>>>>>>We use the bugzilla databse to track specific defects, and do not
>>>>>> really need an extra (after the fact) dependency tree to mimick
>>>>>>the web page.
>>>>>
>>>>>Your team-driven [users have no influence], out-dated and
>>>>>non-referencing status-report within the projects website is not
>>>>>that relevant.
>>>>>
>>>>>Bugzilla must inform the users, which search there for known
>>>>>issues.
>>>>>
>>>>>The dependecy-tree clarifies the issue-interdependencies, enabling
>>>>>users to detect relevant locations where they can contribute if
>>>>>they like to boost development.
>>>>>
>>>>>Please remember that this is an open-source project.
>>>>>
>>>>>
>>>>>>At this stage in our development cycle, we are trying to solve
>>>>>>all remaining problems in J2SE 5.0 front, and need specific defects
>
> to
>
>>>>>>help us; we have a couple non specific defects which
>>>>>>are representing committed 3.1 plan items,
>>>>>
>>>>>are you refering to this joke of an [plan item] issue:
>>>>>
>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>
>>>>>which I would personally be ashamed to show to the public?
>>>>>
>>>>>
>>>>>>and do not need extra ones to simply reformulate them (yes I
>>>>>>agree in a clearer way, but still duplicates).
>>>>>
>>>>>So, you really want to continue this arrogant behaviour?
>>>
>>>[1]
>>>
>>>
>>>>>I could expect from an experienced team that it understands the
>>>>>difference between "duplicate" and "depending on" relation.
>>>>>
>>>>>
>>>>>>>You will see within the issues, that Mr. Kent Johnson (IBM) _closes_
>>>>>>>the issues as INVALID - and as the last action,
>>>>>>>removing dependencies without any justifying comments.
>>>>>>>
>>>
>>>[9]
>>>
>>>
>>>>>>>What happens when a users searches for JSR-175 within Bugzilla?
>>>>>>>
>>>>>>>
>>>>>>>Or JSR-176?
>>>>>>>
>>>>>>>He finds obfuscated data.
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>It looks to me that the team is not intrested in real
>>>>>>>transparency, but just in keeping the open issues as low as
>>>>>>>possible.
>>>>>>>
>>>>>>>Until the JSR's were fully implemented within JDT.Core, the
>>>>>>>filed Issues remain _open_.
>>>>>>>
>>>>>>>This is a _fact_ - and I ask you to keep the Issue tracking
>>>>>>>transparent and honest, whilst reflecting the _real_ status.
>>>>>>>
>>>>>>>I've not the time to continue those close/open games from Mr.
>>>>>>>Kent Johnson (IBM).
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>"JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
>>>>>>>implemented fully within eclipse JDT.Core - and Bugzilla
>>>>>>> should reflect the correct status.
>>>>>
>>>>>
>>>>>>Basically, your effort should have occurred when the J2SE 5.0
>>>>>>effort started, and you should have better communicated with the
>>>>>>JDT Core team so as not to be disrupting our effort.
>>>>>
>>>>>I think it's a good moment to file the open J2SE 5.0 Issues, which
>>>>>will take a few months to finish.
>>>>>
>>>>>I'm not disrupting your effort (to implement J2SE 5.0 within
>>>>>JDT.Core)
>>>>>
>>>>>But you do disrupt mine (to organize and interlink the known
>>>>>issues)
>>>>>
>>>
>>>[2]
>>>
>>>
>>>>>>>Any JSR is worth a dedicated Issue within Buzilla, thus users
>>>>>>>hit on this information after a search.
>>>>>
>>>>>>I appreciate your no longer reopening unnecessary defects, since
>>>>>>they are inducing false hits in mail notifications; and thanks
>>>>>>for your interest in our J2SE 5.0 effort.
>>>>>
>>>>>So, you think honestly that an JSR is not worth an dedicated Issue?
>>>>>
>>>>>Feel free.
>>>>>
>>>>>As I will feel free to reopen the _perfectly_ valid Issues.
>>>>>
>>>>>The arrogant behaviour [ignoring facts and rationales] of the
>>>>>JDT.Core team (IBM) will not hinder me to increase transparency of
>>>>>the development, whilst using the resources of this project.
>>>>>
>>>>>....
>>>>>
>>>>>except:
>>>>>
>>>
>>>[8]
>>>
>>>
>>>>>You could state what should become obvious to every reader:
>>>>>
>>>>>"We (IBM) do not want too much transparency within the JDT.Core.
>>>>>That's the reason why everything is kept so terribly unorganized
>>>>>within _one_ component "Core", including the whole compiler [yes,
>>>>>really! the compiler is not an seperated organisational unit]. So,
>>>>>don't expect that we will allow you to create a transparent
>>>>>dependency-tree, thus everyone is able to understand within minutes
>>>>>the status and the interconnections. We will fight this, whilst
>>>>>risking to look like dumbs who do not understand the difference
>>>>>between a duplicate and a depending-on relation. We will even take
>>>>>the risk to state that an JSR is not worth an dedicated issue
>>>>>within bugzilla - and has to be marked as invalid."
>>>>>
>>>>>then I would possibly stop to insist on a transparent issue filing
>>>>> within this project.
>>>
>>>.
>>>
>>>--
>>>http://lazaridis.com
>>
>>
>
>
--
Eclipse WebMaster - webmaster@eclipse.org
Questions? Consult the FAQ at http://www.eclipse.org/webmaster/faq.html
View my status at http://www.eclipse.org/webmaster/main.html
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9569 is a reply to message #9450] |
Thu, 06 January 2005 14:08 |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.forritan.net
Watching this from the sideline - I find this completely ridiculous. He
is an obvious troll http://en.wikipedia.org/wiki/Internet_troll
but still gets to distract a great deal of the developers with his
rambling. On the mailinglists and the newsgroups it is reasonably easy
to ignore him, but I don't see how you (the developers) can tolerate
that he continues to corrupt the Bugzilla systems. (It took less 3 hours
before he reopened all issues you just closed - once again)
He started to evaluate Hibernate just before Christmas on the
hiberbnate-devel mailinglist and surprisingly:
From: Gavin King <gavin@hi...>
FYI
2004-12-23 17:10
I have removed Ilias Lazaridis from the list.
--
Gavin King
and he is also currently 'evaluating' at the IntelliJ Community forum...
where the first comment to his arrival was:
Oh my god.
So please do something somebody! Its long overdue.
Regards
Eyðun Nielsen
P.s.: I know that I shouldn't have fed the 'evaluator' myself on january
first, but I couldn't resist it. :-)
P.p.s.: To all the developers: Thank you for a great IDE and platform :-)
Philippe Mulet wrote:
> I closed all offending PRs again. Leaving only one which provides actual
> value (https://bugs.eclipse.org/bugs/show_bug.cgi?id=81974).
>
> "Mike Milinkovich" <mike.milinkovich@eclipse.org> wrote in message
> news:cri431$q2$1@www.eclipse.org...
>
>>Ilias,
>>
>>Please read Morten's excellent summary of how bug reporting gets done.
>>
>>Doing their job is not an "abuse of power and position". Like I said, I am
>>satisfied that Kent did the right thing.
>>
>>If you persist in re-opening bug reports which have been closed by the
>>developers, I will unfortunately have no recourse but to look into
>>terminating your access to our Bugzilla systems.
>>
>>/mike
>>
>>"ilias" <ilias@lazaridis.com> wrote in message
>>news:crheh8$sda$1@www.eclipse.org...
>>
>>>Mike Milinkovich wrote:
>>>
>>>>I am not sure who you expect to intervene or what you expect "...the
>>>> relevant organs within the eclipse foundation..." to do.
>>>
>>>Resolving.
>>>
>>>"abuse of power and position"
>>>
>>>[I do not accept this silently, like other users.]
>>>
>>>
>>>>Everything you have complained about is perfectly transparent. You
>>>>opened several duplicative and unnecessary bug reports which we
>>>>closed by the developer(s).
>>>
>>>"duplicative" => false (see [1])
>>>"unnecessary" => false (see [2])
>>>
>>>
>>>>They were well within their rights to do so.
>>>
>>>of course not. [see my requoted rationales below]
>>>
>>>
>>>>I am satisfied that Kent did the right thing.
>>>
>>>I am unsatisfied which your way to ignore the given rationales.
>>>
>>>
>>>>Here's a suggestion. Rather than trying to convert the Eclipse open
>>>>source project to work the way to wished it did, why don't you try
>>>>learning how it actually does work and participating using the same
>>>>rules of engagement as everyone else?
>>>
>>>I know how this weak and non-integrated planning system works, and I've
>>>already suggested some changes (which you are free to ignore once more):
>>>
>>>see [3]
>>>
>>>
>>>>Eclipse is an open source project. It is run by developers for
>>>>developers. The Eclipse Foundation is a member-supported
>>>>not-for-profit organization which is focused on meeting the needs of
>>>>its members and supporting the requirements of the project
>>>>developers.
>>>
>>>I understand.
>>>
>>>
>>>>For users to be effective in promoting their interests,
>>>>they need to communicate using the channels and processes which are
>>>>in place. Agitating for separate channels that better suit your
>>>>personal desires for information is just a waste of everyone's time.
>>>
>>>I don't agitate for separate channels.
>>>
>>>I _insist_ to file dedicated issues for JSR's.
>>>
>>>see [4]
>>>
>>>
>>>>In this case you have seriously misunderstood how the development
>>>>process works. Bug reports are not plans. They are inputs to making
>>>>plans.
>>>
>>>This information is false.
>>>
>>>Plan items were kept within bugzilla - one example:
>>>
>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>>>
>>>Can anyone within this project explain me, why an _JSR_ is not worth an
>>>dedicated issue?
>>>
>>>One was 'accepted', see [5]
>>>
>>>
>>>>Philippe did you the courtesy of providing you a link to the planning
>>>>document --- which is available to all --- and you return the favour
>>>
>>>by pointing out deficiencies within the plan, see [6]
>>>
>>>
>>>>by implying that he is hiding information and maintaining hidden
>>>>plans.
>>>
>>>I've implied that _IBM_ is doing this, see [7] and [8]
>>>
>>>[Btw: did you ever worked for IBM?]
>>>
>>>
>>>>That is *not* how you win friends with anyone.
>>>
>>>I don't want to win friends.
>>>
>>>I just want that this ungentle IBM team stops hindering my efforts to
>
> file
>
>>>issues for the JSR's, similar to other filed plan items.
>>>
>>>[9]
>>>
>>>
>>>>In any case, this matter is closed --- as are the bug reports.
>>>
>>>neither this matter, nor the bug reports were closed.
>>>
>>>I just reopened them, having now again the real dependency tree and
>>>status:
>>>
>>> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>>>
>>>I ask you friendly to not further ignore my rationales.
>>>
>>>
>>>>/mike
>>>>
>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>news:crbl08$gjo$1@www.eclipse.org...
>>>>
>>>>
>>>>>>>I ask the relevant organs within the eclipse foundation to
>
> intervent.
>
>>>>>Awaiting a reaction.
>>>>>
>>>>>Please ensure the transparency of the development process.
>>>
>>>-
>>>
>>>
>>>>ilias wrote:
>>>>
>>>>>Philippe Mulet wrote: [moved down into context]
>>>>>
>>>>>
>>>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>>>news:cr5sji$i45$1@www.eclipse.org...
>>>>>>
>>>>>>
>>>>>>>I ask the relevant organs within the eclipse foundation to
>
> intervent.
>
>>>>>
>>>>>Awaiting a reaction.
>>>>>
>>>>>Please ensure the transparency of the development process.
>>>>>
>>>>>
>>>>>>>Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
>>>>>>>in a way which results in a false reflection of the current
>>>>>>>status of the issues and their dependencies.
>>>>>>>
>>>>>>>-
>>>>>>>
>>>
>>>[6]
>>>
>>>
>>>>>>>Reviewing the J2SE 5.0 implementation status, i've found information
>>>>>>>that was out of synch:
>>>>>>>
>>>>>>>this huge "Issue":
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>>>
>>>>>>>an outdated and inprecise plan, mostly without links to filed
>>>>>>>known issues within bugzilla:
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>>>>>>
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>>>>>
>>>>>>The JDT/Core team is maintaining an accurate status of J2SE 5.0
>
> support
>
>>>>>>on its web page:
>>>>>>
>
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
>
>>>>>>
>>>>>
>>>>>The status _was_ not accurate (see provided links above, which
>>>>>proof this).
>>>>>
>>>>>The status _is_ not accurate:
>>>>>
>>>>>* The open and the known issues are not filed. * links were not
>>>>>provided within the plan. * Interdependencies were not shown.
>>>>>
>>>
>>>[7]
>>>
>>>
>>>>>[I am wondering if the team uses an internal system, which is
>>>>>hidden from public.]
>>>>>
>>>
>>>[3]
>>>
>>>
>>>>>>>This "out-of-synch" problem would be reduced, if the plan was
>
> created
>
>>>>>>>out of the bugzilla database, as suggested in this
>>>>>>>thread:
>>>>>>>
>>>>>>>[PROJECT] [BUGZILLA] - Dependency Feature
>>>>>>
>>>>>>
> http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>
>>>[4]
>>>
>>>
>>>>>>>I've entered within Buzilla (the eclipse Issue Tracking System)
>>>>>>>the following Issue [using current title, initial title was
>>>>>>>different]:
>>>
>>>[5]
>>>
>>>
>>>>>>>[Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>this Issue depends on the implementation (within JDT.Core) of
>>>>>>>the following JSR's:
>>>>>>>
>>>>>>>JSR-201 (contains several parts), JSR-175, JSR-014
>>>>>>>
>>>>>>>Whilst using the dependency-feature of Bugzilla, I've filed
>>>>>>>(after looking for duplicates) the further top-level Issues:
>>>>>>>
>>>>>>>JSR-014 Generics
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>>>>>>
>>>>>>>Implement JSR-175 Metadata Facility (Annotations)
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>>>>>>
>>>>>>>Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
>
> loops,
>
>>>>>>>static imports) https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>>>>>>
>>>>>>>Implement JSR-201, part "static imports"
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>I've interlinked existing issues (and the newly filed
>>>>>>>documented known issues) with use of the dependency feature.
>>>>>
>>>>>
>>>>>>We use the bugzilla databse to track specific defects, and do not
>>>>>> really need an extra (after the fact) dependency tree to mimick
>>>>>>the web page.
>>>>>
>>>>>Your team-driven [users have no influence], out-dated and
>>>>>non-referencing status-report within the projects website is not
>>>>>that relevant.
>>>>>
>>>>>Bugzilla must inform the users, which search there for known
>>>>>issues.
>>>>>
>>>>>The dependecy-tree clarifies the issue-interdependencies, enabling
>>>>>users to detect relevant locations where they can contribute if
>>>>>they like to boost development.
>>>>>
>>>>>Please remember that this is an open-source project.
>>>>>
>>>>>
>>>>>>At this stage in our development cycle, we are trying to solve
>>>>>>all remaining problems in J2SE 5.0 front, and need specific defects
>
> to
>
>>>>>>help us; we have a couple non specific defects which
>>>>>>are representing committed 3.1 plan items,
>>>>>
>>>>>are you refering to this joke of an [plan item] issue:
>>>>>
>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>
>>>>>which I would personally be ashamed to show to the public?
>>>>>
>>>>>
>>>>>>and do not need extra ones to simply reformulate them (yes I
>>>>>>agree in a clearer way, but still duplicates).
>>>>>
>>>>>So, you really want to continue this arrogant behaviour?
>>>
>>>[1]
>>>
>>>
>>>>>I could expect from an experienced team that it understands the
>>>>>difference between "duplicate" and "depending on" relation.
>>>>>
>>>>>
>>>>>>>You will see within the issues, that Mr. Kent Johnson (IBM) _closes_
>>>>>>>the issues as INVALID - and as the last action,
>>>>>>>removing dependencies without any justifying comments.
>>>>>>>
>>>
>>>[9]
>>>
>>>
>>>>>>>What happens when a users searches for JSR-175 within Bugzilla?
>>>>>>>
>>>>>>>
>>>>>>>Or JSR-176?
>>>>>>>
>>>>>>>He finds obfuscated data.
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>It looks to me that the team is not intrested in real
>>>>>>>transparency, but just in keeping the open issues as low as
>>>>>>>possible.
>>>>>>>
>>>>>>>Until the JSR's were fully implemented within JDT.Core, the
>>>>>>>filed Issues remain _open_.
>>>>>>>
>>>>>>>This is a _fact_ - and I ask you to keep the Issue tracking
>>>>>>>transparent and honest, whilst reflecting the _real_ status.
>>>>>>>
>>>>>>>I've not the time to continue those close/open games from Mr.
>>>>>>>Kent Johnson (IBM).
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>"JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
>>>>>>>implemented fully within eclipse JDT.Core - and Bugzilla
>>>>>>> should reflect the correct status.
>>>>>
>>>>>
>>>>>>Basically, your effort should have occurred when the J2SE 5.0
>>>>>>effort started, and you should have better communicated with the
>>>>>>JDT Core team so as not to be disrupting our effort.
>>>>>
>>>>>I think it's a good moment to file the open J2SE 5.0 Issues, which
>>>>>will take a few months to finish.
>>>>>
>>>>>I'm not disrupting your effort (to implement J2SE 5.0 within
>>>>>JDT.Core)
>>>>>
>>>>>But you do disrupt mine (to organize and interlink the known
>>>>>issues)
>>>>>
>>>
>>>[2]
>>>
>>>
>>>>>>>Any JSR is worth a dedicated Issue within Buzilla, thus users
>>>>>>>hit on this information after a search.
>>>>>
>>>>>>I appreciate your no longer reopening unnecessary defects, since
>>>>>>they are inducing false hits in mail notifications; and thanks
>>>>>>for your interest in our J2SE 5.0 effort.
>>>>>
>>>>>So, you think honestly that an JSR is not worth an dedicated Issue?
>>>>>
>>>>>Feel free.
>>>>>
>>>>>As I will feel free to reopen the _perfectly_ valid Issues.
>>>>>
>>>>>The arrogant behaviour [ignoring facts and rationales] of the
>>>>>JDT.Core team (IBM) will not hinder me to increase transparency of
>>>>>the development, whilst using the resources of this project.
>>>>>
>>>>>....
>>>>>
>>>>>except:
>>>>>
>>>
>>>[8]
>>>
>>>
>>>>>You could state what should become obvious to every reader:
>>>>>
>>>>>"We (IBM) do not want too much transparency within the JDT.Core.
>>>>>That's the reason why everything is kept so terribly unorganized
>>>>>within _one_ component "Core", including the whole compiler [yes,
>>>>>really! the compiler is not an seperated organisational unit]. So,
>>>>>don't expect that we will allow you to create a transparent
>>>>>dependency-tree, thus everyone is able to understand within minutes
>>>>>the status and the interconnections. We will fight this, whilst
>>>>>risking to look like dumbs who do not understand the difference
>>>>>between a duplicate and a depending-on relation. We will even take
>>>>>the risk to state that an JSR is not worth an dedicated issue
>>>>>within bugzilla - and has to be marked as invalid."
>>>>>
>>>>>then I would possibly stop to insist on a transparent issue filing
>>>>> within this project.
>>>
>>>.
>>>
>>>--
>>>http://lazaridis.com
>>
>>
>
>
|
|
| |
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9618 is a reply to message #9569] |
Thu, 06 January 2005 16:38 |
Eclipse User |
|
|
|
Originally posted by: myname(with.between names).lombardisoftware.com
I know he is a troll, but sometimes it is tempting to try to be the one
person to get one of these people to see the light and become productive
members of the society. :)
Eyðun Nielsen wrote:
> Watching this from the sideline - I find this completely ridiculous. He
> is an obvious troll http://en.wikipedia.org/wiki/Internet_troll
> but still gets to distract a great deal of the developers with his
> rambling. On the mailinglists and the newsgroups it is reasonably easy
> to ignore him, but I don't see how you (the developers) can tolerate
> that he continues to corrupt the Bugzilla systems. (It took less 3 hours
> before he reopened all issues you just closed - once again)
>
> He started to evaluate Hibernate just before Christmas on the
> hiberbnate-devel mailinglist and surprisingly:
>
>
> From: Gavin King <gavin@hi...>
> FYI
> 2004-12-23 17:10
>
> I have removed Ilias Lazaridis from the list.
>
> --
> Gavin King
>
>
>
> and he is also currently 'evaluating' at the IntelliJ Community forum...
> where the first comment to his arrival was:
>
> Oh my god.
>
>
> So please do something somebody! Its long overdue.
>
> Regards
> Eyðun Nielsen
>
> P.s.: I know that I shouldn't have fed the 'evaluator' myself on january
> first, but I couldn't resist it. :-)
>
> P.p.s.: To all the developers: Thank you for a great IDE and platform :-)
>
>
> Philippe Mulet wrote:
>> I closed all offending PRs again. Leaving only one which provides actual
>> value (https://bugs.eclipse.org/bugs/show_bug.cgi?id=81974).
>>
>> "Mike Milinkovich" <mike.milinkovich@eclipse.org> wrote in message
>> news:cri431$q2$1@www.eclipse.org...
>>
>>>Ilias,
>>>
>>>Please read Morten's excellent summary of how bug reporting gets done.
>>>
>>>Doing their job is not an "abuse of power and position". Like I said, I
>>>am satisfied that Kent did the right thing.
>>>
>>>If you persist in re-opening bug reports which have been closed by the
>>>developers, I will unfortunately have no recourse but to look into
>>>terminating your access to our Bugzilla systems.
>>>
>>>/mike
>>>
>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>news:crheh8$sda$1@www.eclipse.org...
>>>
>>>>Mike Milinkovich wrote:
>>>>
>>>>>I am not sure who you expect to intervene or what you expect "...the
>>>>> relevant organs within the eclipse foundation..." to do.
>>>>
>>>>Resolving.
>>>>
>>>>"abuse of power and position"
>>>>
>>>>[I do not accept this silently, like other users.]
>>>>
>>>>
>>>>>Everything you have complained about is perfectly transparent. You
>>>>>opened several duplicative and unnecessary bug reports which we
>>>>>closed by the developer(s).
>>>>
>>>>"duplicative" => false (see [1])
>>>>"unnecessary" => false (see [2])
>>>>
>>>>
>>>>>They were well within their rights to do so.
>>>>
>>>>of course not. [see my requoted rationales below]
>>>>
>>>>
>>>>>I am satisfied that Kent did the right thing.
>>>>
>>>>I am unsatisfied which your way to ignore the given rationales.
>>>>
>>>>
>>>>>Here's a suggestion. Rather than trying to convert the Eclipse open
>>>>>source project to work the way to wished it did, why don't you try
>>>>>learning how it actually does work and participating using the same
>>>>>rules of engagement as everyone else?
>>>>
>>>>I know how this weak and non-integrated planning system works, and I've
>>>>already suggested some changes (which you are free to ignore once more):
>>>>
>>>>see [3]
>>>>
>>>>
>>>>>Eclipse is an open source project. It is run by developers for
>>>>>developers. The Eclipse Foundation is a member-supported
>>>>>not-for-profit organization which is focused on meeting the needs of
>>>>>its members and supporting the requirements of the project
>>>>>developers.
>>>>
>>>>I understand.
>>>>
>>>>
>>>>>For users to be effective in promoting their interests,
>>>>>they need to communicate using the channels and processes which are
>>>>>in place. Agitating for separate channels that better suit your
>>>>>personal desires for information is just a waste of everyone's time.
>>>>
>>>>I don't agitate for separate channels.
>>>>
>>>>I _insist_ to file dedicated issues for JSR's.
>>>>
>>>>see [4]
>>>>
>>>>
>>>>>In this case you have seriously misunderstood how the development
>>>>>process works. Bug reports are not plans. They are inputs to making
>>>>>plans.
>>>>
>>>>This information is false.
>>>>
>>>>Plan items were kept within bugzilla - one example:
>>>>
>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>>>>
>>>>Can anyone within this project explain me, why an _JSR_ is not worth an
>>>>dedicated issue?
>>>>
>>>>One was 'accepted', see [5]
>>>>
>>>>
>>>>>Philippe did you the courtesy of providing you a link to the planning
>>>>>document --- which is available to all --- and you return the favour
>>>>
>>>>by pointing out deficiencies within the plan, see [6]
>>>>
>>>>
>>>>>by implying that he is hiding information and maintaining hidden
>>>>>plans.
>>>>
>>>>I've implied that _IBM_ is doing this, see [7] and [8]
>>>>
>>>>[Btw: did you ever worked for IBM?]
>>>>
>>>>
>>>>>That is *not* how you win friends with anyone.
>>>>
>>>>I don't want to win friends.
>>>>
>>>>I just want that this ungentle IBM team stops hindering my efforts to
>>
>> file
>>
>>>>issues for the JSR's, similar to other filed plan items.
>>>>
>>>>[9]
>>>>
>>>>
>>>>>In any case, this matter is closed --- as are the bug reports.
>>>>
>>>>neither this matter, nor the bug reports were closed.
>>>>
>>>>I just reopened them, having now again the real dependency tree and
>>>>status:
>>>>
>>>> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>>>>
>>>>I ask you friendly to not further ignore my rationales.
>>>>
>>>>
>>>>>/mike
>>>>>
>>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>>news:crbl08$gjo$1@www.eclipse.org...
>>>>>
>>>>>
>>>>>>>>I ask the relevant organs within the eclipse foundation to
>>
>> intervent.
>>
>>>>>>Awaiting a reaction.
>>>>>>
>>>>>>Please ensure the transparency of the development process.
>>>>
>>>>-
>>>>
>>>>
>>>>>ilias wrote:
>>>>>
>>>>>>Philippe Mulet wrote: [moved down into context]
>>>>>>
>>>>>>
>>>>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>>>>news:cr5sji$i45$1@www.eclipse.org...
>>>>>>>
>>>>>>>
>>>>>>>>I ask the relevant organs within the eclipse foundation to
>>
>> intervent.
>>
>>>>>>
>>>>>>Awaiting a reaction.
>>>>>>
>>>>>>Please ensure the transparency of the development process.
>>>>>>
>>>>>>
>>>>>>>>Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
>>>>>>>>in a way which results in a false reflection of the current
>>>>>>>>status of the issues and their dependencies.
>>>>>>>>
>>>>>>>>-
>>>>>>>>
>>>>
>>>>[6]
>>>>
>>>>
>>>>>>>>Reviewing the J2SE 5.0 implementation status, i've found information
>>>>>>>>that was out of synch:
>>>>>>>>
>>>>>>>>this huge "Issue":
>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>>>>
>>>>>>>>an outdated and inprecise plan, mostly without links to filed
>>>>>>>>known issues within bugzilla:
>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>>>>>>>
>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>>>>>>
>>>>>>>The JDT/Core team is maintaining an accurate status of J2SE 5.0
>>
>> support
>>
>>>>>>>on its web page:
>>>>>>>
>>
>>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
>>
>>>>>>>
>>>>>>
>>>>>>The status _was_ not accurate (see provided links above, which
>>>>>>proof this).
>>>>>>
>>>>>>The status _is_ not accurate:
>>>>>>
>>>>>>* The open and the known issues are not filed. * links were not
>>>>>>provided within the plan. * Interdependencies were not shown.
>>>>>>
>>>>
>>>>[7]
>>>>
>>>>
>>>>>>[I am wondering if the team uses an internal system, which is
>>>>>>hidden from public.]
>>>>>>
>>>>
>>>>[3]
>>>>
>>>>
>>>>>>>>This "out-of-synch" problem would be reduced, if the plan was
>>
>> created
>>
>>>>>>>>out of the bugzilla database, as suggested in this
>>>>>>>>thread:
>>>>>>>>
>>>>>>>>[PROJECT] [BUGZILLA] - Dependency Feature
>>>>>>>
>>>>>>>
>>
http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>>
>>>>[4]
>>>>
>>>>
>>>>>>>>I've entered within Buzilla (the eclipse Issue Tracking System)
>>>>>>>>the following Issue [using current title, initial title was
>>>>>>>>different]:
>>>>
>>>>[5]
>>>>
>>>>
>>>>>>>>[Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>>>>>>>
>>>>>>>>-
>>>>>>>>
>>>>>>>>this Issue depends on the implementation (within JDT.Core) of
>>>>>>>>the following JSR's:
>>>>>>>>
>>>>>>>>JSR-201 (contains several parts), JSR-175, JSR-014
>>>>>>>>
>>>>>>>>Whilst using the dependency-feature of Bugzilla, I've filed
>>>>>>>>(after looking for duplicates) the further top-level Issues:
>>>>>>>>
>>>>>>>>JSR-014 Generics
>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>>>>>>>
>>>>>>>>Implement JSR-175 Metadata Facility (Annotations)
>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>>>>>>>
>>>>>>>>Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
>>
>> loops,
>>
>>>>>>>>static imports) https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>>>>>>>
>>>>>>>>Implement JSR-201, part "static imports"
>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>>>>>>>
>>>>>>>>-
>>>>>>>>
>>>>>>>>I've interlinked existing issues (and the newly filed
>>>>>>>>documented known issues) with use of the dependency feature.
>>>>>>
>>>>>>
>>>>>>>We use the bugzilla databse to track specific defects, and do not
>>>>>>> really need an extra (after the fact) dependency tree to mimick
>>>>>>>the web page.
>>>>>>
>>>>>>Your team-driven [users have no influence], out-dated and
>>>>>>non-referencing status-report within the projects website is not
>>>>>>that relevant.
>>>>>>
>>>>>>Bugzilla must inform the users, which search there for known
>>>>>>issues.
>>>>>>
>>>>>>The dependecy-tree clarifies the issue-interdependencies, enabling
>>>>>>users to detect relevant locations where they can contribute if
>>>>>>they like to boost development.
>>>>>>
>>>>>>Please remember that this is an open-source project.
>>>>>>
>>>>>>
>>>>>>>At this stage in our development cycle, we are trying to solve
>>>>>>>all remaining problems in J2SE 5.0 front, and need specific defects
>>
>> to
>>
>>>>>>>help us; we have a couple non specific defects which
>>>>>>>are representing committed 3.1 plan items,
>>>>>>
>>>>>>are you refering to this joke of an [plan item] issue:
>>>>>>
>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>>
>>>>>>which I would personally be ashamed to show to the public?
>>>>>>
>>>>>>
>>>>>>>and do not need extra ones to simply reformulate them (yes I
>>>>>>>agree in a clearer way, but still duplicates).
>>>>>>
>>>>>>So, you really want to continue this arrogant behaviour?
>>>>
>>>>[1]
>>>>
>>>>
>>>>>>I could expect from an experienced team that it understands the
>>>>>>difference between "duplicate" and "depending on" relation.
>>>>>>
>>>>>>
>>>>>>>>You will see within the issues, that Mr. Kent Johnson (IBM) _closes_
>>>>>>>>the issues as INVALID - and as the last action,
>>>>>>>>removing dependencies without any justifying comments.
>>>>>>>>
>>>>
>>>>[9]
>>>>
>>>>
>>>>>>>>What happens when a users searches for JSR-175 within Bugzilla?
>>>>>>>>
>>>>>>>>
>>>>>>>>Or JSR-176?
>>>>>>>>
>>>>>>>>He finds obfuscated data.
>>>>>>>>
>>>>>>>>-
>>>>>>>>
>>>>>>>>It looks to me that the team is not intrested in real
>>>>>>>>transparency, but just in keeping the open issues as low as
>>>>>>>>possible.
>>>>>>>>
>>>>>>>>Until the JSR's were fully implemented within JDT.Core, the
>>>>>>>>filed Issues remain _open_.
>>>>>>>>
>>>>>>>>This is a _fact_ - and I ask you to keep the Issue tracking
>>>>>>>>transparent and honest, whilst reflecting the _real_ status.
>>>>>>>>
>>>>>>>>I've not the time to continue those close/open games from Mr.
>>>>>>>>Kent Johnson (IBM).
>>>>>>>>
>>>>>>>>-
>>>>>>>>
>>>>>>>>"JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
>>>>>>>>implemented fully within eclipse JDT.Core - and Bugzilla
>>>>>>>> should reflect the correct status.
>>>>>>
>>>>>>
>>>>>>>Basically, your effort should have occurred when the J2SE 5.0
>>>>>>>effort started, and you should have better communicated with the
>>>>>>>JDT Core team so as not to be disrupting our effort.
>>>>>>
>>>>>>I think it's a good moment to file the open J2SE 5.0 Issues, which
>>>>>>will take a few months to finish.
>>>>>>
>>>>>>I'm not disrupting your effort (to implement J2SE 5.0 within
>>>>>>JDT.Core)
>>>>>>
>>>>>>But you do disrupt mine (to organize and interlink the known
>>>>>>issues)
>>>>>>
>>>>
>>>>[2]
>>>>
>>>>
>>>>>>>>Any JSR is worth a dedicated Issue within Buzilla, thus users
>>>>>>>>hit on this information after a search.
>>>>>>
>>>>>>>I appreciate your no longer reopening unnecessary defects, since
>>>>>>>they are inducing false hits in mail notifications; and thanks
>>>>>>>for your interest in our J2SE 5.0 effort.
>>>>>>
>>>>>>So, you think honestly that an JSR is not worth an dedicated Issue?
>>>>>>
>>>>>>Feel free.
>>>>>>
>>>>>>As I will feel free to reopen the _perfectly_ valid Issues.
>>>>>>
>>>>>>The arrogant behaviour [ignoring facts and rationales] of the
>>>>>>JDT.Core team (IBM) will not hinder me to increase transparency of
>>>>>>the development, whilst using the resources of this project.
>>>>>>
>>>>>>....
>>>>>>
>>>>>>except:
>>>>>>
>>>>
>>>>[8]
>>>>
>>>>
>>>>>>You could state what should become obvious to every reader:
>>>>>>
>>>>>>"We (IBM) do not want too much transparency within the JDT.Core.
>>>>>>That's the reason why everything is kept so terribly unorganized
>>>>>>within _one_ component "Core", including the whole compiler [yes,
>>>>>>really! the compiler is not an seperated organisational unit]. So,
>>>>>>don't expect that we will allow you to create a transparent
>>>>>>dependency-tree, thus everyone is able to understand within minutes
>>>>>>the status and the interconnections. We will fight this, whilst
>>>>>>risking to look like dumbs who do not understand the difference
>>>>>>between a duplicate and a depending-on relation. We will even take
>>>>>>the risk to state that an JSR is not worth an dedicated issue
>>>>>>within bugzilla - and has to be marked as invalid."
>>>>>>
>>>>>>then I would possibly stop to insist on a transparent issue filing
>>>>>> within this project.
>>>>
>>>>.
>>>>
>>>>--
>>>>http://lazaridis.com
>>>
>>>
>>
>>
|
|
|
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9642 is a reply to message #9495] |
Thu, 06 January 2005 17:02 |
Eclipse User |
|
|
|
Originally posted by: myname(with.between names).lombardisoftware.com
Well then why don't you enlighten the rest of us on which specific sections
and paragraphs in the Bylaws (http://www.eclipse.org/org/documents/Eclipse
BYLAWS 2003_11_10 Final.pdf) and Dev process
(http://www.eclipse.org/org/documents/Eclipse Development Process
2003_11_09 FINAL.pdf) are violated by Kent Johnson and his way of doing
things. Stating it "violates" without any direct pointers to what exactly
it violates means nothing.
Maybe you can add in a link to the "transparency directive" (and the
paragraph[s] in question) that states the JDT teams way of handling
Bugzilla is illegal?
ilias wrote:
> Mike Milinkovich wrote:
>> Ilias,
>>
>> Please read Morten's excellent summary of how bug reporting gets done.
>
> I've read it, but he's obivously very missinformed about the eclipse
> foundations development process.
>
> I'm wondering that you rate it as "excellent".
>
> Didn't you detect that his writing were generally, and would violate
> eclipse foundations tranparency directive?
>
> or did you read just the final summary:
>
> " * Bugzilla is mainly for developers and testers. They can organize
> it the way they want, not the way you or I might want.
> * Status updates is done when the people involved developing wants
> to in the granularity they want to, not when/what you or I want.
> * How/If to keep status is up to the developers, not me or you.
> "
>
> which is again not valid for the eclipse foundation.
>
>> Doing their job is not an "abuse of power and position".
>
> Declaring valid Issues (which affect JSR's) as invalid, whilst closing
> them is not their job.
>
> Disrupting a valid user contributed dependency tree, which reflects
> reality, without any justifications is not their job:
>
> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>
>> Like I said, I am satisfied that Kent did the right thing.
>
> To keep bugzilla saying that J2SE 5.0 is implemented within JDT.Core?
>
> The right thing for whom?
>
> For the users, which search for information within bugzilla?
>
> Or for the IBM marketin machine?
>
>> If you persist in re-opening bug reports which have been closed by the
>> developers, I will unfortunately have no recourse but to look into
>> terminating your access to our Bugzilla systems.
>
> You are "satisfied" with the abusive behaviour of the JDT.Core team.
>
> Thus I believe that you will not resist to abuse your power and position
> to terminate my access.
>
> I've just reopened the dedicated issues, thus a user which searches
> within bugzilla sees the real status of the JSR's:
>
> JSR-176 J2SE 5.0 (Tiger) Release Contents
> Implement JSR-201 (enumerations, autoboxing, varargs, enhanced loops,
> static imports)
> Implement JSR-175 Metadata Facility (Annotations)
> Implement JSR-014 Generics
>
> The dependency shows now the correct status:
>
> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>
> [note to readers: I've not recreated the dependencies, which IBM
> employees have removed, to showcase the reduced transparency]
>
> -
>
> btw: can you please answer the open questions below.
>
> -
>
>>>Plan items were kept within bugzilla - one example:
>>>
>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>>>
>>>Can anyone within this project explain me, why an _JSR_ is not worth an
>>>dedicated issue?
>
> ?
>
>>>[Btw: did you ever worked for IBM?]
>
> ?
>
>>>I ask you friendly to not further ignore my rationales.
>
>>>>>Please ensure the transparency of the development process.
>>>>>You could state what should become obvious to every reader:
>
> .
>
|
|
| |
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9692 is a reply to message #9594] |
Fri, 07 January 2005 09:49 |
Eclipse User |
|
|
|
Originally posted by: joerg.von.frantzius.artnology.nospam.com
This is a multi-part message in MIME format.
--------------080507000401060303020202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
I'd also find it a bit over the top to throw him out from the newsgroups
and mailing lists. Who wants to ignore him can simply put him into his
personal "killfile" (automatic filters) or just refrain from reading his
postings. I also found that besides being slightly entertaining, there
sometimes was a grain of uncomfortable truth in what he wrote that
should not be completely unheard. I had so far been really impressed by
the integrative powers and endurance of the eclipse community, and I'd
find it a bit disappointing if it reverts to simple repressive measures.
Generating unnecessary work for other people in the Bugzilla is
something different though. Maybe it is possible to just block him in
the Bugzilla?
Mike Milinkovich schrieb:
>I have asked the WebMaster to do what he can to make Ilias disappear from
>Bugzilla, the newsgroups and our mailing lists.
>
>Thanks all.
>
>/mike
>
>"Ey
|
|
| |
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9715 is a reply to message #9594] |
Fri, 07 January 2005 17:20 |
Brian Hudson Messages: 17 Registered: July 2009 |
Junior Member |
|
|
Thank you!
This was long overdue.
Brian Hudson
Mike Milinkovich wrote:
> I have asked the WebMaster to do what he can to make Ilias disappear from
> Bugzilla, the newsgroups and our mailing lists.
>
> Thanks all.
>
> /mike
>
> "Eyðun Nielsen" <eclipse-news@forritan.net> wrote in message
> news:crjgo9$d5q$1@www.eclipse.org...
>
>>Watching this from the sideline - I find this completely ridiculous. He is
>>an obvious troll http://en.wikipedia.org/wiki/Internet_troll
>>but still gets to distract a great deal of the developers with his
>>rambling. On the mailinglists and the newsgroups it is reasonably easy to
>>ignore him, but I don't see how you (the developers) can tolerate that he
>>continues to corrupt the Bugzilla systems. (It took less 3 hours before he
>>reopened all issues you just closed - once again)
>>
>>He started to evaluate Hibernate just before Christmas on the
>>hiberbnate-devel mailinglist and surprisingly:
>>
>>
>>From: Gavin King <gavin@hi...>
>>FYI
>>2004-12-23 17:10
>>
>> I have removed Ilias Lazaridis from the list.
>>
>> --
>> Gavin King
>>
>>
>>
>>and he is also currently 'evaluating' at the IntelliJ Community forum...
>>where the first comment to his arrival was:
>>
>> Oh my god.
>>
>>
>>So please do something somebody! Its long overdue.
>>
>>Regards
>>Eyðun Nielsen
>>
>>P.s.: I know that I shouldn't have fed the 'evaluator' myself on january
>>first, but I couldn't resist it. :-)
>>
>>P.p.s.: To all the developers: Thank you for a great IDE and platform :-)
>>
>>
>>Philippe Mulet wrote:
>>
>>>I closed all offending PRs again. Leaving only one which provides actual
>>>value (https://bugs.eclipse.org/bugs/show_bug.cgi?id=81974).
>>>
>>>"Mike Milinkovich" <mike.milinkovich@eclipse.org> wrote in message
>>>news:cri431$q2$1@www.eclipse.org...
>>>
>>>
>>>>Ilias,
>>>>
>>>>Please read Morten's excellent summary of how bug reporting gets done.
>>>>
>>>>Doing their job is not an "abuse of power and position". Like I said, I
>>>>am
>>>>satisfied that Kent did the right thing.
>>>>
>>>>If you persist in re-opening bug reports which have been closed by the
>>>>developers, I will unfortunately have no recourse but to look into
>>>>terminating your access to our Bugzilla systems.
>>>>
>>>>/mike
>>>>
>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>news:crheh8$sda$1@www.eclipse.org...
>>>>
>>>>
>>>>>Mike Milinkovich wrote:
>>>>>
>>>>>
>>>>>>I am not sure who you expect to intervene or what you expect "...the
>>>>>>relevant organs within the eclipse foundation..." to do.
>>>>>
>>>>>Resolving.
>>>>>
>>>>>"abuse of power and position"
>>>>>
>>>>>[I do not accept this silently, like other users.]
>>>>>
>>>>>
>>>>>
>>>>>>Everything you have complained about is perfectly transparent. You
>>>>>>opened several duplicative and unnecessary bug reports which we
>>>>>>closed by the developer(s).
>>>>>
>>>>>"duplicative" => false (see [1])
>>>>>"unnecessary" => false (see [2])
>>>>>
>>>>>
>>>>>
>>>>>>They were well within their rights to do so.
>>>>>
>>>>>of course not. [see my requoted rationales below]
>>>>>
>>>>>
>>>>>
>>>>>>I am satisfied that Kent did the right thing.
>>>>>
>>>>>I am unsatisfied which your way to ignore the given rationales.
>>>>>
>>>>>
>>>>>
>>>>>>Here's a suggestion. Rather than trying to convert the Eclipse open
>>>>>>source project to work the way to wished it did, why don't you try
>>>>>>learning how it actually does work and participating using the same
>>>>>>rules of engagement as everyone else?
>>>>>
>>>>>I know how this weak and non-integrated planning system works, and I've
>>>>>already suggested some changes (which you are free to ignore once more):
>>>>>
>>>>>see [3]
>>>>>
>>>>>
>>>>>
>>>>>>Eclipse is an open source project. It is run by developers for
>>>>>>developers. The Eclipse Foundation is a member-supported
>>>>>>not-for-profit organization which is focused on meeting the needs of
>>>>>>its members and supporting the requirements of the project
>>>>>>developers.
>>>>>
>>>>>I understand.
>>>>>
>>>>>
>>>>>
>>>>>>For users to be effective in promoting their interests,
>>>>>>they need to communicate using the channels and processes which are
>>>>>>in place. Agitating for separate channels that better suit your
>>>>>>personal desires for information is just a waste of everyone's time.
>>>>>
>>>>>I don't agitate for separate channels.
>>>>>
>>>>>I _insist_ to file dedicated issues for JSR's.
>>>>>
>>>>>see [4]
>>>>>
>>>>>
>>>>>
>>>>>>In this case you have seriously misunderstood how the development
>>>>>>process works. Bug reports are not plans. They are inputs to making
>>>>>>plans.
>>>>>
>>>>>This information is false.
>>>>>
>>>>>Plan items were kept within bugzilla - one example:
>>>>>
>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=37660
>>>>>
>>>>>Can anyone within this project explain me, why an _JSR_ is not worth an
>>>>>dedicated issue?
>>>>>
>>>>>One was 'accepted', see [5]
>>>>>
>>>>>
>>>>>
>>>>>>Philippe did you the courtesy of providing you a link to the planning
>>>>>>document --- which is available to all --- and you return the favour
>>>>>
>>>>>by pointing out deficiencies within the plan, see [6]
>>>>>
>>>>>
>>>>>
>>>>>>by implying that he is hiding information and maintaining hidden
>>>>>>plans.
>>>>>
>>>>>I've implied that _IBM_ is doing this, see [7] and [8]
>>>>>
>>>>>[Btw: did you ever worked for IBM?]
>>>>>
>>>>>
>>>>>
>>>>>>That is *not* how you win friends with anyone.
>>>>>
>>>>>I don't want to win friends.
>>>>>
>>>>>I just want that this ungentle IBM team stops hindering my efforts to
>>>
>>>file
>>>
>>>
>>>>>issues for the JSR's, similar to other filed plan items.
>>>>>
>>>>>[9]
>>>>>
>>>>>
>>>>>
>>>>>>In any case, this matter is closed --- as are the bug reports.
>>>>>
>>>>>neither this matter, nor the bug reports were closed.
>>>>>
>>>>>I just reopened them, having now again the real dependency tree and
>>>>>status:
>>>>>
>>>>> https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=8077 5
>>>>>
>>>>>I ask you friendly to not further ignore my rationales.
>>>>>
>>>>>
>>>>>
>>>>>>/mike
>>>>>>
>>>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>>>news:crbl08$gjo$1@www.eclipse.org...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>I ask the relevant organs within the eclipse foundation to
>>>
>>>intervent.
>>>
>>>
>>>>>>>Awaiting a reaction.
>>>>>>>
>>>>>>>Please ensure the transparency of the development process.
>>>>>
>>>>>-
>>>>>
>>>>>
>>>>>
>>>>>>ilias wrote:
>>>>>>
>>>>>>
>>>>>>>Philippe Mulet wrote: [moved down into context]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>"ilias" <ilias@lazaridis.com> wrote in message
>>>>>>>>news:cr5sji$i45$1@www.eclipse.org...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I ask the relevant organs within the eclipse foundation to
>>>
>>>intervent.
>>>
>>>
>>>>>>>Awaiting a reaction.
>>>>>>>
>>>>>>>Please ensure the transparency of the development process.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>Mr. Kent Johnson (IBM) manipulates filed issues within JDT.Core
>>>>>>>>>in a way which results in a false reflection of the current
>>>>>>>>>status of the issues and their dependencies.
>>>>>>>>>
>>>>>>>>>-
>>>>>>>>>
>>>>>
>>>>>[6]
>>>>>
>>>>>
>>>>>
>>>>>>>>>Reviewing the J2SE 5.0 implementation status, i've found information
>>>>>>>>>that was out of synch:
>>>>>>>>>
>>>>>>>>>this huge "Issue":
>>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>>>>>
>>>>>>>>>an outdated and inprecise plan, mostly without links to filed
>>>>>>>>>known issues within bugzilla:
>>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81471#c3
>>>>>>>>>
>>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=50443#c13
>>>>>>>
>>>>>>>>The JDT/Core team is maintaining an accurate status of J2SE 5.0
>>>
>>>support
>>>
>>>
>>>>>>>>on its web page:
>>>>>>>>
>>>
>>> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt- core-home/r3.1/main.html#release-plan
>>>
>>>
>>>>>>>The status _was_ not accurate (see provided links above, which
>>>>>>>proof this).
>>>>>>>
>>>>>>>The status _is_ not accurate:
>>>>>>>
>>>>>>>* The open and the known issues are not filed. * links were not
>>>>>>>provided within the plan. * Interdependencies were not shown.
>>>>>>>
>>>>>
>>>>>[7]
>>>>>
>>>>>
>>>>>
>>>>>>>[I am wondering if the team uses an internal system, which is
>>>>>>>hidden from public.]
>>>>>>>
>>>>>
>>>>>[3]
>>>>>
>>>>>
>>>>>
>>>>>>>>>This "out-of-synch" problem would be reduced, if the plan was
>>>
>>>created
>>>
>>>
>>>>>>>>>out of the bugzilla database, as suggested in this
>>>>>>>>>thread:
>>>>>>>>>
>>>>>>>>>[PROJECT] [BUGZILLA] - Dependency Feature
>>>>>>>>
>>>>>>>>
>>> http://www.eclipse.org/newsportal/article.php?id=217&gro up=eclipse.foundation
>>>
>>>
>>>>>[4]
>>>>>
>>>>>
>>>>>
>>>>>>>>>I've entered within Buzilla (the eclipse Issue Tracking System)
>>>>>>>>>the following Issue [using current title, initial title was
>>>>>>>>>different]:
>>>>>
>>>>>[5]
>>>>>
>>>>>
>>>>>
>>>>>>>>>[Bug 80775] JSR-176 J2SE 5.0 (Tiger) Release Contents
>>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80775
>>>>>>>>>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>this Issue depends on the implementation (within JDT.Core) of
>>>>>>>>>the following JSR's:
>>>>>>>>>
>>>>>>>>>JSR-201 (contains several parts), JSR-175, JSR-014
>>>>>>>>>
>>>>>>>>>Whilst using the dependency-feature of Bugzilla, I've filed
>>>>>>>>>(after looking for duplicates) the further top-level Issues:
>>>>>>>>>
>>>>>>>>>JSR-014 Generics
>>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80777
>>>>>>>>>
>>>>>>>>>Implement JSR-175 Metadata Facility (Annotations)
>>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=80776
>>>>>>>>>
>>>>>>>>>Implement JSR-201 (enumerations, autoboxing, varargs, enhanced
>>>
>>>loops,
>>>
>>>
>>>>>>>>>static imports) https://bugs.eclipse.org/bugs/show_bug.cgi?id=81470
>>>>>>>>>
>>>>>>>>>Implement JSR-201, part "static imports"
>>>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=81593
>>>>>>>>>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>I've interlinked existing issues (and the newly filed
>>>>>>>>>documented known issues) with use of the dependency feature.
>>>>>>>
>>>>>>>
>>>>>>>>We use the bugzilla databse to track specific defects, and do not
>>>>>>>>really need an extra (after the fact) dependency tree to mimick
>>>>>>>>the web page.
>>>>>>>
>>>>>>>Your team-driven [users have no influence], out-dated and
>>>>>>>non-referencing status-report within the projects website is not
>>>>>>>that relevant.
>>>>>>>
>>>>>>>Bugzilla must inform the users, which search there for known
>>>>>>>issues.
>>>>>>>
>>>>>>>The dependecy-tree clarifies the issue-interdependencies, enabling
>>>>>>>users to detect relevant locations where they can contribute if
>>>>>>>they like to boost development.
>>>>>>>
>>>>>>>Please remember that this is an open-source project.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>At this stage in our development cycle, we are trying to solve
>>>>>>>>all remaining problems in J2SE 5.0 front, and need specific defects
>>>
>>>to
>>>
>>>
>>>>>>>>help us; we have a couple non specific defects which
>>>>>>>>are representing committed 3.1 plan items,
>>>>>>>
>>>>>>>are you refering to this joke of an [plan item] issue:
>>>>>>>
>>>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=36938
>>>>>>>
>>>>>>>which I would personally be ashamed to show to the public?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>and do not need extra ones to simply reformulate them (yes I
>>>>>>>>agree in a clearer way, but still duplicates).
>>>>>>>
>>>>>>>So, you really want to continue this arrogant behaviour?
>>>>>
>>>>>[1]
>>>>>
>>>>>
>>>>>
>>>>>>>I could expect from an experienced team that it understands the
>>>>>>>difference between "duplicate" and "depending on" relation.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>You will see within the issues, that Mr. Kent Johnson (IBM) _closes_
>>>>>>>>>the issues as INVALID - and as the last action,
>>>>>>>>>removing dependencies without any justifying comments.
>>>>>>>>>
>>>>>
>>>>>[9]
>>>>>
>>>>>
>>>>>
>>>>>>>>>What happens when a users searches for JSR-175 within Bugzilla?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Or JSR-176?
>>>>>>>>>
>>>>>>>>>He finds obfuscated data.
>>>>>>>>>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>It looks to me that the team is not intrested in real
>>>>>>>>>transparency, but just in keeping the open issues as low as
>>>>>>>>>possible.
>>>>>>>>>
>>>>>>>>>Until the JSR's were fully implemented within JDT.Core, the
>>>>>>>>>filed Issues remain _open_.
>>>>>>>>>
>>>>>>>>>This is a _fact_ - and I ask you to keep the Issue tracking
>>>>>>>>>transparent and honest, whilst reflecting the _real_ status.
>>>>>>>>>
>>>>>>>>>I've not the time to continue those close/open games from Mr.
>>>>>>>>>Kent Johnson (IBM).
>>>>>>>>>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>"JSR-176 J2SE 5.0 (Tiger) Release Contents" are far away from beeing
>>>>>>>>>implemented fully within eclipse JDT.Core - and Bugzilla
>>>>>>>>>should reflect the correct status.
>>>>>>>
>>>>>>>
>>>>>>>>Basically, your effort should have occurred when the J2SE 5.0
>>>>>>>>effort started, and you should have better communicated with the
>>>>>>>>JDT Core team so as not to be disrupting our effort.
>>>>>>>
>>>>>>>I think it's a good moment to file the open J2SE 5.0 Issues, which
>>>>>>>will take a few months to finish.
>>>>>>>
>>>>>>>I'm not disrupting your effort (to implement J2SE 5.0 within
>>>>>>>JDT.Core)
>>>>>>>
>>>>>>>But you do disrupt mine (to organize and interlink the known
>>>>>>>issues)
>>>>>>>
>>>>>
>>>>>[2]
>>>>>
>>>>>
>>>>>
>>>>>>>>>Any JSR is worth a dedicated Issue within Buzilla, thus users
>>>>>>>>>hit on this information after a search.
>>>>>>>
>>>>>>>>I appreciate your no longer reopening unnecessary defects, since
>>>>>>>>they are inducing false hits in mail notifications; and thanks
>>>>>>>>for your interest in our J2SE 5.0 effort.
>>>>>>>
>>>>>>>So, you think honestly that an JSR is not worth an dedicated Issue?
>>>>>>>
>>>>>>>Feel free.
>>>>>>>
>>>>>>>As I will feel free to reopen the _perfectly_ valid Issues.
>>>>>>>
>>>>>>>The arrogant behaviour [ignoring facts and rationales] of the
>>>>>>>JDT.Core team (IBM) will not hinder me to increase transparency of
>>>>>>>the development, whilst using the resources of this project.
>>>>>>>
>>>>>>>....
>>>>>>>
>>>>>>>except:
>>>>>>>
>>>>>
>>>>>[8]
>>>>>
>>>>>
>>>>>
>>>>>>>You could state what should become obvious to every reader:
>>>>>>>
>>>>>>>"We (IBM) do not want too much transparency within the JDT.Core.
>>>>>>>That's the reason why everything is kept so terribly unorganized
>>>>>>>within _one_ component "Core", including the whole compiler [yes,
>>>>>>>really! the compiler is not an seperated organisational unit]. So,
>>>>>>>don't expect that we will allow you to create a transparent
>>>>>>>dependency-tree, thus everyone is able to understand within minutes
>>>>>>>the status and the interconnections. We will fight this, whilst
>>>>>>>risking to look like dumbs who do not understand the difference
>>>>>>>between a duplicate and a depending-on relation. We will even take
>>>>>>>the risk to state that an JSR is not worth an dedicated issue
>>>>>>>within bugzilla - and has to be marked as invalid."
>>>>>>>
>>>>>>>then I would possibly stop to insist on a transparent issue filing
>>>>>>>within this project.
>>>>>
>>>>>.
>>>>>
>>>>>--
>>>>>http://lazaridis.com
>>>>
>>>>
>
|
|
| |
Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues [message #9733 is a reply to message #9642] |
Fri, 07 January 2005 18:58 |
Eclipse User |
|
|
|
Originally posted by: myname(with.between names).lombardisoftware.com
You stated that Kent way of working is "violating" Eclipe rules, yet you do
not point out which specific rules these are. You also claim that "my way"
of doing things would be in violation of the Eclipse bylaws and the
"transparency directive", which you also do not back up with any direct
reference. The burden of proof of your arguments lies on you, not the rest
of us to disprove them.
All I said was common sense development paradigms I, in my experience as a
developer, would follow and I know that other (open source and commercial)
follows. I say there is nothing that tells anyone to work Bugzilla in a
certain way, and its therefore up to the developer(s)/PMs to handle it. I
can't prove a negative, as in there is no such documents. But you can
certainly prove it wrong on all counts (if such rules actually exists).
Claiming you will be censored is just some cheap stalling tactics. Noone
has censored this thread, and this "proof" can't be worse than this thread.
- Morten Moeller
Lombardi Software
ilias wrote:
> Morten Moeller wrote:
>> Well then why don't you enlighten the rest of us on which specific
>> sections and paragraphs in the Bylaws
>> (http://www.eclipse.org/org/documents/Eclipse BYLAWS 2003_11_10
>> Final.pdf) and Dev process (http://www.eclipse.org/org/documents/Eclipse
>> Development Process 2003_11_09 FINAL.pdf) are violated by Kent Johnson
>> and his way of doing things. Stating it "violates" without any direct
>> pointers to what exactly it violates means nothing.
>>
>> Maybe you can add in a link to the "transparency directive" (and the
>> paragraph[s] in question) that states the JDT teams way of handling
>> Bugzilla is illegal?
>
> [you descriptions violate the dev process of the foundation.]
>
> I'll possibly do this, when i'm sure that i will not be censored again.
>
> And for fairplay reasons, all previous questions of mine should be
> answered.
>
> Again for fairplay reasons, _you_ should point to the documents content
> to backup _your_ sayings about the bugzilla process.
>
> .
>
|
|
| | |
Goto Forum:
Current Time: Sun Oct 06 09:46:30 GMT 2024
Powered by FUDForum. Page generated in 0.06082 seconds
|