[dmd-internals] Planning software?

Brad Roberts braddr at puremagic.com
Thu Jan 19 10:42:53 PST 2012


On 1/19/2012 8:02 AM, 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.

It hasn't worked since it's largely been a one man mission (go go Don!).   That's significantly different than "didn't"
which implies that it also won't ever.  The wiki itself is essentially entirely a separate world from the D development
world.  It contains (or did last time I explored it), a whole lot of interesting bits that really belong in bugzilla
(and ultimately in the dlang website).  But that's a whole separate discussion so let's not get derailed by it right now.

> Walter, Bartosz and I tried using the wiki in the past. It was a complete failure.

Are you talking about the one I setup to record our notes back during the early days of the D2 dev cycle?  Yeah, it was
much more of a note tracker than an effective design medium.  Face to face discussions were much more effective.

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

I don't reach the same conclusion as you do.  I see definite consensus that we can and should do better, just not how to
achieve it.  I really don't want to give up on getting more structure in the process.

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

That's a mis-framing of my opinion.  I think our issues are mostly social, which doesn't mean that they can't be
changed, just that we need to realize that the changes are in behavior.  I also think that adding new tools should be
secondary to taking advantage of the tooling we have.  However, if there's a tool that's perfect for our needs, we
should certainly explore it.  I do suggest prioritize more use of our current tools over exploring others since we can
do that RIGHT NOW with nearly zero effort.

> Given this state of affairs, it's very unlikely we're poised to operate a change of significant impact.

I think the best way to change is to just be bull-headed about it and change.  It's how bugzilla was started in the
first place.  Walter used to 'track' bugs through posts in the digitalmars.d.bugs newsgroup.  I shuddered at how
ineffective that was and set up bugzilla and pointed people at it.  It's now been about 6 years and we've had over 7300
bugs filed and issues aren't lost (other than in the noise of so many open bugs).

To that end, let's start planning the next release (not the upcoming one, that one's fairly close to ready to release, I
think) with the tools available right now, specifically bugzilla.  I just deleted the 2.058 milestone and created 2.059.

I suggest that we create a roadmap.dd page (linked from relevant parts of the website, like the left-nav, probably the
changelog and download pages as well) that starts to build a real roadmap and links to bugzilla search results.  File
issues and sub-tasks for higher level todos.

Is it as good as it could possibly be, no.  Is it a lot better than we've had, yup.

As to Michel's comment that not everyone will follow it.  That's not super important (we shouldn't reject a fix that's
in hand, that discourages participation).  Some people crave a bit of structure and will follow it without having to be
asked, it just needs to be there.  A large portion of our potential user base definitely craves seeing that there's
structure and stays away from the chaotic nature.  I can't blame them, and in-fact sympathize quite a bit.

What's important is that we have guidelines and policies for development and in particular gate releases based on those
policies.

For example, the gcc team has a policy akin to:

    When the number of P1 bugs for a given release reaches 0 and
    P2 bugs reaches 100, the release branch is created.  At some
    point after that the release is cut (it's not when P2 bugs
    hits 0 since that's rarely achieved).

I'm not advocating that for DMD since our release cycles are about 5x more frequent than theirs and we don't, yet,
really use branches much.  Baby steps.

Anyway, this email is long enough so I'll quit talking for the moment.

Later,
Brad


More information about the dmd-internals mailing list