Re: New idea for patch tracking

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