git maintenance bug tracker sooner better than later

I predict that git maintenance will have to adopt a bug tracker.

Just like many other packages that relied on just sending bugs and patches to a mailing list, in the end ended up adding a bug tracker.

On Mon, Feb 2, 2009 at 8:07 PM,  <jidanni@jidanni.org> wrote:

will it snow tomorrow ? ;-)

Quoting jidanni@jidanni.org:

Thanks for sharing your insight.

A more important thing is what you are going to do about it.

There are people in the project who track bugs and patches and they are doing an excellent job, but it's inevitable that the larger the project grows, the more bugs and patches sent to the mailing list. There is a real risk that some of them may get lost in the noise.

The project can use capable project secretaries, and these people may choose to use an issue tracking system to ease their job of keeping track of bugs and patches. "A bug tracker" is just a tool and you need to have real people behind it who are actively taking care of the system and looking at the issues. Are you volunteering to make a difference by becoming one of them, or are you merely adding useless noise to the list traffic to make it more likely for bugs and patches to be lost?

On 2009-02-03 19:05 (+0900), Nanako Shiraishi wrote:

Maybe he would file a lot of bug reports. At least in Debian there are about 1800 reports from jidanni@jidanni.org:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=jidanni@jidanni.org

Hi,

On Tue, 3 Feb 2009, Teemu Likonen wrote:

Definitely too much time on his hands.

If I had that much time, I know exactly what projects I would tackle: there are good ideas on the GSoC page, and it is highly unlikely all of them will be taken/sponsored by GSoC.

Ciao, Dscho

Anyway, I have this file
  -rw-r--r--  1   19561 2009-01-13 03:26 DietCherries17
where I have 17 tiny documentation patches that sent to
git@vger.kernel.org but nothing happened.
Perhaps I could send them to a volunteer who could see if any of them
are useful and then do something with them. Thanks.

On 2009-02-04, jidanni@jidanni.org <jidanni@jidanni.org> wrote:

As I recall a lot of those things were replied to (at least for the first few patches) as being not quite right (or plain wrong). Once you even said "oh, if you could fix this for me before applying it". At some point the time it takes to review patches and to write a quick fix for the bugs/typos yourself stands in no relation whatsoever.

Or you could make one big "typo-fix"-patch out of them and one "i-didnt-understand-the-manpage-there"-patch. Then these patches could be reviewed and you could revise them.

A second solution would be to tackle real problems, earn the respect of the maintainer and those close to him, have your patches merged and _then_ when you come up with nitpicks about documentation, those people would be sure of your abilities and would put more trust in you to not mess up when writing documentation.

About the bug-tracker-thing: I am quite happy that git is one of those projects where everything happens in one spot: Development, bug-reporting and general discussion. It makes it a lot easier than disconnected systems where information is easily duplicated and becomes stale at other ends.

But that's just my oppinion, Greetings, Jojo

jidanni@jidanni.org wrote:

That's really not how things work around here, or on any OSS project I've ever been engaged in. It's your itch to scratch, so before you have a chance of getting anyone else to scratch it for you, you have to either make those others interested enough to volunteer to do it for you, or you get to scratch away as much as you like yourself.

The longer and more difficult way is to scratch the itches of so many others that people want to help you out because the chance you'll do something else which is *also* productive is high enough to warrant it. So far, you seem more interested in shooting from the hip, sending patches at random that have little or no impact on anything and that nobody else is genuinely interested in. That's fine if you also pick up the pieces of your poor aim and actually follow through but when it really just causes more work for others than the end-result would have been worth to start with, the net result is counter-productive and you have to work harder when you have ideas/patches that are actually good than you would have been forced to with a better overall signal-to-noise ratio.

Thank you for your response.

http://jidanni.org/test/DietCherries17 are some things that I previously posted to git@vger.kernel.org, but did not get explicitly accepted or rejected.

You see I feel I am about to enter a month where even simple subtraction and division seems a challenge (mental health not the best.)

With a bug tracker, at least one knows somebody saw something for sure, and it didn't just float by. That way one could register items into it on one's good days, and then take a break, which I am going to do now. Thanks.

On 2009-02-06, jidanni@jidanni.org <jidanni@jidanni.org> wrote:

And what "bugs" would you file? If I look at your patch-series which consists of oneliner documentation nitpicking, I don't even want to imagine how much these would get blown up by a web-based bug-tracker.

The web-based is the second part: When working on/with *git*, a command-line tool, I naturally work in a terminal, and I *don't* want to fire up a webbrowser to communicate something as simple as a bug. Also bug-trackers tend to attract all sorts of people who don't really think or try to find bugs before submitting them. Those sorts of people probably already file bugs for git and the distribution-maintainers then tell them to report the problem upstream (i.e.: here) or do it themselves.