git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] fast-import: fix over-allocation of marks storage

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 15, 2020, 20:15 UTC
Message-ID
<xmqq362ffdom.fsf@gitster.c.googlers.com>
In-Reply-To
<65f46be7283239e86bb345e94bc5dbda@sebres.de>
"Dipl. Ing. Sergey Brester" <serg.brester@sebres.de> writes:
Show 19 quoted lines
> Well, a bug-tracker had some clear benefits:
>
> 1. it has controlling and statistic mechanisms like a road-map,
> milestones etc;
>
> 2. the issues get a priority (so one is able to select bugs with high
> precedence);
>
> 3. they can be labeled or even characterized with other metrics to
> signal seriousness of the issue or
> to emphasize them in order to be flashy in the road-map.
>
> 4. the issues are bound to the participating contributors (reporter,
> devs, tester, etc), so for example there are reports like "open issues
> belonging to me", which could also help to organize work a bit
> ("remember" them).
>
> 5. Transparency of the representation of issue or some lists is not to
> compare with a thread in a mailing list at all.

What is curious in the above list is that their benefits are heavily dependent on people actually curating them. No issue tracker automatically makes random issues "prioritized", no issue tracker automatically closes a stale and/or irrelevant issue. And without curation, it tends to become pile of useless reports.

> I could continue yet, but unsure the arguments will be heard or
> welcome ...

I actually think people already _know_ the benefit of having well curated tracker, and suspect that what needs to be stressed is *not* the "arguments" for having one. It just is that those who bring it up on this list never seem to be interested in maintaining the tracker in useful state, and assumes that issue curation magically happens for free, and that is probably it never materializes.

It would be great if you are volunteering to be one of the issue managers, of course. FWIW, I think somebody (jrnieder?) already runs a tracker for us. I do not know how much community participation the instance gets to to keep it relevant.

Previous: Dipl. Ing. Sergey BresterNext: René Scharfe
Message 17 of 20 in “git fast-import leaks memory drastically, so crashes with out of memory by attempt to import 22MB export dump”
  1. Dipl. Ing. Sergey BresterOct 14, 2020
  2. Jeff KingOct 15, 2020
  3. Dipl. Ing. Sergey BresterOct 15, 2020
  4. fast-import: fix over-allocation of marks storageJeff King, Oct 15, 2020
  5. Junio C HamanoOct 15, 2020
  6. Junio C HamanoOct 15, 2020
  7. Dipl. Ing. Sergey BresterOct 15, 2020
  8. Junio C HamanoOct 15, 2020
  9. Jeff KingOct 15, 2020
  10. Junio C HamanoOct 15, 2020
  11. brian m. carlsonOct 16, 2020
  12. Jeff KingOct 15, 2020
  13. Jeff KingOct 15, 2020
  14. brian m. carlsonOct 16, 2020
  15. Jeff KingOct 16, 2020
  16. Dipl. Ing. Sergey BresterOct 15, 2020
  17. Junio C HamanoOct 15, 2020
  18. René ScharfeOct 15, 2020
  19. René ScharfeOct 15, 2020
  20. Dipl. Ing. Sergey BresterOct 15, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.