On Tue, Oct 06, 2015 at 01:17:48PM -0400, Bruce Momjian wrote: > I do think we rushed to choose a tracker a little too quickly.
Have we chosen one? > Let me explain, from a high level, what a new tracker will change in > our workflow. [snip] I won't quote your whole message, which I essentially agree with. Let me say that the questions I have brought up have several purposes. One, I think it's important to identify what exactly we're after. I hope my questions have help put some light on that. Two, I think any attempt to tell the developers and committers that they need to change their workflow to adapt to some system is bound to fail, so, I have asked, just what changed would you all be willing to actually *do*? Tom Lane is pretty good at noting a bug number in his commit messages, for example. Would he be willing to modify that slightly to make it easier to machine parse? Would you be willing to add a bug number to your commit messages? I'm not asking for guarantees. Actually I'm not really asking for anything, I'm just trying to figure out what the parameters of a solution might be. If the answer to that is "no, I'm not willing to change anything at all", that's fine, it just colors what might be done and how much automation I or someone else might be able to write. I think even with a bug tracker the default "ignore" behavior can still be done. In principle, we could even mark bugs as "unconfirmed" or "logged" or something right away and only mark them as new or open or something if they actually draw a reply. We could even require a reply from a committer if that was wanted. If I haven't made it clear by now, I am trying to write a system that requires the absolute minimal amount of change to the existing way of doing things. As I noted in my original email, I've put together a bug tracker, not a ticket system. If people would like to make some small adjustments to make it easier to automate a bug tracker, that would be great, but if not, that's fine too, it's no *worse* than what we already have. And if people really wanted a ticket system, it wouldn't be hard to enhance a tracker. > My point is that we have our current workflow not because we are > idiots, but because it fit our workflow and resources best. I am not > sure if we have succeeded because of our current non-retain mode, or > in spite of it. It might be time to switch to a default-retain mode, > especially since most other projects have that mode, but we should be > clear what we are getting into. I thinking having a bug tracker and retention vs non-retention are orthogonal questions. But I agree that knowing what might be involved is a good idea. I think perhaps one of the problems is that different people want different things, so it's probably going to be hard to make everyone happy. -- nw -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
