Re: No Issue Tracker - Say it Ain't So!

On Tue, Sep 29, 2015 at 12:42 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> On 09/29/2015 07:25 AM, Merlin Moncure wrote:
>>
>> On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater <ckl(at)seekayel(dot)com> wrote:
>>>
>>> Hello,
>>>
>>> Last night I heard that Postgres had no issue/bug tracker. At first I
>>> thought the guy was trolling me. Seriously, how could this be. Certainly
>>> a
>>> mature open source project that is the database for a measurable
>>> percentage
>>> of the internet would have an issue tracker.
>>>
>>> Sadly, I was not being trolled. I'm new around here so I will keep the
>>> preaching to a minimum and cut right to the chase...
>>>
>>> ___It is time for an issue tracker___
>>
>>
>> This thread is depressing me. We use all these fancy tools at $work
>> and I'm not sure they are much of an improvement over informal
>> processes run by capable people. I regularly advocate, pretty much
>> to the wind, to use JIRA less and email *more*. The main benefit of
>> the system, various reports to corporate taskmasters, seems pretty
>> much irrelevant here. If you're advocating introduction of new
>> tooling with all the associated processes and complexities, can you
>> point to specific breakdowns in the project and exactly how said
>> tooling would have helped the situation?
>
>
> From my perspective this is about more than bugs it is about development as
> a whole. Here is a very simple problem we have:
>
> I come to hackers to discuss an idea
> idea gets sign off
> I submit a patch
> *I am told to go over to this commitfest app thing and upload it there*
>
> Why? That's stupid. I should have submitted the patch to hackers and it
> should have been automatically part of my existing thread.
>
> Someone reviews the patch, decides it needs to be pushed to the next
> commitfest
>
> In theory, at some point I will be informed of that or I will see that it
> was pushed to the next commitfest.
>
> If we were running a properly integrated tracker, I would know that
> instantly because the issue would have been updated to the affect and marked
> for the next commitfest.
>
> The next commitfest comes around, and I can't get to the patch changes in
> time so it gets pushed to the next release. With a properly integrated issue
> tracker, I would immediately see that, be able to comment on it and be able
> to see the entire history of the patch.
>
> Oh... and this can be done all from email as long as the tracker is properly
> integrated.
>
> Bugs can certainly be handled the same way and in some ways better.

I've read this email about three times now and it's not clear at all
to me what a issue/bug tracker brings to the table. First, I find it
pretty hard to believe that a hypothetical patch author would not know
that a patch was or was not submitted in the current framework.
Putting that aside, if you insisted an automatic status change
notifications, that could be worked into the current commit fest
application, right? Note, once done, you'd get that notification with
zero extra process effort beyond what we currently do.

I also openly wonder how big this problem really is. I haven't
submitted all that many patches, but for those I have it's never
really been in doubt as to what status they've were in at the time.
So, I'll repeat the question: if you want to accomplish with this
thread, let's give *specific examples* of project breakdowns we're
trying to solve with this tooling. Did a user lose status of a patch?
If so, which user?...what patch?

merlin