Re: New idea for patch tracking

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: New idea for patch tracking
Дата
Msg-id 5E1AE977-9978-458D-87AE-D24B03423501@decibel.org
обсуждение исходный текст
Ответ на Re: New idea for patch tracking  ("Dave Page" <dpage@postgresql.org>)
Ответы Re: New idea for patch tracking  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Список pgsql-hackers
On May 5, 2007, at 11:40 AM, Dave Page wrote:
>>> <snip tracker outline>
>>>
>>> Barring a few trivial details, that sounds almost identical to  
>>> what I
>>> proposed.
>>
>> Well, Andrew says everyone he talks to doesn't want it.  They want a
>> more comprehensive solution that goes from bug to patch.
>>
>
> I don't recall him saying that, though I do know  that's /his/  
> opinion. It's certainly *not* the opinion of most of the people  
> I've spoken with.
>
> I don't disagree with the idea in principle though, but I don't  
> believe it will work for us because it's so fundamentally different  
> from the way we currently work and still wouldn't solve the problem  
> of capturing all the relevant discussion regarding a given patch  
> (or bug) without a reasonable amount of manual work, or grafting a  
> large part of what I'm proposing on the side.

IIRC, every recent debate about going to a bug/issue (and now patch)  
tracker has ultimately boiled down to the impact it would have on our  
current work processes: it has to work 100% painlessly off of the  
mailing lists. It's got to do more than just pipe changes to the  
mailing list; it's got to be able to be driven by the list as well.  
That's the real challenging part.

People have suggested different trackers that have varying amounts of  
email capability, but I don't think any of them have had the full  
capability that we'd need. At best they might accept comments on a  
bug/issue via email, but to work for the community they'd need to go  
beyond that. You'd have to be able to resolve via email (preferably  
tied to -commiters). You'd need to be able to make a bug as invalid.  
You'd need to be able to open a new issue via email. And change  
status. And assign it to someone. And it would have to actually  
thread discussion to be useful. Probably some other things as well.

Since a system like that doesn't exist I think it's going to be up to  
us to create one. When it comes to the full set of features you'd  
expect out of an issue tracker, it would probably make sense to start  
with an existing project and try and add this functionality. But  
right now I don't think such an effort would work well, because we  
don't know well enough how all these new features should work.

But writing a patch tracker would be simpler than a full issue  
tracker. It's also something we could more easily do in a piece-meal  
fashion, since the only users will be developers. Building such a  
tool would provide a wealth of experience that could then be applied  
to tackling a full-blown issue tracking system.

The system Bruce and Dave have outlined shouldn't be terribly hard to  
implement. Let's start with that and see what we learn (as I've  
already told Dave, this is something I'll help with). Otherwise we'll  
once again have spent another chunk of community effort on a tracker  
discussion that results in nothing being done (I guess it has been 6  
months since it was last brought up, so we were due again anyway...)
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: Managing the community information stream
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first