Somewhere, not necessarily on the front page, some tips for people wondering 
where the project is heading would be good.  Not a list of plans, but orienting 
info like "no one knows", and an explanation of how to get a sense of current 
(i.e., for 0.4 right now) and future issues from the bug tracker.

I found the tip I got awhile ago to search on a particular tag (0.4?) and sort 
by bug/issue activity pretty helpful.

BTW, is 0.4 still in a "you don't want to go there" state for users of julia?

Ross
________________________________
From: julia-users@googlegroups.com [julia-users@googlegroups.com] on behalf of 
David Anthoff [anth...@berkeley.edu]
Sent: Wednesday, December 10, 2014 5:38 PM
To: julia-users@googlegroups.com
Subject: RE: [julia-users] Roadmap

Thanks, this is really useful! I would very much cherish an email like this 
maybe after a release from some of the core team members. It just gives a nice 
insight into the current plans.

Cheers,
David

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of John Myles White
Sent: Wednesday, December 10, 2014 4:56 PM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Roadmap

FWIW, my sense is that no one really knows what's going to happen between 0.4 
and 1.0. There are lots of projects that are seen as essential before 1.0, but 
many of those are tenatively on the 0.4 release targets (static compilation, 
array views, package documentation, etc.).

At JuliaCon, I realized that I was one of the longest standing users of Julia 
-- many people at JuliaCon had never tried Julia 0.1 and therefore don't 
remember how much the 0.2 release improved the language and redefined the way 
Julia code was written. I feel like 0.4 is going to be a similar release: a lot 
of the most egregious problems with the current version of Julia are going to 
be fixed. But once those problems are solved, it seems hard to believe that we 
won't start realizing that there are lots of parts of the language that could 
be cleaned up before 1.0. My sense is that Julia, like ggplot2, will start to 
be mature enough for almost all users well before 1.0 is released, but that1.0 
will still thankfully have the freedom to make any changes that are necessary 
before something gets declared as the "finished" product.

 -- John

On Dec 10, 2014, at 4:45 PM, David Anthoff 
<anth...@berkeley.edu<mailto:anth...@berkeley.edu>> wrote:


I hear you, and I didn’t think much before sending my email. Couple of points:

I totally agree this should certainly not be on the homepage. I also agree that 
there is no need for a detailed schedule, deadlines or anything like that. I 
think the only thing that would be immensely helpful at least for me is just a 
very high level idea of what the core team is thinking about a roadmap/timing. 
Do you expect a 1.0 more in 10 years, or more in 1 year? Do you right now 
expect there to be a 0.5, 0.6, or many more releases before a 1.0? My gut guess 
is that the core team has an idea about those kinds of questions, and it would 
be great if you could share that kind of stuff from time to time. Maybe one 
idea here would be that the core team just sends out a brief email after a 
major release what the current thinking is about the next version and the road 
to 1.0? Such an email could be fuzzy and non-committal if the plans are fuzzy, 
but that in itself would also be valuable information for us users.

I am following the issue tracker and am subscribed to the email lists, and I 
don’t get any sense/picture about those kind of high level questions from those 
sources.

Cheers,
David

From: julia-users@googlegroups.com<mailto:julia-users@googlegroups.com> 
[mailto:julia-users@googlegroups.com] On Behalf Of Tony Kelman
Sent: Wednesday, December 10, 2014 4:31 PM
To: julia-users@googlegroups.com<mailto:julia-users@googlegroups.com>
Subject: Re: [julia-users] Re: home page content

-1 on trying to put plans, schedule, roadmap on the website. "This week in 
Julia" was a great contribution to the community but evidently took more effort 
than Matt had time to keep up with.

New features get developed as the PR's for them get worked on and finished. You 
can subscribe to just the subset of issues/PR's for things you (along with 
everyone else) are eagerly awaiting. Better yet, help with testing and code 
review if you can.

We have been doing a good job of monthly backport bugfix releases, we should be 
able to continue doing that. But 0.4 is still unstable and has several 
big-ticket items still open and being worked on (check the milestones on 
github). It's too early to try to make time estimates, if people are impatient 
and want a release sooner it's not going to be possible without punting on a 
number of targeted features and pushing them back to 0.5 or later.


On Wednesday, December 10, 2014 1:58:52 PM UTC-8, Randy Zwitch wrote:
I think it would please everyone if you moved daily televised scrums.


On Wednesday, December 10, 2014 4:53:50 PM UTC-5, John Myles White wrote:
Stefan, I shared your moment of terror about the idea of posting plans 
(essentially all of which will be invalidated) to the home page.

Although it's huge volume of e-mail, I do feel like people who want to keep up 
with new developments in Julia should try to subscribe to the issue tracker and 
watch decisions get made in real time. It's a large increase in workload to ask 
people to both do work on Julia and write up regular reports about the work.

 -- John

On Dec 10, 2014, at 1:48 PM, Stefan Karpinski 
<ste...@karpinski.org<mailto:ste...@karpinski.org>> wrote:



I have to say the concept of putting plans up on the home page fills me with 
dread. That means I have update the home page while I'm planning things and as 
that plan changes and then do the work and then document it. It's hard enough 
to actually do the work.

On Wed, Dec 10, 2014 at 4:44 PM, David Anthoff 
<ant...@berkeley.edu<mailto:ant...@berkeley.edu>> wrote:
+1 on that! Even vague plans that are subject to change would be great to have.

From: julia...@googlegroups.com<mailto:julia...@googlegroups.com> 
[mailto:julia...@googlegroups.com] On Behalf OfChristian Peel
Sent: Wednesday, December 10, 2014 10:15 AM
To: julia...@googlegroups.com<mailto:julia...@googlegroups.com>
Subject: Re: [julia-users] Re: home page content

One thing that I would very much appreciate is some kind of development 
schedule.  For example
  - Some kind of general roadmap
  - a plan for when 0.4 and future releases will come
  - Any plans to switch to a regular schedule?  (yearly, six
    months, ...)
  - What features remain before a 1.0 release?
  - When will following arrive?
    > faster compilation
    > pre-compiled modules
    > Interactive debugging; line numbers for all errors
    > Automatic reload on file modification.
    > Solving P=NP

I know that it's tough to make such a schedule, but anything that you can 
provide would be helpful. Also, I'd be happy for something like a weekly 
update; or a weekly blog post to help those who don't peruse this group in 
depth each day.

Thanks!

Chris

On Wednesday, December 10, 2014 5:41:35 AM UTC-8, Tamas Papp wrote:
>From the discussion, it looks like that homepages for programming
languages (and realed projects) serve two purposes:

A. provide resources for the existing users (links to mailing lists,
package directories, documentation, etc)

B. provide information for potential new users (showcasing features of
the language, links to tutorials).

Given that space on the very front page is constrained (in the soft
sense: no one wants pages that go on and on any more), I think that
deciding on a balance between A and B would be a good way to focus the
discussion.

Once we have decided that, we can shamelessly copy good practices.

For example,

1. the R website emphasizes content for existing users (in a non-flashy
way that I am OK with), with very little material for new users,

2. about 1/3 of the middle bar on
https://www.haskell.org/haskellwiki/Haskell is for new users
(explanations/tutorials/etc), the 1/3 is for existing users (specs,
libraries), and the final 1/3 is for both (forums, wiki, etc),

3. http://new-www.haskell.org/ is mostly caters to potential new users
("see how great this language is"),

4. the content of clojure.org<http://clojure.org/> is similarly for potential 
new users,
while the sidebar has links for existing users.

Best,

Tamas

On Wed, Dec 10 2014, Hans W Borchers 
<hwbor...@gmail.com<mailto:hwbor...@gmail.com>> wrote:

> Look at the R home page. R is one of the most popular languages, and esp. so
> for statistical and computational applications. A programming language does
> not need bloated home pages.
>
> I like the old Haskell home page much more than the new one. The new one
> has
> large, uninformative background pictures and not much information in a
> small
> and readable view. The HaskellWiki front page was much better in that. It
> may
> not even be decided which version will win.
>
> [Clojure])http://clojure.org/) has a nice, simple and informative home
> page,
> while [Scala](http://www.scala-lang.org/) has overdone it like the new
> Haskell. For other approaches see the [Nim](http://nimrod-lang.org/) -
> formerly 'Nimrod' - and [Nemerle](http://nemerle.org/) home pages.
>
> In the end I feel the condensed form of the Python home page will attract
> more interest, for example with 'latest news' and 'upcoming events' on the
> first page.This gives the impression of a lively and engaged community.
>
>
> On Wednesday, December 10, 2014 11:23:37 AM UTC+1, Tim Holy wrote:
>>
>> I like the Haskell one better than the Rust one.
>>
>> --Tim
>>
>>

Reply via email to