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....

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.



-- 
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com


Back to the top