[News.eclipse.foundation] Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfu

["Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>]

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@xxxxxxxxxxxxx> wrote in message 
news:crheh8$sda$1@xxxxxxxxxxxxxxxxxx
> 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=80775
>
> I ask you friendly to not further ignore my rationales.
>
>> /mike
>>
>> "ilias" <ilias@xxxxxxxxxxxxx> wrote in message 
>> news:crbl08$gjo$1@xxxxxxxxxxxxxxxxxx
>>
>>>>> 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@xxxxxxxxxxxxx> wrote in message 
>>>> news:cr5sji$i45$1@xxxxxxxxxxxxxxxxxx
>>>>
>>>>> 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&group=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