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

  I have set up a JIRA instance using Atlassian's OnDemand service,
  available at https://git-scm.atlassian.net/

Do people really think it's reasonable to use non-Free tools to develop
git?  That seems surprising to me.

On 1 March 2012 11:37, Greg Troxel [off-list ref] wrote:

 I have set up a JIRA instance using Atlassian's OnDemand service,
 available at https://git-scm.atlassian.net/

Do people really think it's reasonable to use non-Free tools to develop
git?  That seems surprising to me.

Maybe not, and if that is the case I am more than happy to let this die.

That said, this is the tool I know how to use best, and is in my
opinion the most flexible, reliable and supported. The source code is
available on request to customers to extend or modify (or at least it
used to be) and the company is very supportive of open source projects
in general.

Additionally, if we are not prepared to use non-Free tools, we should
probably stop using github. (This example is a little trite, seeing as
there are non-github alternatives available for grabbing the source
code. Then again, the mailing list is not disappearing any time soon,
so there is a free alternative to _any_ bug tracker that is used)

Regards,

Andrew Ardill

Andrew Ardill [off-list ref] writes:

Additionally, if we are not prepared to use non-Free tools, we should
probably stop using github.

I think the issue isn't "using" non-free tools so much as it's getting
_locked into_ non-free tools.

So if JIRA makes all its data trivially exportable in a format which
is easy to use, and there's some way of isolating references to it so
that it's possible to switch to something else without undue hardship,
maybe it's not such a big deal.

[Github is a prime example of a non-free tool which is largely avoids
the lockin issue, and I imagine that's why so many free projects
happily use it.  That's generally true of any git repo site, given the
super-easy cloneability of git repos, but Github also provides good
export of the meta-data it keeps (issues, etc).]

-Miles

-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

On 1 March 2012 16:16, Miles Bader [off-list ref] wrote:

Andrew Ardill [off-list ref] writes:

quoted

Additionally, if we are not prepared to use non-Free tools, we should
probably stop using github.

I think the issue isn't "using" non-free tools so much as it's getting
_locked into_ non-free tools.

So if JIRA makes all its data trivially exportable in a format which
is easy to use,

JIRA provides the ability to trivially export any 'filter' as XML or
CSV data files. A filter is simply a search, and can contain every
single issue in the database. Some pieces of information are slightly
more difficult to migrate.
- Issue attachments such as screenshots are not stored in the
database, and we would have to request them in order to retrieve them.
- User information and configuration data is only available in a full
site backup (which is available on request).
- CSV export option does not include comments. (XML, and Word formats do)

Additionally, there are quite a number of tools to allow migration
between JIRA and other tools, and in my experience Atlassian are quite
helpful when you try and move off their products.

and there's some way of isolating references to it so
that it's possible to switch to something else without undue hardship

JIRA has the capacity to automatically link issues to commits which
mention issue numbers, however this is by no means essential or
necessary functionality. JIRA will be happy completely detached from
the rest of the world, and will provide additional functionality
gradually as it becomes more integrated. Some functionality it can
provide without forming hard links with the outside world (like
polling the repository and providing continuous builds)

The primary thing to look out for would be other sites linking to the
issue tracker. Unfortunately, there is no way at the moment to provide
an alternate URI for the tracker, so it is hard to avoid this from
happening.

Regards,

Andrew Ardill

On Wed, Feb 29, 2012 at 4:37 PM, Greg Troxel [off-list ref] wrote:

 I have set up a JIRA instance using Atlassian's OnDemand service,
 available at https://git-scm.atlassian.net/

Honestly I would argue against this, just because unless you want to
spend a lot of time on it, I don't think it's going to get used much.
Issue trackers in general tend not to get traction unless the
maintainer uses it and asks people to use it or it's included in the
workflow somehow.  I use issue trackers in most of my projects, but I
also don't use mailing lists - a lot of the things that work for my
workflows are not the way that the Git project does it and I think
you'll find that it's a bit of a waste of time to try to shoehorn them
in.

Besides, most of the things you are looking to get out of this are
generally pretty easily obtained from the ML.  If you're bored and
want a project to work on, ask the ML.  If you want to know the status
on something, search or ask the ML.  It's not quite as self-service as
a issue tracker, but it gets you into the community more, which I
think is also important.

Do people really think it's reasonable to use non-Free tools to develop
git?  That seems surprising to me.

This is particularly interesting to me.  Disclaimer: I work at GitHub
and have for most of the life of GitHub.  That said, it's interesting
to think about this.  What does the freedom of the tooling provide
you?  Data portability is one thing, but both JIRA and GitHub have
APIs to obtain basically any data in them (I think - I never use JIRA,
but I've worked on the GH APIs).

I do think that an interesting data point here is the cast of
kernel.org, though.  So that's all free, but also hugely and totally
failed everyone here.  It wasted hours of my time trying to clean up
all the broken links from git-scm.com over a month, which is after a
month of thinking that they couldn't possibly be down another day.
The wiki is still busted.  The docs are still gone.  GitHub has
contracted a designer and has started spending developer hours working
on a better git-scm.com to take over those functions so it won't
happen again.  More importantly, that will never happen to GitHub or
JIRA - there is no conceivable way that either of these relatively
large corporations would tolerate even a full day of downtime or data
loss.

So free is great, but what is more important in the tooling and
services that help you develop?  Is it freedom to some arbitrary
level, or is it simplicity and availability? I value my time a lot
more than if I can get the source code to the issue tracker that my
open source project uses.  If we're going to use an issue tracker, or
any other tool, I would really rather prefer we use one backed by a
company that takes downtime seriously as opposed to using something
that doesn't have the resources to fix things in any timeframe.
Having someone saying "it's going to keep working because if it
doesn't we all lose our jobs" is more freedom to me than having people
say "if it doesn't work at some point you have the freedom to spend
days of your time reimplementing it on your own hardware with maybe
some of our backed up data and our open source code".  Which is
literally what I'm doing today for the hosted man page documentation.

Just some thoughts.

Scott