Vote on Jira as bugtracker

[Victor Sosa]

HI,

I felt like lost using trac; it is kind of messy. I just don't feel comfortable with it.
I see so many open source project using Jira that is just natural. Search is easy, categorize is easy, look through the all issues and task is quick.

I would like to propose a vote on Jira as the bugtracker for this project. Just vote + or - to see how many people agree on this.

[Daniele Procida]

Hi Victor. It's a reasonable proposition, but it's not simply a case of choosing what would be nicer: we also have to make it work in our infrastructure - and that's a huge effort.

How, for example, would we migrate the many thousands of tickets from Trac to JIRA?

How would JIRA be integrated into our current deployment infrastructure?

By all means it's useful to get votes on something like this, even before we consider those questions, because if enough people want something it's always possible - but be aware that simply getting lots of votes for it would only ever be the first and easiest step.

Having said that: I prefer Trac to JIRA. It's simpler, and faster.

Daniele

[James Bennett]

I'd be against such a change. I've used a lot of bug trackers, and the only thing I've learned is there is no good one; replacing one with another just swaps one set of annoying limitations/frustrations for another. And since there's a lot of inertia in whatever's currently being used, and it would require a lot of work and effort to switch to something else, I don't see enough gain from doing so to support a switch, especially since we at least have a ton of experience working around Trac's limitations now, and would have to re-learn all of that to switch to something else.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b80ec53d-ec62-4b77-a8cf-72ca1e852c78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Victor Sosa]

To answer you question:
There is a plug-in to migrate all the data to Jira and similar to integrate with any it with any in you infrastructure. (I just don't know it all you infrastructure)

https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html

[Marc Tamlyn]

Yeah, this is a non-starter for me. All bug trackers are bad, we should stick with the bad one we are used to.

Marc

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%40googlegroups.com.

[Florian Apolloner]

Ditto.

[Shai Berger]

What Marc and James said, and in particular what Daniele said : I get to use Jira on a daily basis and find it cumbersome and confusing.

Shai see

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Michael Manfre]

Agreed with the above for the same reasons.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CDE1F163-5500-446F-B8A4-FE512F944C57%40platonix.com.

For more options, visit https://groups.google.com/d/optout.

--

GPG Fingerprint: 74DE D158 BAD0 EDF8

keybase.io/manfre

[Aymeric Augustin]

FWIW Jira seems to be an exception among bug trackers: some people really love it, others really hate it. It depends on who set it up and maintained it in the company where they used it.

Since we don’t have a resident Jira expert, we run the risk that most of the Django community will fall into the “hate it” bucket. To me this is one of the riskier choices we could make.

Anyway it’s unclear to me that the potential benefits of switching to any bug tracker could offset the transition costs, as long as Trac is serviceable.

We’ll see what happens in 2020 if it doesn’t support Python 3 by then (http://trac.edgewall.org/ticket/10083, http://trac.edgewall.org/ticket/12130).

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBtQmB45ogstE2PFE%3DDxw9EVgdjaOyw5UeXKHgLD74dQHw%40mail.gmail.com.

[Nick Sarbicki]

FWIW Jira seems to be an exception among bug trackers: some people really love it, others really hate it. It depends on who set it up and maintained it in the company where they used it.

Since we don’t have a resident Jira expert, we run the risk that most of the Django community will fall into the “hate it” bucket. To me this is one of the riskier choices we could make.

Anyway it’s unclear to me that the potential benefits of switching to any bug tracker could offset the transition costs, as long as Trac is serviceable.

We’ll see what happens in 2020 if it doesn’t support Python 3 by then (http://trac.edgewall.org/ticket/10083, http://trac.edgewall.org/ticket/12130).

Could always look at Bloodhound (http://bloodhound.apache.org/) if after something similar. Not that it supports Py3 yet.

But I'm with everyone else. It's not worth it.

[Chris Foresman]

For whatever it's worth, our company switched from Pivotal Tracker to JIRA because we added a QA team and they wanted all this flexibility in devising bug ticket "workflows." All it did from my perspective is add 47 layers of complexity on top of a massively confusing UI and insists on NOT supporting markdown while using its own sorta-similar-but-different-enough-to-be-constantly-annoying "wiki markup", but it can only be supported in certain fields, only I forget which ones it works in and which ones it doesn't until I've carefully entered all these useful code snippets and links and screenshots and save the ticket and see it's just full of gobbledygook.

TL;DR: HATE IT

[Daniele Procida]

On Wed, Jan 6, 2016, Daniele Procida <dan...@vurt.org> wrote:

>By all means it's useful to get votes on something like this, even
>before we consider those questions, because if enough people want
>something it's always possible - but be aware that simply getting lots
>of votes for it would only ever be the first and easiest step.

While we're in the realm of the completely hypothetical, if I were going to find myself enthusiastic about moving to a new development tracking platform, it would be Taiga. <https://taiga.io>

It's written in Django, by a company that actively supports the Django community. It's open-source. The people who develop it are approachable and friendly. It has a nice name.

Daniele

[Victor Sosa]

Looks like it is a NO to the proposition.

Daniele

I like what I saw in taiga, that's a way better bug tracking UI; you can check here:

https://tree.taiga.io/project/taiga/issues?page=1

[Josh Smeaton]

FWIW I actually like Jira (much more than Trac) and find it a lot easier to use. I think the trick is configuring very basic workflows so users don't have to fight through transitions. Open, Closed, Assigned/In Progress and transitions to and from each state would get us really close to the current Trac workflow. My number 1 gripe with Trac is that search SUCKS, so I'd actually be in favour of a migration *if someone else were to do all the work* :D. But that's the rub isn't it, nothing comes for free. We'd also lose login with Github (I think) and psuedo-anonymous triage because Jira requires an email account, so there's no way it could be a full parity transition.

Taiga looks very nice, but arguments made above also apply. There's a cost in setup + migration, overhead of learning a new system, and a lack of knowledge about the problems that will evidently exist.

I really do think Trac is awful though, just wanted to be clear about that.

[Tim Graham]

To search Trac, use "site:code.djangoproject.com your query" in a Google search box. Works great in my experience.

[Yamila Moreno]

Hi there,

I'm Yamila, part of Taiga Team and Kaleidos (the company that develops Taiga.io). We're very happy to be as a "completely hypothetical" candidate for a new bugtracker. Taiga (a Django and open source project) being used by django-dev would be huge :)

I just wanted to let you know that me or anyone in our team would be glad to answer any question about the product, saas or installation, migrating issues or anything related. No strings attached, of course!!!

Best,
Yamila

[Daniele Procida]

On Thu, Jan 7, 2016, Yamila Moreno <yami...@gmail.com> wrote:

>I'm Yamila, part of Taiga Team and Kaleidos (the company that develops
>Taiga.io). We're very happy to be as a "completely hypothetical" candidate
>for a new bugtracker. Taiga (a Django and open source project) being used
>by django-dev would be huge :)
>
>I just wanted to let you know that me or anyone in our team would be glad
>to answer any question about the product, saas or installation, migrating
>issues or anything related. No strings attached, of course!!!

Thanks Yamila.

Are you already familiar with Trac and the way we use it?

Key things are:

* integration with GitHub (tickets, login)
* integration with Django Project login
* integration with site styling
* workflow

(I expect I've missed something.)

What scope is there for automated migration?

And perhaps users familiar both with Taiga and our Trac might be able to comment too?

Daniele

[Yamila Moreno]

Hi, 

Are you already familiar with Trac and the way we use it?

I'm familiar with trac (we were using it some year ago), and I'm a bit familiar with django workflow because I attended a couple of sprints. Anyway, I'm not an expert in trac.
 

Key things are:

* integration with GitHub (tickets, login)

Yes, we have.
- Everything is based in a documented API, so with webhooks you can get new issues in github automatically created in your instance of taiga.io, as well as comments
- Login with github is a contrib plugin, check it here: https://github.com/taigaio/taiga-contrib-github-auth ; there are also other contrib plugins to login with other platforms:

https://github.com/agolden/taiga-contrib-google-auth

https://github.com/fedora-infra/taiga-contrib-fas-openid-auth

 

* integration with Django Project login

It's not developed, but it should be easy to create a new contrib plugin for your instance
 

* integration with site styling

Yes!

https://taigaio.github.io/taiga-doc/dist/#themes

 

* workflow

The filosophy behind Taiga is the agile frame (Individuals and interactions over processes). Thus, workflow is completely free to set; in a fresh project, administrators can configure the workflow, statuses, name and colours; which of them are "open statuses" and which one are "closed statuses".
 

(I expect I've missed something.)

What scope is there for automated migration?

Right now there isn't an automated migration from trac, it's in the backlog (https://tree.taiga.io/project/taiga/us/108) but it's not planned in the short term. Nevertheless, it could be done with the Taiga API (http://taigaio.github.io/taiga-doc/dist/api.html) or with the import export feature.
 

And perhaps users familiar both with Taiga and our Trac might be able to comment too?

It would be very interesting to read these comments.

Best,
Yamila

[Florian Apolloner]

Hi Yamila,

On Thursday, January 7, 2016 at 2:22:21 PM UTC+1, Yamila Moreno wrote:

I just wanted to let you know that me or anyone in our team would be glad to answer any question about the product, saas or installation, migrating issues or anything related. No strings attached, of course!!!

I personally do actually have one question. I was looking through your source code and realized that you are apparently importing DRF and changing a few parts and relicensing it as AGPL. I am not a lawyer and you might actually be allowed to do that, but what about contributing to DRF back instead? Your AGPL code (again I am not a lawyer and might be wrong), actually forbids Tom to take your changes back into DRF… That said, the DRF license requires you to retain the copyright information, either I missed it or you did not retain it.

Do not get me wrong, but if half what I wrote is true; I'd personally be very worried if Django switched to Taiga, given the signal that this would send to our userbase (might be just me though).

Cheers,
Florian

[Chris Cogdon]

I used Jira at my previous company. It is a great tool, but it is _extremely_ heavyweight. Unless you need to high level of customisation of workflows and integrations it can provide, and have someone intimately familiar with it and/or have the nearly-full-time job of learning and fiddling with it [1], it will be an alienating, frustrating experience for all involved.

[1] Just like about every Java-based tool out there. ;)

[Russell Keith-Magee]

Weighing in on Jira specifically - I’ve had to use it on a number of projects, and I’ve never had a good experience with it. That might be because the Jira instances were badly configured - bit if that’s the case, it suggests to me that there’s a deeper problem with Jira being too complex for it’s own good. 

On the more broad topic of adopting a new ticket system - historically, I’ve been very much of the same opinion as James. All ticket trackers suck. Trac sucks in ways we understand.

However, I think the integration between Trac and Github is sufficiently kludgey that it’s at least worth looking at options. If we’re going to switch (and it’s a *BIG* if), 

* Open source, and written in Django. 

* Able to support our workflow, and customisable to adapt to other workflows if we need to

* Able to integrate with our authentication mechanisms

* Able to deal with our “everyone can contribute” permissions structure (more on this below)

* *Completely* seamless integration with the Github PR workflow.

On Thu, Jan 7, 2016 at 10:18 PM, Yamila Moreno <yami...@gmail.com> wrote:

Hi, 

Are you already familiar with Trac and the way we use it?

I'm familiar with trac (we were using it some year ago), and I'm a bit familiar with django workflow because I attended a couple of sprints. Anyway, I'm not an expert in trac.
 

Key things are:

* integration with GitHub (tickets, login)

Yes, we have.
- Everything is based in a documented API, so with webhooks you can get new issues in github automatically created in your instance of taiga.io, as well as comments
- Login with github is a contrib plugin, check it here: https://github.com/taigaio/taiga-contrib-github-auth ; there are also other contrib plugins to login with other platforms:

https://github.com/agolden/taiga-contrib-google-auth

https://github.com/fedora-infra/taiga-contrib-fas-openid-auth

 

* integration with Django Project login

It's not developed, but it should be easy to create a new contrib plugin for your instance
 

* integration with site styling

Yes!

https://taigaio.github.io/taiga-doc/dist/#themes

 

* workflow

The filosophy behind Taiga is the agile frame (Individuals and interactions over processes). Thus, workflow is completely free to set; in a fresh project, administrators can configure the workflow, statuses, name and colours; which of them are "open statuses" and which one are "closed statuses". 

Related to out workflow is permissions. This is one of the biggest reasons why Github Issues doesn’t work for us. We need to be able to give access to *anyone* to update issues. This doesn’t just mean adding comments - it means progressing a ticket along the workflow, adding flags (or whatever categorisation mechanism exists), even closing issues. 

Being able to identify members of the core team when they participate in conversations is highly desirable, but not absolutely essential. This is a feature that we’ve added to Trac.

Providing the ability for core team members to “lock” certain issues would be a nice-to-have that we don’t currently have.

Yours,

Russ Magee %-)

[Andrey Antukh]

HI Florian

On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner <f.apo...@gmail.com> wrote:

Hi Yamila,

On Thursday, January 7, 2016 at 2:22:21 PM UTC+1, Yamila Moreno wrote:

I just wanted to let you know that me or anyone in our team would be glad to answer any question about the product, saas or installation, migrating issues or anything related. No strings attached, of course!!!

I personally do actually have one question. I was looking through your source code and realized that you are apparently importing DRF and changing a few parts and relicensing it as AGPL. I am not a lawyer and you might actually be allowed to do that, but what about contributing to DRF back instead? Your AGPL code (again I am not a lawyer and might be wrong), actually forbids Tom to take your changes back into DRF… That said, the DRF license requires you to retain the copyright information, either I missed it or you did not retain it.

The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive license that does not impide take the source and re-license it under other license. 

taiga.io initially have started using the DRF just like a dependency but over time the dev-team found the needs monky-patch many and many parts of it... Later, the dev-team have decided just include it in the code base and remove useless (for taiga) code and add additional features. 

Much of code/improvements is contributed back to the DRF (v2), other as third party packages and some other is no, because the approaches are diverged and the changes are just to much opinionated/coupled to the taiga usage.

I hope I have solved your question.

Regards.

Andrey

Do not get me wrong, but if half what I wrote is true; I'd personally be very worried if Django switched to Taiga, given the signal that this would send to our userbase (might be just me though).

Cheers,
Florian

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4f189a3c-9011-4b06-994f-ec4b1a346c9c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrey Antukh - Андрей Антух - <ni...@niwi.nz>

http://www.niwi.nz

https://github.com/niwinz

[Carl Meyer]

Hi Andrey,

On 01/07/2016 04:23 PM, Andrey Antukh wrote:
> On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner

> The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive
> license that does not impide take the source and re-license it under
> other license.
>

> taiga.io <http://taiga.io> initially have started using the DRF just

> like a dependency but over time the dev-team found the needs monky-patch
> many and many parts of it... Later, the dev-team have decided just
> include it in the code base and remove useless (for taiga) code and add
> additional features.
>
> Much of code/improvements is contributed back to the DRF (v2), other as
> third party packages and some other is no, because the approaches are
> diverged and the changes are just to much opinionated/coupled to the
> taiga usage.
>
> I hope I have solved your question.

I am not a lawyer, but it seems to me the problem is not the use of the
code (which the license does allow), but the re-licensing and the lack
of the original DRF license in your codebase.

You are allowed to use the code and re-distribute it, but AFAIK you are
not allowed to re-license it unless you are the copyright owner. And the
terms of the DRF license do require that the DRF license text be
preserved along with any redistribution of the DRF code, which (as far
as I can see) Taiga currently doesn't do.

So if I'm right (which I may well not be), I think the issue is easily
resolved by including the original DRF license text in your base/api/
directory, and clarifying that that license (not the AGPL) is the
license that applies to all code taken from DRF.

Carl

[Joe Tennies]

I'm not a lawyer, but I care about licensing.

The MIT License would allow you to relicense it, but you must keep the original copyrights in tact. (From license: Redistribution and use in source and binary forms, with or without modification, are permitted...)

It does have a list of "buts" too.

You must keep the copyright and disclaimer in the source files you used, and your documentation must also do that.

Typical answer is to add a header above it in the source and then state that all modifications from the original are AGPL... Original code is: leave theirs alone.

You typically add "Portions of the code are based on Django Rest Framework which is *paste copyright and lack of warranty etc disclaimer*"

 to your documentation.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/568F0D05.3050901%40meyerloewen.net.

For more options, visit https://groups.google.com/d/optout.

--

Joe Tennies
ten...@gmail.com

[Andrey Antukh]

Hi Joe

On Fri, Jan 8, 2016 at 7:16 AM, Joe Tennies <ten...@gmail.com> wrote:

I'm not a lawyer, but I care about licensing.

The MIT License would allow you to relicense it, but you must keep the original copyrights in tact. (From license: Redistribution and use in source and binary forms, with or without modification, are permitted...)

It does have a list of "buts" too.

You must keep the copyright and disclaimer in the source files you used, and your documentation must also do that.

Typical answer is to add a header above it in the source and then state that all modifications from the original are AGPL... Original code is: leave theirs alone.

You typically add "Portions of the code are based on Django Rest Framework which is *paste copyright and lack of warranty etc disclaimer*"

 to your documentation.

On each file imported from DRF we have a notice about the original copyright: 

# This code is partially taken from django-rest-framework:

# Copyright (c) 2011-2014, Tom Christie

But as you are suggesting, the best approach would be paste the entire original license preamble. We will do it ASAP.

Thank you very much.

Regards.

Andrey

 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACiOJ6sFEP%3D-i3z8ge3JDXm7%3Dn0xDgg3bOE%2BjHJDJruuvz8ONw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Joe Tennies]

No problem. Don't forget the documentation too. That was called out in the original license. For instance, I'd put it right on the README.md on the correct project(s) on GitHub under the license section.

OTOH, I'm now interested in checking it out, so thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOQnsAABqVZdvHfzAbmPCp6S4EoAH0o0eRtVG4FW%3D7K9n0f7mQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Joe Tennies
ten...@gmail.com

[Hugo Osvaldo Barrera]

On Wednesday, January 6, 2016 at 10:09:08 AM UTC-3, Victor Sosa wrote:

HI,

I felt like lost using trac; it is kind of messy. I just don't feel comfortable with it.
I see so many open source project using Jira that is just natural. Search is easy, categorize is easy, look through the all issues and task is quick.

I would like to propose a vote on Jira as the bugtracker for this project. Just vote + or - to see how many people agree on this.

Not an actual django developer (I'm a user lurking here really), but I'd still like to chime in:

 * Jira is too complex. Devs may end up understanding it, but users will have a harder time, especially since they won't be using it as much.
 * Moving from a FLOSS tool to a proprietary solution really gives mixed signals. It'd confuse me why a team who clearly appreciates open-sourceness would make such a move with so many great alternatives out there.
 * Can you actually apply django's theme to Jira? What about the project login?

[Curtis Maloney]

On 09/01/16 13:08, Hugo Osvaldo Barrera wrote:
> Not an actual django developer (I'm a user lurking here really), but I'd
> still like to chime in:

Doesn't make your input any less valid... in fact, perhaps makes it more
valuable :)

> * Jira is too complex. Devs may end up understanding it, but users
> will have a harder time, especially since they won't be using it as much.

I agree here... having used it in projects in the past, I've found is
bizarrely slow, and tedious.

> * Moving from a FLOSS tool to a proprietary solution really gives
> mixed signals. It'd confuse me why a team who clearly appreciates
> open-sourceness would make such a move with so many great alternatives
> out there.

Absolutely agree here... but, could you mention some of these "great
alternatives"? Several others have espoused their position that "they
all suck" [and I don't believe they're limiting that to just OSS ones :)]

I certainly believe it would be a coup if we could wind up with a Django
based one... for obvious reasons.

--
Curtis