On Jan 19, 2012, at 8:02 AM, Andrei Alexandrescu wrote:
> 
> 5. Leandro has the strong opinion that we don't need additional tools. He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.

To be fair, Leandro wrote a "mostly parallel" GC for D which incorporates precise scanning and it's been pretty much entirely ignored for ages now.  He's contributed in a number of other areas as well, and I consider him a valuable member of the community in terms of code contribution, despite any recognition for his work.  He's also possibly the first contributor to druntime besides myself, as he's been involved since it was a part of Tango.

As a qualifier for the above, I do feel somewhat responsible for Leandro's GC being ignored (the CDGC branch has languished since before we move to github).  I'd love to change this, but I simply don't have the time to invest right now.  The best I can do is point at it and hope others take interest.

I'd be interested in integrating Leandro's changes *but only if* the compiler is modified to generate pointer offset information in TypeInfo first.  I'm currently not a DMD developer and I don't have time to learn my way around that codebase so I won't be writing that patch.  Last time I tried to add precise heap scanning it went nowhere because I used templates and CTFE to generate this and it didn't play nicely with RTTI.

Bottom line:  I'm willing to put in the effort but only if I can be reasonably confident that it won't be wasted.

On Thu, Jan 19, 2012 at 2:08 PM, Sean Kelly <sean at invisibleduck.org> wrote:

> On Jan 19, 2012, at 8:02 AM, Andrei Alexandrescu wrote:
> >
> > 5. Leandro has the strong opinion that we don't need additional tools.
> He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.
>
> To be fair, Leandro wrote a "mostly parallel" GC for D which incorporates
> precise scanning and it's been pretty much entirely ignored for ages now.
>  He's contributed in a number of other areas as well, and I consider him a
> valuable member of the community in terms of code contribution, despite any
> recognition for his work.  He's also possibly the first contributor to
> druntime besides myself, as he's been involved since it was a part of Tango.
>
> As a qualifier for the above, I do feel somewhat responsible for Leandro's
> GC being ignored (the CDGC branch has languished since before we move to
> github).  I'd love to change this, but I simply don't have the time to
> invest right now.  The best I can do is point at it and hope others take
> interest.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20120119/326c1499/attachment.html>

On 1/19/12 11:55 AM, Leandro Lucarella wrote:
> Andrei Alexandrescu, el 19 de enero a las 10:02 me escribiste:
>> 5. Leandro has the strong opinion that we don't need additional tools. He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.
>
> Sometimes you can be such an asshole... You don't just ignore my work on D, but you even make fun of the fact that my work has been ignored. Is just so hard for me to control my impulse to just start cursing at you that you have no idea.

I apologize for what must be my ignorance. I know you made some large contributions to the GC in the past, but I don't have much knowledge of your recent work. I am sorry that your GC contributions have not bore fruit yet, but on the plus side a lot of things we've done recently (including this now dead initiative) is to make sure such contributions are not ignored.

My reply was based on a github search for your recent contributions to the project, without finding many (but then maybe I didn't search for the right thing). I now searched bugzilla and found 184 bugs in which you were involved in either role (http://d.puremagic.com/issues/buglist.cgi?emailcc2=1&emailreporter2=1&query_format=advanced&emailtype2=substring&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email2=LUCARELLA&emailassigned_to2=1). But comments include _use_ of D as opposed to work _on_ D, so I restricted the search to all issues reported by you and found a total of 51.

Again, this is more about the work on D, not work with D; you clearly are a major D user. I'm sure I'm guilty of misperception, but on a regular basis I don't gather the feeling you have participated actively in D-Programming-Language, so I was a bit surprised by your strong participation in this particular discussion and your reaction of now. I apologize for such and I'm glad to be wrong.


Thanks,

Andrei

On 19 jan 2012, at 17:02, Andrei Alexandrescu wrote:

> On 1/19/12 9:26 AM, Jesse Phillips wrote:
>> On Thu, Jan 19, 2012 at 6:27 AM, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>>> We tried a wiki. It didn't work.
>>> 
>>> Andrei
>> 
>> The only Phobos Dev I've seen edit the Wiki consistently has been Don.
> 
> Walter, Bartosz and I tried using the wiki in the past. It was a complete failure.
> 
>> In this group lots have signed up to trillo, you have even started doing some task lists. Create an organization and publicize your list. You've given up because Walter is on board yet, but if the community actually starts to use it and coordinate, with it, Walter would be in the wrong to ignore that.
> 
> I honestly am giving up on this. I won't even look at other suggested products. There seems to be no shared vision of what kind of organization we need and even no consensus that we need better organization. To summarize my understanding:
> 
> 1. Walter is (a) opposing trello, (b) not enthusiastic about changing much, (c) working kindly on particular examples discussed here (e.g. the oldest bugs).
> 
> 2. Don is already organized in his approach to fixing bugs and doesn't think adding some project planning software would help.
> 
> 3. Brad's opinion is that we're having a social issues that tools can't solve, and brings as evidence the fact that we don't use all features of our existing tools. Brad is not a strong participant in terms of code but is a key contributor of logistics and infrastructure.
> 
> 4. Kenji is too gentleman to participate. I personally think his work is so awesome, if anything I'd be afraid the introduction of whatever tools to disrupt it in any way.
> 
> 5. Leandro has the strong opinion that we don't need additional tools. He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.
> 
> 6. A few others thought they'd give it a whirl and joined trello. We have a project there with two items and a few tumbleweeds.
> 
> Given this state of affairs, it's very unlikely we're poised to operate a change of significant impact.


You seems to focus too much on the products. We first have to decide:

* What goal we want to achieve
* How we should a achieve that goal
* How we want to organize the community

Then we can get into more detail of what we want from a tool. Examples:

* Milestones
* Roadmaps
* Goals
* Tasks

Then we start by looking at the tools we have, bugzilla, wiki, github and so on. After that, if none of those tools fit for what we want to do, we can start to look for other tools. If we don't know how to organize the community and what we want from a tool we will never know if a tool fit your needs.

-- 
/Jacob Carlborg

On 19 jan 2012, at 18:09, Michel Fortin wrote:

> Le 2012-01-19 ? 11:02, Andrei Alexandrescu a ?crit :
> 
>> I honestly am giving up on this. I won't even look at other suggested products. There seems to be no shared vision of what kind of organization we need and even no consensus that we need better organization. To summarize my understanding:
>> 
>> 1. Walter is (a) opposing trello, (b) not enthusiastic about changing much, (c) working kindly on particular examples discussed here (e.g. the oldest bugs).
>> 
>> 2. Don is already organized in his approach to fixing bugs and doesn't think adding some project planning software would help.
>> 
>> 3. Brad's opinion is that we're having a social issues that tools can't solve, and brings as evidence the fact that we don't use all features of our existing tools. Brad is not a strong participant in terms of code but is a key contributor of logistics and infrastructure.
>> 
>> 4. Kenji is too gentleman to participate. I personally think his work is so awesome, if anything I'd be afraid the introduction of whatever tools to disrupt it in any way.
>> 
>> 5. Leandro has the strong opinion that we don't need additional tools. He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.
>> 
>> 6. A few others thought they'd give it a whirl and joined trello. We have a project there with two items and a few tumbleweeds.
>> 
>> Given this state of affairs, it's very unlikely we're poised to operate a change of significant impact.
> 
> 
> The problem with settings milestones is that everyone need to feel constrained by them, otherwise they are meaningless. More generally, what's needed is a way to take decisions and have everyone accept them. But before agreeing on a solution, the problem needs to be understood by everyone.
> 
> My understanding is that there is so many problems to fix everywhere that everyone is focussing on a small aspect and no one really get the whole. Like a giant castle that need to be repaired and extended, someone needs to draw a high-level map of it and then mark all the problematic areas and those that need to be built. Once you have that map you can plan a roadmap.
> 
> Is bugzilla providing a good enough overview? Would it work better with another tool? Maybe, maybe not. That's not important: pick the tool you want and try to draw an accurate overview of all aspects of the language, making everything that needing a fix or further development. Pick a drawing program if you need to. What's important to make the biggest flaws stand out. Once everyone can visualize the big picture, it'll be much easier to have everyone agree to a roadmap.
> 
> So adding a new tool is not the point of the exercise. The point is to have a better overview, a better understanding, so better decisions can be taken and agreed by everyone, and thus acted upon.
> 
> Sorry if I stated the obvious.


No you're not. I think you're spot on. Andrei is focusing too much on the tools.

-- 
/Jacob Carlborg

On Thu, 19 Jan 2012 20:18:33 +0100, David Simcha <dsimcha at gmail.com> wrote:

> I'd be interested in integrating Leandro's changes *but only if* the
> compiler is modified to generate pointer offset information in TypeInfo
> first.  I'm currently not a DMD developer and I don't have time to learn
> my
> way around that codebase so I won't be writing that patch.  Last time I
> tried to add precise heap scanning it went nowhere because I used
> templates
> and CTFE to generate this and it didn't play nicely with RTTI.
>
> Bottom line:  I'm willing to put in the effort but only if I can be reasonably confident that it won't be wasted.
>
Let's talk about this maybe in a month or two.

On 1/19/12 12:32 PM, Sean Kelly wrote:
> As an aside, I suppose it bears mentioning that one of our problems is simply that this is an open source project, so timelines and such can be difficult to project.  If I were working full-time on D I could make accurate statements about what I'd be working on, when it would be completed, etc.  As it is, when I have a spare moment for D I tend to jump on what seems to be the most important thing that specifically needs my input rather than working based on any sort of project plan.

That describes my situation, too. I still think I could be helped by a tool tracking my an others' progress instead of "now I have a couple of hours... what should I work on?"

Andrei

> You seems to focus too much on the products. We first have to decide:
>
> * What goal we want to achieve
> * How we should a achieve that goal
> * How we want to organize the community
>
> Then we can get into more detail of what we want from a tool. Examples:
>
> * Milestones
> * Roadmaps
> * Goals
> * Tasks
>
> Then we start by looking at the tools we have, bugzilla, wiki, github and so on. After that, if none of those tools fit for what we want to do, we can start to look for other tools. If we don't know how to organize the community and what we want from a tool we will never know if a tool fit your needs.
>

I wholeheartedly agree.

Let's take the current momentum to a fruitful effect.

2012/1/19 Jacob Carlborg <doob at me.com>

>
>
>
> You seems to focus too much on the products. We first have to decide:
>
> * What goal we want to achieve
> * How we should a achieve that goal
> * How we want to organize the community
>
> Then we can get into more detail of what we want from a tool. Examples:
>
> * Milestones
> * Roadmaps
> * Goals
> * Tasks
>

Please also think about new community members, they need:

* Rules
* Procedures

Thanks,
Oleg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20120120/37a4b223/attachment.html>

On 19 January 2012 21:22, Oleg Kuporosov <oleg.kuporosov at gmail.com> wrote:
>
>
> 2012/1/19 Jacob Carlborg <doob at me.com>
>>
>>
>>
>>
>> You seems to focus too much on the products. We first have to decide:
>>
>> * What goal we want to achieve
>> * How we should a achieve that goal
>> * How we want to organize the community
>>
>> Then we can get into more detail of what we want from a tool. Examples:
>>
>> * Milestones
>> * Roadmaps
>> * Goals
>> * Tasks
>
>
> Please also think about new community members, they need:
>
> * Rules
> * Procedures
>
> Thanks,
> Oleg.

Here's some concrete suggestions:
....
An obvious easy improvement would be to add more structure to the
release cycle. I think this is our biggest management problem.
I don't think we need tools so much as decisions. The change from a
one month release cycle to two months wasn't a decision, it just
happened somehow...

We always have three phases:
1. unrestricted activity
2. preparing for a release (dealing with regressions, etc)
3. beta testing period
Currently we move from stage 1 to 2 randomly, when somebody suggests
it's time for a release,
and achieves consensus. Normally it's proposed a few times before it
actually happens.
That's really crazy.
And stage 3 is a bit random. We apparently have a few projects which
must be tested (dsimcha's, for example)
but I think most things that are tested are open source, and could
therefore be automated.
The docs could also be tested for dead links (a common problem).

Proposal #1:

We move from phase 1 to phase 2 exactly n days after the previous release.
ALL pull requests originating prior to that date are either merged, or
given a comment as to why that cannot be merged.
Then, all regressions since the previous release are fixed. Issues
deemed crucial to the release may be merged even
if they originate after the n days, but we should try to minimize that.
When these are fixed, we enter stage 3. The 'Beta Test Program'
projects are tested for regressions.
A beta is released. We wait for m days for regression reports.
Any regressions result in another beta. After p days without further
reports, a release is made.
This final step may be done multiple times, with a beta release + p
days each time.

n >> m > p.
Probably something like n = 45 (?), m = 4 and p = 1 day to achieve a
60 day release cycle.
It'd actually be possible to look through the newsgroup and find what
these numbers have historically been...

Proposal #2:

During the stabilisation phase (phases 2 and 3), discuss goals for the
following release.
In the lull while waiting for beta reports to come it, it's a great
opportunity for strategy.
If major contributors have particular plans, they can say what they
plan to work on.
Quite good if there is a theme -- major features to be added in
Phobos, or particular
focus areas of the compiler, eg "attributes", "type inference",
"performance", "debugging",
"executable size", "concurrent gc", "SIMD", "inout", "64 bit", "shared
libraries".
Specific important bugs or pull requests.

Put the goals in the changelog under the "Under Construction" section, which
has just been "1. Shared libraries for Linux" for quite a long time.
It should change in every release.
Everybody reads that page -- it's a great place to put a quick
overview of the plans for the benefit of
the entire community. Add a link at the bottom, "to contribute to
future releases, click here".