Was BitBucket (mercurial system which is python based) not considered? And 
could someone point me to a url where I can read the discussion on this 
migration; I am rather curious why it’s happening – the current system works so 
I see no reason to fix it.
From: Max Thayer 
Sent: Friday, April 20, 2012 1:26 PM
To: [email protected] 
Subject: Re: GitHub migration planning

Luke, maybe I don't understand something about Trac, but some of the issues 
raised by you or those you quoted seem easily fixed. Consider: 

  "- there isn't a notion of "component", so there's no way to ask "give me
  the list of all contrib.auth tickets, so I can find the duplicate quickly";"

Why not tag all relevant issues "contrib.auth"?

  "- it's hard to navigate when there are more than 200 open tickets on a
  project."

There are easily that many open tickets on Trac (a quick look seems to indicate 
there are about 2k open tickets). What about Trac makes the number of open 
tickets a non-issue?

  "- we can't put customized flags on tickets (easy, ui/ux) -- there are
  tags, but the result of the "Keywords" field in Trac shows the limits of
  unstructured tags;"

Could you explain this more? "customized flag" sounds exactly like a tag.

Best regards,
Max

On Fri, Apr 20, 2012 at 3:21 AM, Luke Plant <[email protected]> wrote:

  On 18/04/12 22:44, philipn wrote:
  > Hey folks!
  >
  > I started a wiki page to help plan a migration to GitHub:
  >
  > https://code.djangoproject.com/wiki/GitHub%20Migration
  >
  > I don't know what I'm doing, but I do know that the current Trac setup
  > (attaching patches, etc) is less accessible to non-core contributors
  > than GitHub and I'd love to do anything I can to help make this better.


  In discussing the move to GitHub on django-core, we fairly quickly came
  to the conclusion that we wouldn't be using GitHub issues.

  One of my major points in this discussion was the need to be able to
  import our current Trac database, because otherwise we are throwing away
  a huge amount of important history. As a core committer I regularly
  trace history to work out why a certain change was made, and often find
  myself looking at bugs on Trac and reading the discussion there.

  But importing our Trac database to GitHub issues would be basically
  impossible as it doesn't support attachments, and various other things -
  we would lose a huge amount of info if we attempted to port our current
  Trac database.

  There were a fair amount of other objections too. Some copy and paste
  from that thread:

  Aymeric wrote:
  """
  I just looked at it again and here's what I noticed:
  - there is no workflow, so we lose the ability for the community to
  triage tickets;
  - we can't upload patches (which forces every contributor to sign up for
  GitHub and learn git) or arbitrary files (like logs, screenshots,
  tracebacks: not everything is a pull request);
  - there isn't a notion of "component", so there's no way to ask "give me
  the list of all contrib.auth tickets, so I can find the duplicate quickly";
  - we can't put customized flags on tickets (easy, ui/ux) -- there are
  tags, but the result of the "Keywords" field in Trac shows the limits of
  unstructured tags;
  - it's hard to navigate when there are more than 200 open tickets on a
  project.
  """

  Justin Bronn wrote:
  """
  GitHub's issue tracker is so much worse than Trac I don't know why we're
  even considering it.  I can attest it has NOT gotten better with age,
  and large projects on GitHub can't use it either.  For example, both
  Chef and Puppet are hosted on GitHub yet use their own ticket solutions
  (Puppet uses Redmine, Chef uses Jira).  The Pinax folks wrote their own
  issue system rather than using GitHub's!
  """

  Cheers,

  Luke

  --
  "My capacity for happiness you could fit into a matchbox without
  taking out the matches first." (Marvin the paranoid android)

  Luke Plant || http://lukeplant.me.uk/


  --
  You received this message because you are subscribed to the Google Groups 
"Django developers" group.

  To post to this group, send email to [email protected].
  To unsubscribe from this group, send email to 
mailto:django-developers%[email protected].
  For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

--
Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
Office: 613-817-6833
Fax: 613-817-4553
Toll Free: 1-855-5DANOLS
Kingston, ON K7L 1H3, Canada

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to