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

[ilias <ilias@xxxxxxxxxxxxx>]

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.
> >
> > -
> >
> > 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&group=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