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

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

From
DBDipl. Ing. Sergey Brester <serg.brester@sebres.de>
Date
Oct 15, 2020, 19:17 UTC
Message-ID
<65f46be7283239e86bb345e94bc5dbda@sebres.de>
In-Reply-To
<xmqqo8l3fibz.fsf@gitster.c.googlers.com>
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.

I could continue yet, but unsure the arguments will be heard or welcome (I know it is your work, and everyone organizes his/her workplace how one need or want). I was just wondering how it could work, even for years. In my opinion all pros of a bug-tracker are obvious for everyone once using them.

And an automatic export/import from/to tracker into mailing lists (to retain it for conservative part of old school participants) is mostly trivial.

Thanks, Serg.

15.10.2020 20:35, Junio C Hamano wrote:
Show 9 quoted lines
> "Dipl. Ing. Sergey Brester" <serg.brester@sebres.de> writes:
> 
>> May be this is a sign to introduce real issue tracker finally? :) No 
>> offence, but I was always wondering how a team is able to hold all the 
>> issue related stuff in form of a mailing list, without to experience 
>> such an "embarrassments". Especially on such large projects and 
>> communities.
> 
> I do not know if an issue-tracker would have helped, though.
Previous: Jeff KingNext: Junio C Hamano
Message 16 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.