[darcs-devel] darcs patch: Remove GUI code and stuff to build it.

[Jason Dagit]

On 7/15/07, Eric Y. Kow <eric.kow at gmail.com> wrote:

> And finally a silly opionated rant

I overlooked your rant until this morning.  It's a good rant though.

> ----------------------------------
> Also, maybe those of us on the fringe (who are not busy drawing crazy
> commutation diagrams) should invert our priorties.  Our efforts should
> be spent bashing away at the bug tracker, finding *easy* things to fix
> and getting rid of that stuff first.

I think you're right.  Whatever we're doing now, isn't working so
well.  It seems that everyone that is a contributor at the moment is
something else first and second and a darcs contributor third (or
worse?).  This probably has an impact on the amount of contributions.

> It's an issue of bang for buck, similar to the idea that anything which
> takes < 2 min should be done immediately because the time it takes to
> put it on your todo list, or to keep recyling 'crap, I have to get
> around to that' in your head is colossal with the two minutes it would
> have taken to get it over with in the first place.  Having things rot in
> our bug tracker is like a perpetual 'crap, I have to get around to
> that'.  It also obscures away the true issues, drowning away the really
> worrying stuff in a sort of noise.

Yes, increasing through put is probably a good thing at this point.
Regardless of how deep or tricky the problem really is.

> Perhaps fixing the easy stuff will be better for darcs's popularity,
> which will in turn inspire more people to become developers.  And
> besides, new easy stuff to fix (and to train developers with) is a
> highly renewable resource.  Just ask Zooko.

I keep hoping people from #haskell will take more interest and help
out.  Stefan the other day commented on the source and theory being
impenetrable to him in it's current state.  Making things more
accessible to new developers should probably be a meta goal for anyone
contributing to darcs at the moment.  And if you're thinking of
contributing, ignore conflictors and mergers.  They are going away and
they're not worth learning about (unless you find it interesting to
learn why they don't solve the problem).

> (*) although as one redditor has already complained, we don't have
>     a notion of priorities.

Perhaps we could use a "roadmap" and a big picture
guidance/documentation.  I don't see how it could hurt.

Jason