Re: New idea for patch tracking - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: New idea for patch tracking
Date
Msg-id 463F1FD2.8060305@sun.com
Whole thread Raw
In response to Re: New idea for patch tracking  (Jim Nasby <decibel@decibel.org>)
Responses Re: New idea for patch tracking  (Jim Nasby <decibel@decibel.org>)
List 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 by date:

Previous
From: Koichi Suzuki
Date:
Subject: Re: [PATCHES] Full page writes improvement, code update
Next
From: Koichi Suzuki
Date:
Subject: Re: Patch queue triage