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

On Wed, Sep 23, 2015 at 5:10 PM, Szymon Lipiński <mabewlun(at)gmail(dot)com> wrote:

>
>
> On 23 September 2015 at 22:07, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
>> * Josh Berkus (josh(at)agliodbs(dot)com) wrote:
>> > On 09/23/2015 11:18 AM, Kam Lasater wrote:
>> > > At this point not having one is borderline negligent. I'd suggest:
>> > > Github Issues, Pivotal Tracker or Redmine (probably in that order).
>> > > There are tens to hundreds of other great ones out there, I'm sure one
>> > > of them would also work.
>> >
>> > First, understand that the Postgres project was created before bug
>> > trackers existed. And people are very slow to change their habits,
>> > especially since not having a bug tracker was actually a benefit up
>> > until around 2005. It's not anymore, but I'm sure people will argue
>> > with my statement on that.
>> >
>> > We have to use something OSS; open source projects depending on
>> > closed-source infra is bad news. Out of what's available, I'd actually
>> > choose Bugzilla; as much as BZ frustrates the heck out of me at times,
>> > it's the only OSS tracker that's at all sophisticated.
>> >
>> > The alternative would be someone building a sophisticated system on top
>> > of RequestTracker, which would also let us have tight mailing list
>> > integration given RT's email-driven model. However, that would require
>> > someone with the time to build a custom workflow system and web UI on
>> > top of RT. It's quite possible that Best Practical would be willing to
>> > help here.
>>
>> Yeah, even if we got past the "do we want a bug tracker?" question, any
>> project would probably end up stalling indefinitely on "well then, which
>> one?"
>>
>> In the end, we should probably just throw something up based on whatever
>> the folks who are going to be actually maintaining it want and call it a
>> 'beta' and see what happens with it. The above-referenced individuals
>> would be the bug tracking system curators, of course. Unless it's got
>> serious technical issues, the infrastructure team will do our best to
>> support the choice. On the other hand, some of us would likely be
>> involved in bug curation also.
>>
>> Thanks!
>>
>> Stephen
>>
>
>
> Hi,
> a couple of days ago I was reading through the tickets in the Django bug
> tracker. It was much easier to find any information about the things to
> work on than currently for Postgres.
>

​TBH, if you want to work on PostgreSQL and are not sure where to best
contribute you should actually two-way communicate​ with the people
actively involved. If you know what you want to work on you likewise
should propose something reasonably concrete for discussion. The other
resources are solid and do reflect past ideas and desires and while they do
make a good starting point unless you have a personal interest in the topic
putting the question out to the lists will gauge how necessary the
community deems the feature at this moment in time.

From my point of view, for Postgres, there is just a not updated too often
> list of things to implement on the wiki. If I need to find some additional
> information, then I can find there just some links to mails from the mail
> groups.
>
> Then I need to read through the emails. This is not user friendly too, as
> I need to click through the email tree, and if an email has multiple
> replies, it is usually hard not to omit some of them, as after going into a
> reply, I need to click to get to the parent mail again.
>
>
​Yes, people are not particularly inclined to put a lot of effort into
organizing pure ideas. The emails that are out there are probably of more
use to the people that wrote and read them originally than to someone
coming in fresh. In many cases they were never written to be primary
sources.​

> What's more, there are some things on the wiki, and when I asked about
> that, it turned out that "oh, there was some discussion long time ago, that
> it is not doable".
>
>
​So we should constantly manage the entire Todo list because occasionally
someone shows interest in a couple of items that appear on it that were
already declared "not doable" some time in the past? This doesn't seem
efficient or likely. The Todo list is an idea generator, not project
management.
​

> It would be also worth storing the information that someone is working on
> something, so the work won't be doubled.
>
>
The ​Commitfest interface, basically.​

​David J.​