Hi guys,

sorry for the long delay, it was not the best week for me to restart
all of this discussion, but now it's OK, I'm catching up!

On Sun, Jan 06, 2019 at 05:29:43PM +0100, Lukas Tribus wrote:
> Hello everyone,
> as per Tim's suggestion I'm restarting the discussion about the issue
> tracker, started in "haproxy 1.9 status update" (2018-05-25),
> Message-ID 20180525161044.ga6...@1wt.eu:
> https://www.mail-archive.com/haproxy@formilux.org/msg30139.html
> > It would be nice to show what's pending or being worked on, and
> > to sometimes add extra info regarding a given task.
> Yes, we are in need of an issue tracker, not only to handle open bugs,
> but even more so to handle feature/change requests that often need
> more time. Those do get lost on the mailing list, even when everyone
> already agreed it's needed.

I totally agree. This is the tool I'm missing the most currently. I'm
not aware of a *good* and manageable issue tracker. Having a status for
a bug per branch most likely eliminates most of them...

> > The problem we've faced in the past with GitHub's issue tracker
> > is that it's impossible to restrict the creation of new issues to
> > participants. Given that haproxy is a complex component, the boundary
> > between human error, misunderstanding and bug is extremely thin.
> It is, but I don't like restricting the creation of new issues to 
> participants.
> Issue templates need to be clear that the issue tracker is not a
> support forum.

I'm really not convinced it would change anything. We've put prominently
on the previous repo an indication that it was not the official project
and that issues / PRs were not accepted, despite this your automatic bot
was needed to close them. My goal is contributors efficiency. Several of
us are on the critical path and every minute they waste slows someone
else down. So if it becomes more annoying for everyone to create a new
issue just for the purpose of discouraging wanderers from trying to
create them, it will only have a globally negative effect.

Based on your experience dealing with all these reports on discourse,
what is the approximate ratio between valid and invalid reports ?

> Triaging new issues will be needed anyway, and that
> also includes closing misdirected support request.

Sure, and any support / issue reporting chain requires this since you
only know what it was once the issue is fixed (and sometimes even after
it's fixed you discover new impacts).

> To be clear: I think developers should not receive an email
> notifications for new or untriaged issues - only when specifically
> assigned to the issue or if they commented previously on it. Instead,
> maybe an automated weekly report or something like that (similar to
> what we have now for the stable-queue) could go out to the mailing
> list with a summary of the open issues, grouped by it's labels.

Maybe. But right now issues reported here are dealt with because all
of us presume that "someone will surely look at this one", and if we
see a long unresponded e-mail, we try to assign more time to it (and
sometimes we miss it, of course). And what is nice is that actually a
large number of people respond, some with links to a similar previous
report, others suggesting to adapt the config to narrow the issue down,
etc. So there is a huge value in having the community participate to
issue resolution and not just some developers. The problem with batches
is that when you get 20 new bugs at once that you hadn't had the time
to look at previously, well, you don't know where to start and you
simply prefer to pretend you didn't see them. So possibly that having
the triaged issues being forwarded here in real time with a visible tag
would maintain the same level of participation with a higher accuracy
and less losses.

> > It resulted in the issue tracker being filled with wrong bugs, 100% of
> > which were in fact requests for help. It makes the utility totally
> > useless for development and bug fixing as it requires more time to
> > maintain in a clean state than it takes to put issues in a mailbox.
> What you are describing basically is a unmaintained issue tracker,
> which is of course useless.
> But keeping people from filing new issues is the wrong approach to
> this, imho. Proper templating, triaging and correct labeling of the
> issues is the difference between a useless and a useful issue tracker
> from my point of view.

I do have strong doubts but I'm open to trying :-)

> So I guess we ultimately have to decide between:
>   - an issue tracker open to everyone, however requiring some
> volunteers to triage incoming bugs (and close invalid ones)
>   - an issue tracker that is open to "previous participants", with the
> expectation to require less manpower for triage
> I'm in favor of the former, because I believe triage will be required
> for both and I don't think the amount of bogus issues will be
> unmanageable. I'd also volunteer to triage incoming issues - not that
> it's much different from what's currently done discourse anyway - as
> Tim already said.

Oh yes! I just want to be sure we don't burn you out! This is also why
I'm open to trying what those doing the work propose. If I'm imposing
a painful or inefficient process for those doing the work, it will not
work either.

> Regarding what tool to use, in the "open to everyone" case I'd opt for
> github simply because it has the lowest barrier of entry for everyone,
> as well as me being mildly familiar with it personally. Pre-existing
> github labels would have to be replaced by useful ones and a issue
> template would have to be created.

I'd say that we managed to close the issues there when we discovered
them. It took a huge amount of efforts, sure, but eventually it was
done. So if we figure later that it was a wrong choice, we know it can
be done again. In this regard I think it's the lowest cost to *try*.

However I'd like that we spend some time thinking about what can be
done to properly route the bugs to the various branches. Bugs in dev
are useless, we want them to be fixed in stable branches. So we have
to be sure that the way bugs are tagged/labelled etc makes it very
clear that they're still pending for this or that branch. Maybe we
could have a series of labels for each branch indicating the status
for each of them, and never use the issue's status at all ? E.g.
something like "dev-security", "1.9-security", "1.8-major",
"1.7-unaffected", "1.6-unaffected", "1.5-unaffected". This would require
to manually update these labels when the fixes are backported. I don't
know, this still sounds extremely hackish to me.

> > A limitation that isn't addressed by any of them is that an issue has
> > a single status and not one per maintenance branch. Some will say that
> > labels replace this but I'd say that this isn't true, it just vaguely
> > emulates this. Anyway if we don't have better we can go with this. I
> > often dream of the day someone pissed of by using prehistoric issue
> > trackers writes a modern one, just like when Linus created Git...
> There are some niche tools allowing a "distributed issue tracking
> system" within git, but they seem very fragmented, none of it gets a
> lot of traction and it would certainly over complicate things for a
> lot of people, including myself. See git-bug [1] and it's HN
> discussion [2],

Thanks a lot for these links, they are very informative. This utility
doesn't "yet" support cross-branches, but it's said that bugseverywhere
does. But bugseverywhere claims that its value is in keeping a hard
relation between bug's state and the fix in the tree, which precisely
is the wrong way to do it for me : I strongly prefer that the bug tracker
is never fully up to date regarding the resolved status for a branch than
having it believe the branch is fixed because it doesn't know that this
branch requires an extra patch. An apparently unresolved bug will be
noticed by the next person trying to resolve it. It's how it really
works with most developers and bug trackers in real life. I had too
quick a look at the other ones for now.

> containing a log of other references [3-7].
> Well I guess we would certainly not have many bogus issues reported on
> those systems ;)

That's my concern as well, which is why I want a hosted solution, and one
that can reuse various identity management sources to result in the least
possible friction.

Now to be clear on one point, I've been discussing with people about joining
our community to give some help with tooling, processes, documentation, issue
triaging, so I'm not even opposed to starting to think "big" if needed. I
mean, if we're inflicting ourselves a lot of pain because we don't have as
many arms/eyes/brains as required to deal with everything, this is something
that can be addressed. And this is true as well with the selection of
software. I will probably not shock anyone here disclosing my strong
preference for opensource, but in practice if we found the perfect tool
which matches all our expectations and it was not opensource and came at
a fairly reasonable price, I'm not worried about finding some funding for
it. So I prefer to be clear about the fact that I'm not implicitly ruling
out such options.

The limits I'm fixing to myself to be able to use such tools are simple :
if using the tool results in more time spent keeping it in good shape than
the time it saves us looking for e-mail read/unread status or our own post-it
notes that we have, I'm pretty sure I'll give up using it in the end.

And I don't want that people doing all the maintenance job feel like they're
constantly cleaning toilets that nobody respects either and that each day
looks exactly like the previous day. While I don't imagine that maintaining
a bug tracker in good shape is not the most gratifying activity, I certainly
imagine that feeling like you're a significant enabler in the project, by
improving overall quality, release pacing and developers' efficiency is so.
This is why the solution must be well balanced so that everyone finds his/her
role and place in the system according to taste, availability and skills.

With that said at the moment we don't have anything and the situation is
not better than having a suboptimal tool.


Reply via email to