Re: Learning curves and such (was Re: pgFoundry) - Mailing list pgsql-hackers

Neil Conway wrote:
> Joshua D. Drake wrote:
> > You can even respond to specific messages within the thread instead of 
> > just a top down (one email after the other).
> 
> Well, that seems pretty fundamental...
> 
> >> But the point is that the current system works well;
> > 
> > Well does it though? I am not saying it is bad, well yes I am ;). There 
> > is no central place for me to point one of my developers and say -- Hey,
> > look at this patch... weren't we working on something like this? Let's 
> > help them out.
> 
> I'm not saying there is not room for improvement -- my point is that the 
> fundamental workflow (email submission of patches, discussion and 
> resolution via mailing list discussion) works well, and I don't see any 
> need to change it. If there are tools that help us improve this process 
> (e.g. archiving the resolution of old issues, as you suggest), they are 
> worth considering. In other words, I'd like a tool that fits the way we 
> work now, not one that forces us to change our processes to adapt to its 
> requirements.

Agreed.  Basically, there is the ideal world, where everything is
organized around bug numbers, and there is a tracking system of who has
reported the bugs and who fixed them, with a roadmap, and there is the
real world, where such organization takes time, and takes time away from
doing actual productive work.  Now, you can argue that the time to do
the maintenance of such a system will pay off, but it is far from clear
that is true.

No one has shown me a project that has such a system that works better
than what we have now, nor a roadmap that is better than ours.  If this
new setup is so great, please point me to a real project that uses it
effectively.  The only two projects I have worked with in this area are
Mozilla (bugzilla, terribly complex bug tracking and roadmap that drove
them off the road), and gaim, which seems to work (sourceforge,
everything gets put into a box of feature/bug, etc, and someone comes
along and manages that).  I don't think either are more effective than
what we have now.

What we have now is _bad_ for new people trying to jump in and figure
things out --- that is the real problem with our current setup.  You
can't just point someone at bug number XXX.  How much is that worth to
us in terms of time?  I am unsure.

I imagine the Mozilla guys spending all day closing bugs and putting
things in little boxes (oh, that bug is a duplicate), but the whole time
the project is not user-focused and they get superceeded by Firefox
because the new project actually gives users what they want.

Do we really want people to fill out a bug form, and have us get an
email and get an email and reply to the request and close the bug,
rather than just email the guy to give them the fix?  What does the big
bug database actually do for us except give us a big list of thousands
of items.  I just don't see the huge value in tracking stuff for little
payback.  Sure, it sounds great, but in practice it seems pretty
useless, and there is maintenance cost.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073