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
Err, I think the point was that Trac is less accessible than Github so
Django *should* be using Github Issues instead.
Best,
Alex Ogier
--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.
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.
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
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
This is awesome! Thanks Luke and Karen!
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.
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
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/
"- 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."
"- 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.
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
To unsubscribe from this group, send email to mailto:django-developers%2Bunsu...@googlegroups.com.
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
-----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
--
>
> "- 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.
> 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).
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.
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.)
--
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.
--