Re: [HACKERS] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
On May 7, 2007, at 7:47 AM, Zdenek Kotala wrote: Jim Nasby wrote: 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. If we lived in an ideal world I'd agree with you 100%. But we live in PostgreSQL-community-world. :) There is a *lot* of resistance in the development community to going to any kind of a tracker, even if it would mean essentially zero change to how the development has to work. If you don't believe me go look in the archives; I believe this debate happens about twice a year, and every time the result is the same: lots of emails, zero change. 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. Yes, when it comes to doing a full-blown tracker it would be a huge amount of wheel reinvention. But that's not the case with a simple patch tracker. Let's take the baby step of a patch tracker first and see what we learn from it. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New idea for patch tracking
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[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
--- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. What I think we can do simply is to have our email software automatically number emails submitted to the patches list that already don't have a number. This way, all followups, even if moved to the hackers list, would maintain that patch number, and if an updated version is posted, the user would keep the same number in the email subject. snip tracker outline Barring a few trivial details, that sounds almost identical to what I proposed. Regards, Dave ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] New idea for patch tracking
Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. What I think we can do simply is to have our email software automatically number emails submitted to the patches list that already don't have a number. This way, all followups, even if moved to the hackers list, would maintain that patch number, and if an updated version is posted, the user would keep the same number in the email subject. 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. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. that would be easy to do on either the wishlist or a seperate wiki page and I would volunteer to do that if you think it is useful. Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New idea for patch tracking
Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. that would be easy to do on either the wishlist or a seperate wiki page and I would volunteer to do that if you think it is useful. OK, you have to go back to Tom's email stating where we are on each patch, then look over the patch application and find out which ones have been applied. Also you have to read the replies to find out who has taken ownership of patches. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Dave Page wrote: 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. Dave can speak for his own views, but I think you're misquoting me somewhat. I said that a majority of developers wanted to move to use of a tracking system, not everyone. I did say that this patch tracker would be at best a half measure in almost everyone's eyes. Note the almost. That doesn't mean nobody wants it. Possibly some see significant benefit where I see little or none. Clearly Dave does. But it does mean that it's not what most people really want. I would be prepared to put considerable effort (say, comparable to what I have put into the buildfarm) into establishing and maintaining a feature/bug tracker system, if I thought there was enough buyin. I have not done so in the past because others (principally you) have been against it, and so it seemed doomed to failure. Unlike the buildfarm, which can stand on its own, a tracker requires cooperation from the developers in order to be effective. Our present change management methods strike me as being analogous to keeping track of a banking system in a spreadsheet (don't get me started). It's quite ironic (not to mention sad) given that we are producing a sophisticated database ... cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. that would be easy to do on either the wishlist or a seperate wiki page and I would volunteer to do that if you think it is useful. OK, you have to go back to Tom's email stating where we are on each patch, then look over the patch application and find out which ones have been applied. Also you have to read the replies to find out who has taken ownership of patches. ok I did a rough sketch of how I interpreted your proposal on http://developer.postgresql.org/index.php/Todo:PatchStatus. This table is by far not complete yet(more of a PoC) but I wanted to get some feedback if I'm on the right track before I put more time into this. Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
I would like to add one point: Bruce Momjian wrote: Patch committers check several things before applying a patch: 1) Follows the SQL standard or community agreed-upon behavior 2) Style merges seamlessly into the surrounding code 3) Written as simply and efficiently as possible 4) Uses the available PostgreSQL subsystems properly 5) Contains sufficient comments 6) Contains code that works on all supported operating systems 7) Has proper documentation 8) Passes all regression tests 8.5) Contains regression test(s) which covered performed changes 9) Behaves as expected, even under unusual cirumstances 10) Contains no reliability risks 11) Does not overly complicate the source code 12) If performance-related, it should have a measureable performance benefit 13) Is of sufficient usefulness to the average PostgreSQL user 14) Follows existing PostgreSQL coding standards Zdenek ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
OK, item modified to: liPasses all regression tests, and if needed, adds new ones/li --- Zdenek Kotala wrote: I would like to add one point: Bruce Momjian wrote: Patch committers check several things before applying a patch: 1) Follows the SQL standard or community agreed-upon behavior 2) Style merges seamlessly into the surrounding code 3) Written as simply and efficiently as possible 4) Uses the available PostgreSQL subsystems properly 5) Contains sufficient comments 6) Contains code that works on all supported operating systems 7) Has proper documentation 8) Passes all regression tests 8.5) Contains regression test(s) which covered performed changes 9) Behaves as expected, even under unusual cirumstances 10) Contains no reliability risks 11) Does not overly complicate the source code 12) If performance-related, it should have a measureable performance benefit 13) Is of sufficient usefulness to the average PostgreSQL user 14) Follows existing PostgreSQL coding standards Zdenek -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
--- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 05/05/07, 11:06:37 Subject: Re: [HACKERS] New idea for patch tracking 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. Regards, Dave ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: I have already responded to all the email comments. Here is my idea of moving forward. There are basically three interrelated issues: 1) bug tracking 2) getting more people to review complex patches 3) patch tracking I am not going to go into #1, except to say that the problem has always been the effort needed to track the bugs vs. the value. I am not going to go into #2, except to say that this is going to require a personal approach to assisting developers. One thing I am going to do is to add an item to the developer's FAQ outlining how patches are analyzed for application, which should help both patch submitters and committers (sample attached). As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. What I think we can do simply is to have our email software automatically number emails submitted to the patches list that already don't have a number. This way, all followups, even if moved to the hackers list, would maintain that patch number, and if an updated version is posted, the user would keep the same number in the email subject. Once that is done, it should be trivial to write a web application that will track the patches based on the subject line, something like PATCH#555. Committers can include that patch string in the commit message, so committed patches can be automatically removed from the open patch queue. The only tricky part is to handle patches that are rejected or kept for a later release. That would probably require web access to adjust. One thing that has always bothered me about tracking patches is that when an email to the patches list is bounced for discussion to the hackers list, there isn't any good way for outside people to track the full patch discussion because we don't track threads that move to different mailing lists. The special patch number would make such tracking easier. The good thing about such a simple system is that it has a very light burden on patch submitters and committers. The major work is done by the web application, but that can all be programmed. Bruce, I will say publicly what I have said to others privately. Forgive me if I'm a bit blunter than usual. I do not see any value in this at all. What we need to track are problems to be solved, be they bugs or features, not particular patches. Tracking patches simply comes too late in the process. I think that your attitude to the use of bug/feature trackers is quite unreasonable, and certainly in opposition to what seems to be the majority opinion among developers. It's a great pity that you are so utterly resistant to use of tracking software. The only reason that this system, at best a half measure in almost everyone's eyes, is being proposed, as far as I can see, is that you will not agree to use anything else. So if this goes ahead and proves to be of little value, I hope that you will relent and agree the use of proper tracking software like almost every other open source project uses. It really is time that PostgreSQL managed to advance beyond thinking that email lists are the greatest management tool since sliced bread. It's just indefensible in 2007. cheers a disappointed andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] New idea for patch tracking
Andrew Dunstan wrote: I will say publicly what I have said to others privately. Forgive me if I'm a bit blunter than usual. I do not see any value in this at all. What we need to track are problems to be solved, be they bugs or features, not particular patches. Tracking patches simply comes too late in the process. I think that your attitude to the use of bug/feature trackers is quite unreasonable, and certainly in opposition to what seems to be the majority opinion among developers. It's a great pity that you are so utterly resistant to use of tracking software. The only reason that this system, at best a half measure in almost everyone's eyes, is being proposed, as far as I can see, is that you will not agree to use anything else. So if this goes ahead and proves to be of little value, I hope that you will relent and agree the use of proper tracking software like almost every other open source project uses. It really is time that PostgreSQL managed to advance beyond thinking that email lists are the greatest management tool since sliced bread. It's just indefensible in 2007. As I said before, I am involved in patches only when a patch isn't addressed. If a new system works, I will have nothing to do, which is good. If you want me to believe it will work better than what we do now, I can't. Prove me wrong. Forget about what I think. Do something and stop talking about it. What I am not going to do is to do 2x more work and get 2% more help, which is what I fear. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
