Enhancements in the IDE
iulian dragos
contributions, and one thing I heard several times was that there is
no easy way to find something to work on in the IDE. So I put together
a list of tickets that are relatively self-contained enhancement
requests:
https://www.assembla.com/spaces/scala-ide/milestones/454722-enhancements
I gathered them from different people, on twitter or email
conversations. I thought this would be a great place to start for
(new) contributors, shopping for ideas to implement in the IDE :) For
instance, semantic highlighting is one such useful feature that would
be well-delimited, a project wizard for compiler plugins is another.
If you feel inclined to tackle one of them, please just go ahead
(assign the ticket to you and maybe drop a line so people don't all
work on the same thing).
What else could we do to make it easier for people to contribute?
cheers,
iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Eugene Vigdorchik
search. While this is big, it is an invaluable addition. --Eugene.
Martin Ellis
> What else could we do to make it easier for people to contribute?
Update this:
https://www.assembla.com/spaces/scala-ide/wiki/Hacking_and_Testing
If that process is deprecated... then what do you use?
How do you set up the target platform?
Martin
Martin Ellis
> Update this:
> https://www.assembla.com/spaces/scala-ide/wiki/Hacking_and_Testing
Sorry. Excuse my tone. I was aiming for brevity and achieved rudeness.
Martin
iulian dragos
> On 1 September 2011 20:33, Martin Ellis <mar...@ellis.name> wrote:
>> Update this:
>> https://www.assembla.com/spaces/scala-ide/wiki/Hacking_and_Testing
The first paragraph (using the Equinox Weaving Launcher) is all that
is needed to enable weaving in the target platform. I edited a bit the
page, hopefully it's a bit clearer now. Let me know if it makes sense
(if you are a watcher of the space, you can edit the wiki as well).
> Sorry. Excuse my tone. I was aiming for brevity and achieved rudeness.
No problem, I perceived only the brevity ;-)
cheers,
iulian
>
> Martin
David Bernard
iulian dragos
<david.be...@gmail.com> wrote:
> Iulian,
> How/delay contribution will be back to a public update-site ?
I don't know what you are referring to.
> And more personnal question, is it planned to grab some code from 1.x.y to
> 2.1+ or not ?
I'm sorry, we kind of let that idea drop. I would like to get back to
it and see what we can port... should I call it forward-port from
backport? :) My head spins already. Let's discuss again once a final
is out.
iulian
David Bernard
On Wed, Sep 7, 2011 at 9:07 PM, David BernardI don't know what you are referring to.
<david.be...@gmail.com> wrote:
> Iulian,
> How/delay contribution will be back to a public update-site ?
iulian dragos
<david.be...@gmail.com> wrote:
>
>
> On Thu, Sep 8, 2011 at 17:15, iulian dragos <jagu...@gmail.com> wrote:
>>
>> On Wed, Sep 7, 2011 at 9:07 PM, David Bernard
>> <david.be...@gmail.com> wrote:
>> > Iulian,
>> > How/delay contribution will be back to a public update-site ?
>>
>> I don't know what you are referring to.
>
> I try to rephrase : What is the process between the time when a contribution
> is send (as patch or as a branch) and when it is present into nightly or
> "release" ?
> eg: Since few month 2.0.0 is "feature freeze" and submission/contribution
> (from out of Typesafe) to the plugin are postponed to 2.1+ (mainly because
> you roadmap and expect some stability).
Thanks for the explanations. I agree with you that this is not great,
but IMO absolutely necessary if we want to have something reliable as
a first release. Note though, feature freeze was concerned with using
the presentation compiler (the main source of errors, with high
potential to break everything in the IDE). Disconnected features were
merged back to 2.0 (like semicolon inference, formatter configuration,
and maybe others I do not remember now). However, any contribution
that fixes a bug in the existing feature set will be included as soon
as the code review says 'OK'.
There have been delays in code reviews, and I take responsibility for
that. I'll try to be more responsive, and hopefully others will offer
to code review as well. We need to find a better tool for reviews,
maybe move to github (but that's another thread of discussion).
> IMHO :
> * It doesn't encourage contribution, if it take several month to see your
> work available to other.
Ouch! Yes. Do you propose to split 2.1 already now, and let new
contributions there, while we commit fixes to both 2.0 and 2.1?
Note that this is somewhat of a special situation, but once a stable,
release branch exists (after the final), we'll all be contributing to
2.1 and the barrier for entry will be low. People would always have a
stable 'channel' to turn to, if the 2.1 nightly has regressed beyond
being usable.
> * It increase the work of the contributor who want to use (test) his
> contribution (S), he need to provide its own update-site and to continuously
> merge,...
> * It can increase the work of the final integrator, if the contribution is
> based on old code (several months)
(that should be still the contributor) ;-)
iulian