Keeping better track of Julia as a project

[Iain Dunning]

Yo,

So today I saw "array nirvana" (https://github.com/JuliaLang/julia/issues/7941) get bumped and various out-standing PRs and issues were linked. I started following down the chain of PRs and I thought that maybe Julia as a project might be reaching a sort of scale that is getting harder to reckon with. Certainly the number of outstanding issues/PRs on 0.4-projects is intimidating.

I just put up a simple little chart by trawling through some of those issues, and its actually shallower than I thought:

https://github.com/IainNZ/JuliaPRTrack

Now I don't really have the ability to contribute to base much, so I don't really benefit from this sort of thing too much as I'm not the one doing the work. But, would something like this be useful? Or is it not really solving a real problem?

Anyway, was interesting to have a browse through the issues.

Cheers,

Iain

[Tim Holy]

+1 from me!

But it might be very incomplete. As an example, it would be interesting to find
out from Jameson whether there's more holding up the "package load times"
issue. I kinda suspect that this is one of those many-headed hydras that
requires deep changes in many places. Even I can't tell whether his recently-
merged cool work on "SSA optimized gensyms" was something he found he needed
for that issue, or whether it was an independent improvement.

--Tim

[Jameson Nash]

the work on optimizing gensym variables was actually in support of "making struct passing work properly" (https://github.com/JuliaLang/julia/pull/7906) which has made a lot of progress this weekend.

fwiw, in my issues, I usually try to build up the graph mentioned by Iain in whichever issue I consider to be the task driver. this helps me keep track of other considerations, and other issues to close, as work progresses. if that issue doesn't exist to my liking, i'll open a new one. sometimes there's then a meta issue linking those all together (or the milestone), that forms the root of the graph. i think a lot of this structure comes from what is easiest to maintain – a wiki seems harder to keep updated since it is disconnected to github.

i think another approach to better maintaining this information would to suggest editing the top post more frequently (for those with access privileges to do so) to summarize the current status of the issue and open questions in the sometimes prolonged discussion that follows.

at this point, i think  the "package load times" PR only has a single item on my list of blocking issues: finding time to work through the api considerations

i'm usually happy to respond to pings on github issues with a status update, although i realize that those too can get somewhat lost in the rapid flow of information on the julia github pages.

[Tim Holy]

On Monday, February 02, 2015 05:26:28 AM Jameson Nash wrote:
> i think another approach to better maintaining this information would to
> suggest editing the top post more frequently (for those with access
> privileges to do so) to summarize the current status of the issue and open
> questions in the sometimes prolonged discussion that follows.

That's a pretty good idea.

--Tim