[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[News.eclipse.foundation] Re: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues
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