GitHub migration planning
philipn
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.
-Philip
Dalton Barreto
Maybe the best way to avoid that people create issues on github is to
disable it for the
official repository. This is possible through the Github's Admin interface.
Thanks,
--
Dalton Barreto
http://daltonmatos.com
Alex Ogier
Err, I think the point was that Trac is less accessible than Github so
Django *should* be using Github Issues instead.
Best,
Alex Ogier
Donald Stufft
--You received this message because you are subscribed to the Google Groups "Django developers" group.To post to this group, send email to django-d...@googlegroups.com.To unsubscribe from this group, send email to django-develop...@googlegroups.com.For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Dalton Barreto
Hmm, this would probably disable pull requests too. Not a good idea,
assuming that
contributions will be accepted as pull requests on this new repo.
Łukasz Rekucki
> Github Issues are not flexible enough for Django.
>
That's rather a vague statement. Github issues are actually more
*flexible* then Trac as you can define any set of tags for an issue.
What Django could possibly want to have is a way to create extra
constraints on the tags, but as a matter of fact, the current Trac
instance doesn't do that! (you can have an issue with "tests needed"
but without "patch needs improvement").
--
Łukasz Rekucki
Karen Tracey
>> Maybe the best way to avoid that people create issues on github is to
>> disable it for the
>> official repository. This is possible through the Github's Admin interface.
>>
>
> Hmm, this would probably disable pull requests too
No, it does not, unless I am mis-understanding what you are saying.
https://github.com/django/django/
has no issues (issues is unchecked in admin area), but it has pull requests.
Karen
Luke Granger-Brown
Donald Stufft
Dalton Barreto
This is awesome! Thanks Luke and Karen!
philipn
On Wednesday, April 18, 2012 5:26:27 PM UTC-7, dstufft wrote:
Github issues do not have the ability for anyone to close, tag, or createmilestones. You have to be the creator of the ticket or someone withcommit access. Django's track instance allows anyone to participatein this way and is one of the major reasons to my knowledge thatDjango will keep it's trace instance.
Alex Ogier
Lack of milestones could probably be worked around, but without the
ability to tag issues Django's triage process would be dead in the
water. I don't know if Django could support that, we are up to ticket
#18xxx now. That doesn't mean there aren't ways to improve the status
quo: maybe pull requests could be supported as an explicit alternative
to attached patches. That might mean we lose explicit notification of
all code changes on a ticket.
A Trac plugin that follows changes to a GitHub pull request sounds
like a powerful tool, and could be widely useful. There's not actually
a way to notify Trac of changes to pull requests as far as I can tell,
but you can query and check for recent updates. I'll look into this
more.
As an aside, just because we are starting to use git doesn't mean that
linear history isn't valuable. I know of several successful projects
that use git that use patch-based workflows rather than merging. The
advantage of that is a linear history with each feature packaged into
a neat commit. The extra detail is great for developing, but not so
great for a mainline history (it breaks 'git bisect' for example).
Best,
Alex Ogier
Luke Plant
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/
Max Thayer
"- 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";"
"- 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;"
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
Paul McMillan
Arguing about the specific mechanics of how github issues work isn't
productive. Put very plainly:
Django will not move to github issues because they cannot support our
open community triage process.
This is not negotiable.
Regards,
-Paul
Daniel Sokolowski
To unsubscribe from this group, send email to mailto:django-developers%2Bunsu...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
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
Max Thayer
Alex Ogier
<daniel.s...@klinsight.com> wrote:
> 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.
Well there are two somewhat related questions in play. One is moving
Django's master repository to Git from SVN. This has a lot of support,
as Git is significantly more powerful and many (most?) Django
developers already use the Git mirror.
The other debate is about switching to Github as a hosting platform.
It already hosts the Git mirror, and people regularly submit pull
requests, a feature made possible by Git and that is being considered
as an alternative to submitting patches. Github Issues are basically
unacceptable for Django's process, so they have never been seriously
considered as far as I know.
There is a large social benefit to leveraging github: there is a large
community of developers with established presences there, and making
Django accessible to that community is valuable. BitBucket does not
have the same social benefits, and all the same drawbacks, so I don't
think anyone would seriously advocate moving there.
Best,
Alex Ogier
Daniel Sokolowski
-----Original Message-----
From: Alex Ogier
Sent: Friday, April 20, 2012 3:15 PM
To: django-d...@googlegroups.com
Subject: Re: GitHub migration planning
On Fri, Apr 20, 2012 at 2:58 PM, Daniel Sokolowski
<daniel.s...@klinsight.com> wrote:
> 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.
Well there are two somewhat related questions in play. One is moving
Django's master repository to Git from SVN. This has a lot of support,
as Git is significantly more powerful and many (most?) Django
developers already use the Git mirror.
The other debate is about switching to Github as a hosting platform.
It already hosts the Git mirror, and people regularly submit pull
requests, a feature made possible by Git and that is being considered
as an alternative to submitting patches. Github Issues are basically
unacceptable for Django's process, so they have never been seriously
considered as far as I know.
There is a large social benefit to leveraging github: there is a large
community of developers with established presences there, and making
Django accessible to that community is valuable. BitBucket does not
have the same social benefits, and all the same drawbacks, so I don't
think anyone would seriously advocate moving there.
Best,
Alex Ogier
--
Luke Plant
> 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"?
>
>
> "- 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.
They are very different things in reality.
With tags, it is up to people to decide which kind of tagging they think
is relevant. With flags, we've already decided, it's there in the UI,
and every time you create or update a ticket you scroll past the
questions we've decided are important and that you may need to update.
Without this, tagging quickly becomes next to useless for querying.
Also, tags are unstructured, so if you use it for more than one purpose,
everything lives in the same namespace. Sure, there are things you could
do to help matters, like colours and prefixes, but there are no
constraints to stop multiple assignments in the same category etc.
Also, the tracking on these things is basically non-existant in GitHub.
When I read a ticket, it tells me explicitly that such and such user set
such and such flag. For tags like "Ready for checkin", the flag is
*massively* less useful without this information (I will assess the
accuracy of the flag by the person who set it, and also as a core
developer looking for reliable triagers and potential developers, I'm
assessing the accuracy of the person by the flags they set).
It also seems that only managers can set tags in GitHub Issues, which
would kill the community triage process we have.
> "- 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?
For one thing, the Trac UI just makes much better use of screen space.
There is no comparison between these two in terms of easily finding the
information you want:
https://code.djangoproject.com/query
https://github.com/divio/django-cms/issues
Trac also has pretty nice reporting abilities, and report building
abilities:
https://code.djangoproject.com/wiki/Reports
No-one thinks Trac is ideal, it's just much better than GitHub Issues
which, in its own words, is a "lightweight" issue management system.
Luke Plant
> 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.
Some of the discussion happened on django-core.
One of the reasons for this was that it affects core developers most of
all, so Adrian wanted their opinions first.
Another reason was that this kind of change is almost certainly going to
require a BDFL decision, because we will never come to consensus on Git
vs Mercurial etc. - even within the core developers they are strong
preferences in both directions, and even strong preferences to stick
with Subversion. And I guess that's the reason that we didn't have
further discussion on django-devs - since it already needed a BDFL
decision, there was no point making the pretence of discussion in a
wider forum. (Adrian/Jacob feel may correct me if I'm guessing wrongly).
Daniel Sokolowski
-----Original Message-----
From: Luke Plant
Sent: Saturday, April 21, 2012 8:52 AM
To: django-d...@googlegroups.com
Subject: Re: GitHub migration planning
> 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
Some of the discussion happened on django-core.
One of the reasons for this was that it affects core developers most of
all, so Adrian wanted their opinions first.
Another reason was that this kind of change is almost certainly going to
require a BDFL decision, because we will never come to consensus on Git
vs Mercurial etc. - even within the core developers they are strong
preferences in both directions, and even strong preferences to stick
with Subversion. And I guess that's the reason that we didn't have
further discussion on django-devs - since it already needed a BDFL
decision, there was no point making the pretence of discussion in a
wider forum. (Adrian/Jacob feel may correct me if I'm guessing wrongly).
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 django-d...@googlegroups.com.
To unsubscribe from this group, send email to
django-develop...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Web Engineer
KL Insight
http://klinsight.com/
Tel: 613-344-2116 | Fax: 613.634.7029
993 Princess Street, Suite 212
Tai Lee
Maybe I wasn't following closely enough (apologies if that is the case), but my impression was that this decision was reached behind closed doors without a great deal of focussed community discussion or attempt to reach consensus. I just remember Adrian basically saying (and I'm paraphrasing here): "I've been away too long, but I'm back now and I've decided that we're moving to GitHub!"
Yes, there have been threads about moving to this or that environment, but I don't remember a thread started by Django core letting the community know that a move was seriously on the cards, and giving the community a chance to have some formal input before a decision was made.
Even if Django core feels that a BDFL decision will be required, I still think it is appropriate to raise such a change with the community and ask for some structured proposals, and then if necessary make a BDFL decision that shows which elements from which proposals have been blessed.
There's always a possibility that the community has something to say that could sway the decision, even if Adrian or Jacob are 99% decided. And even if it doesn't change the outcome, at least there is a clear public record of the decision making process.
I don't necessarily disagree with the decision that was made, but I would have liked to see more openness in the discussion and decision making process.
Cheers.
Tai.
Danny Adair
> This seems odd to me. [...]
> that a move was seriously on the cards, and giving the community a chance to
> have some formal input before a decision was made.
> On Saturday, 21 April 2012 22:52:01 UTC+10, Luke Plant wrote:
>> decision, there was no point making the pretence of discussion in a
This doesn't seem odd to me. Makes perfect sense imho.
Cheers,
Danny
Florian Apolloner
On Tuesday, April 24, 2012 7:30:05 AM UTC+2, Tai Lee wrote:
I just remember Adrian basically saying (and I'm paraphrasing here): "I've been away too long, but I'm back now and I've decided that we're moving to GitHub!"
I had that feeling a bit myself, but I think there have been more than enough discussions internally (including with Adrian) and I am sure Adrian didn't intend it to sound the way we probably understood it.
Yes, there have been threads about moving to this or that environment, but I don't remember a thread started by Django core letting the community know that a move was seriously on the cards, and giving the community a chance to have some formal input before a decision was made.
Given those threads with kinda heated discussions whether bitbucket is better than github or the other way around I think it's clear that a BDFL decision is/was needed.
Even if Django core feels that a BDFL decision will be required, I still think it is appropriate to raise such a change with the community and ask for some structured proposals, and then if necessary make a BDFL decision that shows which elements from which proposals have been blessed.
Well the main point was whether we want svn, git or hg -- and as someone already said; even in the core team are tendencies for any of them. That said, and given the fact that we can agree that none of those systems is superior there is not much point in starting more heated discussions again. Also don't forget that it's probably the core team which has to deal with the chosen system the most; we as community can easily use git-svn etc... (Yes the core team can too, but has to be aware of the pitfalls)
There's always a possibility that the community has something to say that could sway the decision, even if Adrian or Jacob are 99% decided. And even if it doesn't change the outcome, at least there is a clear public record of the decision making process.
I think the timing was a bit bad, since internal discussions and public ones (started by the community) overlapped, so there probably wasn't a clear direction in the core team itself yet, which made it hard to present the idea etc...
Cheers,
Florian
Aaron C. de Bruyn
> This seems odd to me. Django is generally a very open and community oriented
> project, which strives to consult with the community and achieve a
> consensus, resorting to a BDFL decision when necessary, after all sides have
> put their case.
You're right. Speaking as a 'developer' who has contributed something
like 14 lines of code to Django ever, evar, I think everyone should
listen to me tell you why Microsoft's Visual Source Save 5.0* is the
best.
* It's not 'distributed' like all those new-fangled systems. Too many
people working on a project at the same time introduces bugs.
* Single point of control. Someone needs to review and test
everything. If they go on vacation for a week, development should
stop and everyone else should go on vacation too.
* Harder to fork. We don't need 50,000 forks of Django floating
around. It'd be confusing.
* Backed by a company with billions of dollars. This will ensure
innovation, and prompt bug fixing.
* Paid support. If something goes wrong with the database that stores
the code, we can hold a Django bakesale to raise money to pay for them
to recover it.
Any arguments to my points will be taken as a personal attack because
you're attacking my personal choice of RCS after all. ;)
Hopefully everyone realizes that was a joke by this point.
But seriously, getting a bunch of geeks to decide on 'the best' RCS
will go over as well as deciding on the best text editor, the best IDE
to use for developing with Django, the best desktop environment, the
best distro, the best religion, or any number of other unresolved
discussions raging on millions of forums around the internets.
I personally have invested myself in developing with Django as a
framework. As an 'end user' of the framework, I trust the core
developers to make sound decisions about its future--including which
RCS to use. They are the ones who will be most impacted by the change
after all.
-A
* (No, I really don't want Microsoft's Visual Source Safe. Nobody wants that.)
Mohamad Efazati
maybe this link can be helpful
CommercialServices – The Trac Project -> http://trac.edgewall.org/wiki/CommercialServices
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
--