Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Javascript: a bug that makes me really sad.... 
Lars,
Of course this is all extremely subjective. Personally I'm not so sure about modern constructs and cleanup being so important. I'm sure the majority of the bugs that are open are about what the user experiences using the tools. Granted the people working on the code will care, but downstream disruption of APIs isn't always a bonus either, because that code base is huge and the human resource to keep up is not... 

It's all a balancing act based on subjective judgement calls...

On 13/07/2015 8:35 PM, Lars Vogel wrote:

Hi Ed,

I think modern Java version and code constructs and code cleanup play
an important role. Even though it is hard to say how important it is
in general, it is important for me. IMHO it is not fun contributing to
an 1.4 Java API in your unpaid time.

But with all things IMHO it is hard to measure exactly which factor is
the most important. I think constant improvements in all areas are key
for a increase flow of contributions.

Best regards, Lars

On Mon, Jul 13, 2015 at 8:12 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:

Lars,

Comments below.

On 13/07/2015 7:52 PM, Lars Vogel wrote:

Looks like most agree that simplifying the contribution process is the
most important part.

Setup is one thing in which Oomph really helps.

Another important things are IMHO a solid and well documented build
setup,

It would be great if a local Tycho build were supported.  I'm not sure how
the projects are built.  But then I'm not sure anyone needs to do builds to
test their contributions.  A self-hosted launch, and launchable unit tests
seem most important for that purpose.  And if Gerrit is supported, that can
trigger builds too...

regular code clean-ups,

Yes, though generally all contributions need to be reviewed, and clean-ups
would tend to be very large to review...  For Oomph itself, I'd prefer
contributions to be more focused than general cleanup.

   update of the code base to modern Java
versions and code constructs,

That to me seems more of a nice to have.  Also, things like gentrification
have significant ripple affect on downstream consumers of the APIs (and as
discussed, in the face of array-based APIs, are even more horrible).

   enablement of Gerrit for the projects
and a working build trigger in Gerrit íncluding the tests.

Yes, that's definitely key.

   I'm not
familiar with the WTP code base but it sounds like they should do some
work here.

I get the sense that this code base is kind of stagnant or more positively
stated, very stable...   I'm not sure for whom this code base is upstream
API for which anything other than enhancements and bug fixes is important.


Best regards, Lars

On Mon, Jul 13, 2015 at 6:46 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:

With Oomph we've worked very hard to provide functional project setups
for
effectively most/all of the core software in the platform SDK, i.e.,
Platform, E4Tools, PDE, JDT, and Equinox.  Unfortunately none of these
teams
have stepped up to support/maintain these for lack of time and resource.
I'm not thrilled with maintaining them, but for the good of the
community,
I'm certainly willing to do that for the time being.

For Oomph itself, the ease of getting started in terms of automatically
setting up a functional workspace prepared to commit contributions to
Gerrit
have definitely resulted in significant Gerrit contributions.   And
because
we use it ourselves, we know that it works for everyone.

As such, it seems pointless to argue that simplifying the contribution
process isn't the biggest hurdle.  It is a significant hurdle and there
is
already a solution, so to me it seems best to exploit that so that we can
indeed address the remaining hurdles.


On 13/07/2015 5:44 PM, Lars Vogel wrote:

I agree with Alex. While a simplification of the build and contribution's
process will not solve big issues immediately it paves the way for new
contributors and committers instead of shying them away.

Am 25.06.2015 4:16 nachm. schrieb "Aleksandar Kurtakov"
<akurtako@xxxxxxxxxx>:

While I agree with you that in this case there are bigger hurdles than
getting started we can't deny that it prevented someone to even try
himself
on real solution according to the comments.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----

From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
To: "eclipse.org-architecture-council"
<eclipse.org-architecture-council@xxxxxxxxxxx>
Sent: Thursday, 25 June, 2015 5:02:59 PM
Subject: Re: [eclipse.org-architecture-council] Javascript: a bug that
makes  me really sad....

I highly doubt that the issue in this particular case is the getting
started
barrier.


-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf
Of
Aleksandar Kurtakov
Sent: Thursday, June 25, 2015 6:58 AM
To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Javascript: a bug that
makes
me really sad....

----- Original Message -----

From: "Doug Schaefer" <dschaefer@xxxxxxx>
To: "Michael Scharf" <eclipse@xxxxxxxxx>,
"eclipse.org-architecture-council"
<eclipse.org-architecture-council@xxxxxxxxxxx>
Sent: Thursday, 25 June, 2015 4:43:01 PM
Subject: Re: [eclipse.org-architecture-council] Javascript: a bug that
makes me really sad....

I suppose that’s almost an existential question on the role of the
Eclipse Architecture Council. At times, I feel the projects have too
much power, the power to make decisions that adversely affect the
Eclipse product as a whole. And I’m sure this extends just beyond the
IDE.

But Eclipse is built as a meritocracy. And really the only people who
have the power to change things like this are the ones contributing
the code to that project. We can try and influence them to make the
right decisions, and I think we are in our right to do that. But that
would require the Architecture council be more vocal about technical
matters and earn the respect of the projects so they’ll have some
incentive
to listen.

Another question that remains open is: What can Eclipse Architecture
Council
do when there is noone willing to do the work?
Comment 9 makes it clear that contributions are more than welcome. But
still
following comments are on the topic of howto build and etc. not on a
real
work to fix the problem.
My personal opinion is that the Architecture Council should look at
ways
to
improve this matter, even adding requirement for Release train projects
to
ensure that if following a known build process one can get to working
on
the
codebase - there is enough from the tech side - Oomph setup files,
Tycho/Maven builds, etc. - but each project ends up with "creative"
releng
procedures making it really hard to start on it. And such a clean room
-
clone/build/install/runtestsuite should be automatable too - assuming
that
there are people willing to work on it as otherwise not much will
happen.

Alex


Doug.

From: < eclipse.org-architecture-council-bounces@xxxxxxxxxxx > on
behalf of Michael Scharf < eclipse@xxxxxxxxx >
Reply-To: Michael Scharf < eclipse@xxxxxxxxx >, Eclipse Architecture
Council < eclipse.org-architecture-council@xxxxxxxxxxx >
Date: Thursday, June 25, 2015 at 9:30 AM
To: Eclipse Architecture Council <
eclipse.org-architecture-council@xxxxxxxxxxx >
Subject: [eclipse.org-architecture-council] Javascript: a bug that
makes me really sad....





Hi,

I am excited about mars being out. But there is a bug, that makes me
really really sad. The most popular eclipse package is JavaEE and it
contains JavaScript. But eclipse supports only JavaScript 1998.

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

The most annoying problem is that modern versions of javascript allow
keywords if they are part of a data structure:

promise.catch(function(){...});
var foo {
default: 42
}




Many libraries use `throw` and `catch` as methods on objects and this
causes a lot of errors and the rest of the file cannot be parsed.

I know there are a lot of different javascript solutions out there
that work better than this. But, the out of box experience with
eclipse is, well suboptimal.

Is there anything the architecture council can do about this?


Michael


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other
than the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients
is not authorized and may be unlawful.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-coun
cil

IMPORTANT: Membership in this list is generated by processes internal
to the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx


https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal
to
the
Eclipse Foundation.  To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx


https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal
to
the
Eclipse Foundation.  To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list, you
must
contact emo@xxxxxxxxxxx to request removal.



_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to
the
Eclipse Foundation.  To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.



_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to
the
Eclipse Foundation.  To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.




_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation.  To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.

Back to the top