Eclipse Community Forums: Technology Project and PMC » Decision making process in Eclipse project?

Help

Home

Home » Eclipse Projects » Technology Project and PMC » Decision making process in Eclipse project?

Show: Today's Messages :: Show Polls :: Message Navigator

Decision making process in Eclipse project? [message #58768]

Sun, 12 October 2003 11:33

Eclipse User

Originally posted by: derisor.arcor.de

I am curious about the decision making process in Eclipse. The reason that I am
so curious is that I am used to working with apache projects which have
something of a democratic system in their decisions about code implementation
procedures. In addition the process of submitting patches or code to apache
projects is rather fast.

I recently filed some issues with SWT in particular and it seems a couple of
them were flat vetoed by one single person at IBM.

Re:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=44111
https://bugs.eclipse.org/bugs/show_bug.cgi?id=43007

In addition, I did a rather significant piece of code that is important and
submitted it and it has so far been ignored completely.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=43990

It is certainly discouraging to people that want to get involved to be merely
ignored.

So is there some process behind the Eclipse project or is it just run primarily
according to the whims of a few people at IBM? If so then I wont bother wasting
my time making contributions and having them ignored.

-- Robert

Report message to a moderator

Re: Decision making process in Eclipse project? [message #58870 is a reply to message #58768]

Mon, 13 October 2003 16:42

Jean-Christophe Deprez

Messages: 133
Registered: July 2009

Senior Member

> I recently filed some issues with SWT in particular and it seems a couple of
> them were flat vetoed by one single person at IBM.
true, some people tend to get 'snippy' and will give some ideas more
consideration based on from whom they are coming. but as most
open-source projects are, this is a meritocracy.
>
> Re:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=44111
first, this should have been filed as an RFE, not a bug. what the
responder is saying that this is functioning as designed.

second, the entire concept of SWT is to directly call the underlying
OS's procedure for accomplishing the task (if it exists). absolutely no
other functionality is added by design. if anything, this RFE should be
submitted with the OS, since it is the OS that does not check for valid
styles. SWT merely sends the information to the underlying OS call. it
does not act on and has no knowledge of the information at all. this is
a basic SWT concept which is conveyed in much of the SWT documentation
out there.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=43007
swt is its own project and a link to its web page can be found at:

http://www.eclipse.org/platform/index.html

it has no more or less billing than any other eclipse technology. in
addition, you can download SWT separately on the download page.
> In addition, I did a rather significant piece of code that is important and
> submitted it and it has so far been ignored completely.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=43990
>
first, you just submitted this less than two weeks ago, at a time when
every one is working hard to push the M4 build out the door. any new
code clearly won't be considered this close to a milestone release. now
that M4 is out is when you should begin pushing new ideas.

second, the method:

public boolean hooks(final int eventType) {
synchronized (this.eventMap) {
return (getListenerMap(eventType) == null);
}
}

should be changed to:

public boolean hooks(final int eventType) {
synchronized (this.eventMap) {
return (getListenerMap(eventType) != null);
}
}

third, although this class is not serializable, who knows what bizarre
uses it (or its derived classes) may hold in the future. i can't think
of any reason this would become serializable, but just to be safe
eventMap (and anything that holds listener references) should be marked
as <transient>, and the readObject(...) method should be used to
reinitialize it. of course, then eventMap can't be final, so it's a
trade off...

fourth, i'm not an expert at weak references, but i don't think this
code will work. consider the following (generic) method many people use
to write event code. I don't know the code, so i'm sure some of it is
incorrect, but it conveys the concept:

eventTable.hook(
SWT.SOME_EVENT, new EventListener() {
public void handleEvent(Event e) {
...
}
}
);

this uses an anonymous inner class to handle the event, so there are no
references. the only strong reference would normally be is the one in
the event map. using the WeakHashMap, there are no strong references.
this anonymous inner class instance may be finalized and cleaned up at
any time; sometimes the event won't be 'heard'. in fact, i think it's
standard procedure not to have a reference for events that you know will
never be unhooked. did you compile and test this code extensively?

> It is certainly discouraging to people that want to get involved to be merely
> ignored.
>
nothing happens instantly in an open-source project. just because the
originator of an idea thinks it's a good one doesn't mean everyone will
think it's worthwhile. enough people have to learn of and support an
idea for it to become reality. it is up to you to 'advertise' your ideas
and convince people of their merit. that's one of the reasons why these
newsgroups exist.
> So is there some process behind the Eclipse project or is it just run primarily
> according to the whims of a few people at IBM? If so then I wont bother wasting
> my time making contributions and having them ignored.
>
this project is a very large effort involving a lot of people. many of
these people are very talented. people are not going to drop what they
are doing just because some new guy thinks they have a great idea. no
offense intended with the wording there, just trying to convey the point
as succinctly as possible. as i mentioned above, eclipse is a
meritocracy; people start at the bottom. this is necessary with all
open-source projects because many people become excited about a project
but then lose interest; a lot of time would be wasted with people who
don't follow through with their ideas. it is only those with proven
dedication to the project that have a large say in its direction. if
someone new has a good idea it is up to them to 'sell' it to those with
more influence. as they continue to make valuable contributions their
value to the community will go up.

as a friend of mine used to say, "you catch more bees with honey than
you do with vinegar". the tone of your post probably won't help your
case any and it probably won't get you favored treatment in the future.

-alvin

Report message to a moderator

Re: Decision making process in Eclipse project? [message #58920 is a reply to message #58870]

Mon, 13 October 2003 20:43

Eclipse User

Originally posted by: derisor.arcor.de

"Alvin Thompson" <nobody@nowhere.com> wrote in message
news:3F8AD60B.2020101@nowhere.com...
> > I recently filed some issues with SWT in particular and it seems a couple of
> > them were flat vetoed by one single person at IBM.
> true, some people tend to get 'snippy' and will give some ideas more
> consideration based on from whom they are coming. but as most
> open-source projects are, this is a meritocracy.

An idea is an idea, regardless of where it comes from. Given some of the code
quality in SWT, I would think they need every bit of help they can get.

> >
> > Re:
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=44111
> first, this should have been filed as an RFE, not a bug. what the
> responder is saying that this is functioning as designed.
>
> second, the entire concept of SWT is to directly call the underlying
> OS's procedure for accomplishing the task (if it exists). absolutely no
> other functionality is added by design. if anything, this RFE should be
> submitted with the OS, since it is the OS that does not check for valid
> styles. SWT merely sends the information to the underlying OS call. it
> does not act on and has no knowledge of the information at all. this is
> a basic SWT concept which is conveyed in much of the SWT documentation
> out there.
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=43007
> swt is its own project and a link to its web page can be found at:
>
> http://www.eclipse.org/platform/index.html
>
> it has no more or less billing than any other eclipse technology. in
> addition, you can download SWT separately on the download page.

This page is still merely a description of SWT as a component of Eclipse whereas
it has become a technology in its own right.

> > In addition, I did a rather significant piece of code that is important and
> > submitted it and it has so far been ignored completely.
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=43990
> >
> first, you just submitted this less than two weeks ago, at a time when
> every one is working hard to push the M4 build out the door. any new
> code clearly won't be considered this close to a milestone release. now
> that M4 is out is when you should begin pushing new ideas.

Im pretty much convinced that there is little reason to bother. There is no
voting process or other process that I can tell. When I merely suggested the
source should be documented and formatted, some people at IBM threw a fit. You
would have thought I asked them to murder their firstborn.

>
> second, the method:
>
> public boolean hooks(final int eventType) {
> synchronized (this.eventMap) {
> return (getListenerMap(eventType) == null);
> }
> }
>
> should be changed to:
>
> public boolean hooks(final int eventType) {
> synchronized (this.eventMap) {
> return (getListenerMap(eventType) != null);
> }
> }

Good catch.

>
> third, although this class is not serializable, who knows what bizarre
> uses it (or its derived classes) may hold in the future. i can't think
> of any reason this would become serializable, but just to be safe
> eventMap (and anything that holds listener references) should be marked
> as <transient>, and the readObject(...) method should be used to
> reinitialize it. of course, then eventMap can't be final, so it's a
> trade off...

Why would you serialize a gui component? And the original class isnt
serializable either.

> fourth, i'm not an expert at weak references, but i don't think this
> code will work. consider the following (generic) method many people use
> to write event code. I don't know the code, so i'm sure some of it is
> incorrect, but it conveys the concept:
>
> eventTable.hook(
> SWT.SOME_EVENT, new EventListener() {
> public void handleEvent(Event e) {
> ...
> }
> }
> );

First of all, anonymous classes are extremely bad practice. I could enumerate
the problems with them but it would take pages and pages just to get started.
You can check out my book, Hardcore Java, which should be published in a couple
months by O'Reilly.

Second of all, creating a new object and dumping it into nowhere is a bad idea
as well.

Third of all, if this was held in a strong reference, there would be no way to
unhook the event. This can lead to extremely HUGE memory leaks... consider ...

eventTable.hook(
SWT.SOME_EVENT, new EventListener() {
Dialog dlg;
public void handleEvent(Event e) {

dlg = new Dialog(shell, STYLE);
// add 12 composites with multiple widgets ad attached to data
objects.
// Link the widgets into data objects using jface
// show the dialog.
}
}
);

In this case, event listener will hold onto the dialog and all of its controls
and so on forever and there is absolutely no way to unhook it and make the
references go away.

If you absolutely insist on using anonymous classes, you should store their
instances so that on dispose the window can unhook them. The more circular
strong references you have in code, the more potential for huge memory leaks.

To summarize:

1) Anonmyous classes are bad but if you insist on using them, store their
instances in class variables.
2) Memory leaks are caused by circular strong references.

>
> this uses an anonymous inner class to handle the event, so there are no
> references. the only strong reference would normally be is the one in
> the event map. using the WeakHashMap, there are no strong references.
> this anonymous inner class instance may be finalized and cleaned up at
> any time; sometimes the event won't be 'heard'. in fact, i think it's
> standard procedure not to have a reference for events that you know will
> never be unhooked. did you compile and test this code extensively?
>
> > It is certainly discouraging to people that want to get involved to be
merely
> > ignored.
> >
> nothing happens instantly in an open-source project. just because the
> originator of an idea thinks it's a good one doesn't mean everyone will
> think it's worthwhile. enough people have to learn of and support an
> idea for it to become reality. it is up to you to 'advertise' your ideas
> and convince people of their merit. that's one of the reasons why these
> newsgroups exist.

Everyone? From what I can tell individuals are making the vetos. There is no
voting process that I can see so the word "everyone" is rather a misnomer.

> > So is there some process behind the Eclipse project or is it just run
primarily
> > according to the whims of a few people at IBM? If so then I wont bother
wasting
> > my time making contributions and having them ignored.
> >
> this project is a very large effort involving a lot of people. many of
> these people are very talented. people are not going to drop what they
> are doing just because some new guy thinks they have a great idea. no
> offense intended with the wording there, just trying to convey the point

Who said they have to drop what they are doing. However when vicious replys hit
bug tracking and bugs are closed spontaneously because of one person's opinion
then it isnt open source. Its ... something else.

> as succinctly as possible. as i mentioned above, eclipse is a
> meritocracy; people start at the bottom. this is necessary with all
> open-source projects because many people become excited about a project
> but then lose interest; a lot of time would be wasted with people who

People loose interest because they submit ideas and are relied to with hostility
or ignored.

> don't follow through with their ideas. it is only those with proven
> dedication to the project that have a large say in its direction. if
> someone new has a good idea it is up to them to 'sell' it to those with
> more influence. as they continue to make valuable contributions their
> value to the community will go up.

I spend a horde of time at work trying to sell the right ideas to managers so
politically married to their code that they cant see the issues in it. I would
have hoped in open source commuinity the emphasis would have been on getting
things done right. As a regular contributor to apache projects I can say that
they DO have such a process and drive and it works. I could MURDER the code
quality of SWT if I wanted to. However, instead of merely bitching, I offer my
services and am attacked or ignored. Since I am no one important I doubt my
experience is unique.

Eclipse needs a process. Something similar to the apache process.

> as a friend of mine used to say, "you catch more bees with honey than
> you do with vinegar". the tone of your post probably won't help your
> case any and it probably won't get you favored treatment in the future.
>
> -alvin

I dont expect "favored" treatment. I expect people to act like professionals and
people who are more concerned about doing things right. Developers that treat
code as if it was their baby and anyone suggesting changes is murdering their
baby need to get a reality check. My "tone" is matter of fact indication of
annoyance at what i have seen not just recently but over several months. Im not
in open source to play politics, Im in it to write good code.

-- Robert

Report message to a moderator

Re: Decision making process in Eclipse project? [message #58969 is a reply to message #58920]

Tue, 14 October 2003 00:27

Jean-Christophe Deprez

Messages: 133
Registered: July 2009

Senior Member

> An idea is an idea, regardless of where it comes from. Given some of
the code
> quality in SWT, I would think they need every bit of help they can get.

are we now discussing code quality or are we discussing your issues with
the decision-making process?

> This page is still merely a description of SWT as a component of Eclipse whereas
> it has become a technology in its own right.

i agree on this. a more 'independent' home page (in addition to the
current one) is warranted.

> First of all, anonymous classes are extremely bad practice.

anonymous classes are extremely bad practice? i use them extensively in
event code and i like to think of myself as a reasonably accomplished
programmer. please convince me of this.

besides, your original assertion was that there would be no other
changes needed in the eclipse code. now it seems using your code would
require rewriting all event code to not use anonymous nested classes, as
well as ensuring that no future submissions use them. that's a lot of
work for everyone else just because you don't like that particular
programming style.

> Second of all, creating a new object and dumping it into nowhere is a bad idea
> as well.

i don't understand this statement. please explain it.

> Third of all, if this was held in a strong reference, there would be no way to
> unhook the event. This can lead to extremely HUGE memory leaks... consider ...
>
> eventTable.hook(
> SWT.SOME_EVENT, new EventListener() {
> Dialog dlg;
> public void handleEvent(Event e) {
>
> dlg = new Dialog(shell, STYLE);
> // add 12 composites with multiple widgets ad attached to data
> objects.
> // Link the widgets into data objects using jface
> // show the dialog.
> }
> }
> );
>
> In this case, event listener will hold onto the dialog and all of its controls
> and so on forever and there is absolutely no way to unhook it and make the
> references go away.

true, the code above will hold on to the most recent dialog object and
its members indefinitely. until it is called again, BUT:

first, it is poorly written NOT because it hangs on to the Dialog object
(it should), but rather because it creates a new Dialog object every
time it is called instead of reusing the old one. the first rule of
event management code is to never--ever--create objects unless you
absolutely have to; if you must use an object, hold on to it for reuse.

second, i have looked at a lot of code and i have never seen anyone
write an anonymous nested class that used its own members to hold
disposable objects. what would be the point? while it is permissible to
use contrived examples to prove a point, this one is so unlikely as to
be unreasonable to expend effort accounting for.

third, if this (or any) framework were to try to account for every
possible user's bad programming practice, it would be very large and
very slow (well, larger and slower :) .

fourth, this code could be easily written without the anonymous inner
class and it would exhibit the same behavior.

> If you absolutely insist on using anonymous classes, you should store their
> instances so that on dispose the window can unhook them. The more circular
> strong references you have in code, the more potential for huge memory leaks.
>
> To summarize:
>
> 1) Anonmyous classes are bad but if you insist on using them, store their
> instances in class variables.
> 2) Memory leaks are caused by circular strong references.

does creating new objects during event dispatch have the potential for
memory leaks? of course. but that has nothing to do it being in an
anonymous inner class.

where are the circular references here? i don't see any. but i DO know
that the garbage collector is smart enough to reclaim unused circular
references (that's java 101). i also know that WeakHashMap IS NOT smart
enough to know that a strong reference to an object is circular (that's
java 102).

> Everyone? From what I can tell individuals are making the vetos. There is no
> voting process that I can see so the word "everyone" is rather a misnomer.

on the bottom of every bug report/RFE page there is the link 'vote for
this bug'. if people think it is a good idea, they will vote for it.

> People loose interest because they submit ideas and are relied to with hostility
> or ignored.

i have not observed anyone being especially hostile to you. on the other
hand, you seem to be exceptionally combative in this newsgroup. you
cannot expect people to be cooperative when you take this tone. please
don't give me any 'he started it' arguments as i would find it hard to
believe.

> I dont expect "favored" treatment. I expect people to act like professionals and
> people who are more concerned about doing things right. Developers that treat
> code as if it was their baby and anyone suggesting changes is murdering their
> baby need to get a reality check.

it is hard to expect others to act like a professional when you yourself
do not. you started your last post impugning the code quality in SWT.
how is this constructive? in a way, the code IS their baby; they have
put a lot of time and effort into it. if you were a parent and someone
told you that your baby was ugly, you would take offense as well. you
claim your code is better, but the SWT team has produced an actual
working product whereas you have not, a product that you yourself admit
that many people wish to use.

> ... Im not
> in open source to play politics, Im in it to write good code.

you are obviously young if you make this statement, so i will give you a
very good piece of advice: everything in life involves playing politics
to some degree. if you do not make an effort to 'play well' with others
you entire life will be much more difficult. this problem you are having
with the SWT developers is just one example. are there others?

sincerely,
alvin

Report message to a moderator