Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1 March 2012 22:29, Thomas Rast <trast@xxxxxxxxxxx> wrote:
> Andrew Ardill <andrew.ardill@xxxxxxxxx> writes:
>
>> I have set up a JIRA instance using Atlassian's OnDemand service,
>> available at https://git-scm.atlassian.net/
> [...]
>> As I see it (and Junio has mentioned before) we are going to need
>> people who are able to manage the issues in this system
>
> Note that you are not the first one to try.  The most elaborate plan and
> writeup that I know of sits at
>
>  http://article.gmane.org/gmane.comp.version-control.git/136500  [1]
>
> Jan "jast" Krüger also mentioned server issues today, so *.jk.gs is
> presumably down because of that, not because gitbugs.jk.gs is no longer
> valid.
>
> Nevertheless, AFAIK it has never been used for "real work", so you may
> want to look into why that happened, and do something different.
>

Thanks for the links Thomas, I think the general sentiments summarised
there are echoed every time someone mentions an issue tracker on the
list. It is good to have the summary though!

I think that, to some degree, the model that most quickly arises from
the ideals of that list is inherently flawed. The git list is, almost
by definition, a fairly chaotic place. Issues get looked into because
either someone makes a loud enough noise, or someone is interested
enough in the problem. An issue tracker is a much more structured
beast, and trying to tether the two is obviously going to be
difficult.
One of the benefits of an issue tracker is that it keeps all
discussion around an issue in the one place. The driving wedge here is
that we *already* have somewhere that issues are tracked, albeit in a
less structured sense. Anything that reduces the duplication efforts
needed is a desirable thing, but more on that later.

The one thing we need to avoid is single points of failure. In my
experience, this is achieved by ensuring that people contributing
issues are able to do as much of the leg work as possible. Typically
they want to help, and are limited most by unnecessary restrictions
and lack of understanding. If the process is simple enough it becomes
much easier for new people to step in and make valuable contributions
(the mailing list is in some ways the embodiment of this). We also
need to encourage those who are willing and empower each other to be
time-effective.

I feel that is enough pontificating from me, and I am really enjoying
the discussion. Please, if you think it will work or not, visit the
site [1] - sign up if you want to - and provide feedback. I am going
to open a project to capture feedback, and anything else related that
is not directly relevant to the list, and that will probably be a good
place to test the ropes if you want to get your hands dirty. In
general, it is very hard to break things so if you would like to have
a play around with the system please let me know and get involved!

Regards,

Andrew Ardill

[1] git-scm.atlassian.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]