Re: New idea for patch tracking

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: New idea for patch tracking
Дата
Msg-id 463F1FD2.8060305@sun.com
обсуждение исходный текст
Ответ на Re: New idea for patch tracking  (Jim Nasby <decibel@decibel.org>)
Ответы Re: New idea for patch tracking  (Jim Nasby <decibel@decibel.org>)
Список pgsql-hackers
Jim Nasby wrote:


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

As I wrote few days ago. You can see how and what use e.g. Apache Derby 
community. I guess more of mentioned issues they have solved and we can 
take some of their ideas. However I still  miss list of tracker 
requirements - what tracker MUST have and what is nice to have.

And you describe current processes based on email communication. But if 
we setup some tracker some process will be changed. I think first step 
is determine what we really want and after we can discuss how to reach it.


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

Create own tracker is reinvent a wheel and waste a time. There are a lot 
of trackers and I believe that one of them fit postgres requirements. I 
agree with your idea to try one and if it will be necessary we can add 
some functionality. But I think that there are not clear requirements 
and I also afraid that there is not unified view of core team on this.


I suggest following process:

1) create list of requirements - MUST HAVE/NICE TO HAVE
2) create list of tracker
3) reject trackers which does not fit "MUST HAVE"
4) each member of core team create own order
5) results will be put together and one tracker will be select for testing.
    Zdenek





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

Предыдущее
От: Koichi Suzuki
Дата:
Сообщение: Re: [PATCHES] Full page writes improvement, code update
Следующее
От: Koichi Suzuki
Дата:
Сообщение: Re: Patch queue triage