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