Re: No Issue Tracker - Say it Ain't So!
От | Josh Berkus |
---|---|
Тема | Re: No Issue Tracker - Say it Ain't So! |
Дата | |
Msg-id | 560C1F41.3040105@agliodbs.com обсуждение исходный текст |
Ответ на | No Issue Tracker - Say it Ain't So! (Kam Lasater <ckl@seekayel.com>) |
Ответы |
Re: No Issue Tracker - Say it Ain't So!
|
Список | pgsql-hackers |
On 09/30/2015 07:44 AM, Merlin Moncure wrote: > I'm not trolling in any way. I'm just challenging you to back up your > blanket assertions with evidence. For example, you're assertion that > mailing lists are insufficient is simply stated and expected to be > taken on faith: *How* is it insufficient and *what* do things like in > the new world? Be specific: glossing over these details doesn't > really accomplish anything and avoids the careful examination that may > suggest small tweaks to the current processes that could get similar > results with a lot less effort. In this entire massive thread, so far > only Josh has come up with what I'd consider to be actionable problem > cases. I don't see any way to make small tweaks to the existing process which would fix any of these problems. I think if that were possible, we'd already have done it. Suggestions welcome, of course. For example, "just use the wiki for this" has been mentioned as an alternative. But we've tried "just using the wiki" for a number of things, and it doesn't really work. For example, using the wiki as a way of breaking down the various multixact issues manifestly didn't work. A big part of the problem there is that there's no good way for the wiki to notify people when there's been an update; a smaller part is that the formatting gets messed up and impossible to follow. > Josh's point, "2. Not losing track of minor bugs." is an example of > what's bugging (pun intended) me. Do you think issues don't get lost > in issue trackers? More accurately: losing track of *fewer* minor bugs. > As I noted upthread google is incredibly efficient at tying up a > observed issue with the relevant fix and commentary, all based on > search engine integration with the mailing list that you've summarily > dismissed (without any evidence whatsoever) as ineffective. In my experience it has not been effective. Generally when a client asks me the question about which release a particular bug is fixed in, it takes me 15-30 minutes to determine the answer using google/list/commitlog. The client would not be able to determine it for themselves at all. While I appreciate the billable hours, it doesn't seem like a good use of the customer's money, you know? > You're > just assuming it's better without any examination of the costs > involved. For example, implementation and training aside, I expect > one of the immediate downsides of moving away from google + mailing > list is that you're going to be suffering from a deluge of duplicate > issues. As opposed to duplicate emails, which we already get? > Note, I'm not picking on Josh here. The points pertaining to > querying issues are certainly better than wading through the release > notes which I've always felt to be kind of a pain. What I'm driving > at is that you should identify actual pain points in the process and > explain clearly how things would improve. Also, consider low impact > solutions first (for example what low tech method makes bug > identification to release easier?) and move into a big tooling change > only after discarding them. Well, if you have suggestions that don't involve an email-driven bug tracker, please make them. I don't have any other ideas. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: