Re: GitHub migration planning

[Max Thayer]

Paul,

I meant no offense. I should have been more clear that I meant my question
to explore what makes Trac ideal for Django. My apologies for any
misunderstandings.

Daniel: Indeed, BitBucket was considered. There's a thread about it from
pretty recently here:
http://python.6.n6.nabble.com/Moving-to-Github-vs-Bitbucket-td4476484.html

Best regards,
Max

On Fri, Apr 20, 2012 at 2:52 PM, Paul McMillan  wrote:

> Max, and others on this thread,
>
> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GitHub migration planning

[Max Thayer]

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  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 django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.user refactor: the profile aproach

[Max Thayer]

Hello!

The page you 
linked,
Tom, concludes with this line: "Discussion on django-developers suggests
that complete consensus is unlikely; Currently awaiting BDFL mandate."

Since we have the BDFL mandate, shouldn't we update the page?

Best regards,
Max

On Tue, Apr 10, 2012 at 10:58 AM, Tom Evans wrote:

> On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis  wrote:
> > Hi,
> >
> > I'm not getting why you *have* to add fields to the User model to store
> data
> > pertaining to the user. There is nothing in the proposal for pluggable
> user
> > models that says you can never have a seperate model with a foreign key
> to
> > the user model. It just means that you can define your user model the way
> > you want it to be.
>
> That is perfectly fine. The problem comes when there is a simple
> system to add fields to the user model, people will use it to add
> fields to the user model in their pluggable apps, for 'simplicity' and
> 'ease of use'.
>
> > Why can't third party apps have a model with a foreign key to the user
> table
> > with the pluggable models approach? I imagine you are right that every
> app
> > and it's brother adding fields to the user model is not realistic but I
> > don't think that anyone has proposed that. Certainly not me.
>
> The proposed solution as decided by BDFL diktat is 2a from [1]. I quote:
>
> Split off as much as possible of auth.User into orthogonal mixins that
> can be reused.
> Modify auth.User to inherit these mixins. Care must be taken to ensure
> that the database expression of the new User model is identical to the
> old User model, to ensure backwards compatibility.
> Unrelated and third-party apps can indicate that they depend on
> various orthogonal mixins. For example, contrib.admin can specify that
> it works with auth.User out of the box, and with any model
> implementing PermissionsMixin if you supply your own login forms.
>
> At the moment, you cannot change the user model, so we do not have
> issues relating to third party apps changing the user model. With the
> proposed solution, you would be able to change the user model, so we
> may have issues.
>
> It's also enlightening to read the code from Alex's Django branch,
> which is an initial implementation of option 2a.
>
> > The thing I
> > want to be able to is define user models suitable for my project. Third
> > party apps adding their own fields wasn't proposed by anyone AFAIK, nor
> was
> > specifically requiring that you add them yourself. Some might require
> that
> > your user has something like an 'email' field because that would be a
> common
> > field across apps but app specific data can easily go on a seperate model
> > included with the app that simply has a FK to user. You can then only
> fetch
> > that data on requests that need it.
> >
> > I'm sorry but doing a JOIN every request is a BAD idea. You will run into
> > problems there quickly and have no way out of it besides ditching auth
> > completely (and thus all the thirdparty apps you use that depend on it).
>
> I completely disagree, but I'm not here to try and convince people how
> to design their databases. A JOIN every request will not end the
> world. Besides, it is far more likely to be a separate query than a
> JOIN, and would only happen on views that required that data.
>
> More to the point, what basis are you making this claim on? People
> love to pipe up "JOINs are slow and evil", but have you actually
> analysed the cost compared to monolithic tables?
>
> > Assuming the user table and profile tables are small is awfully short
> > sighted.
>
> To be fair, I was slightly ambiguous with my use of the word 'small'. I
> said:
>
> >> Queries against monolithic tables are much slower than a few queries on
> much
> >> smaller tables.
>
> Here 'small' means fewer columns, not less tuples.
>
> However, assuming tables will be small is precisely what you have just
> done - "we must not have JOINs, they are evil, but it doesn't matter
> because the user table will only have the columns I desire". I agree
> that it is a short sighted position, if you do not prevent the table
> becoming monolithic ;)
>
>
> Cheers
>
> Tom
>
> [1] https://code.djangoproject.com/wiki/ContribAuthImprovements
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For 

Re: auth.User usernames

[Max Thayer]

I and some folks in my area (Boston/Cambridge, MA) are thinking of ways to
provide a solution to this problem that neither requires schema migration
nor breaks backwards compatibility. David, if you (or anyone on this
mailing list) is interested, email me and let's coordinate our efforts.

Alternatively, if all you need is a longer username, this monkey patch
works nicely: https://github.com/GoodCloud/django-longer-username

Best regards,
Max

On Wed, Feb 15, 2012 at 5:57 PM, Donald Stufft wrote:

> On Wednesday, February 15, 2012 at 5:49 PM, James Bennett wrote:
>
> On Wed, Feb 15, 2012 at 4:37 PM, Donald Stufft 
> wrote:
>
> I know this has been discussed before, but I wanted to bring it up again in
> light of the oncoming Djnago 1.4 beta.
>
>
> So, here's the thing: you're asking for a fairly significant,
> massively backwards-incompatible change which requires every Django
> install on the planet to do a schema migration... about four hours
> before we feature-freeze 1.4. There is simply no way this is going to
> get in on that time scale; 1.5, maybe, if the inherent problems can
> get ironed out, and if you're strongly interested in making this
> happen I'd invite you to help out with that.
>
> But 1.4 beta -- and thus feature freeze -- happens tonight, and it's
> flat impossible to land something of this magnitude before that
> happens.
>
>
> 1.5 would work as well ;) Sorry I sometimes speak before I think things
> through,
> thoroughly. django.auth in general is something that i'm interested in and
> I want
> to try and improve to be more flexible, I just hadn't though of a general
> solution yet
> and a "easy" (code wise) fix appealed in a shorter term "provide some
> improvement"
> sort of way.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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 django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: start using less (and bootstrap!)

[Max Thayer]

The point about admin's appeal to new people is important, but
externalizing it and keeping new people from ever seeing it are very
different. Consider: admin isn't even enabled by default. You have to
follow the tutorial on how to enable it. If admin weren't included in
Django proper, we could just change the tutorial to "Apps are awesome;
here's how to download and install one written by someone else." New users
could meet pip sooner, and otherwise understand how to integrate with the
broader python/django community's various creations.

Actually, a friend of mine and I have been plotting out externalizing
various parts of contrib, like admin and auth. Are any groups currently
pursuing those goals as well?

Best regards,
Max

On Fri, Feb 3, 2012 at 8:35 AM, Brendan Smith <
bren...@nationalpriorities.org> wrote:

> I give +1 to the idea of separating out the admin and letting people fork
> and modify to their hearts content
>
> I also still give my +1 to having it utilize less, but I am also cautious
> like others about prescribing bootstrap specifically , especially the JS
> since as others have pointed out is somewhat unstable right now and not
> very easy to use at times (took me a long time to figure out modals)
>
> Sent from my iPhone
>
> On Feb 3, 2012, at 1:25 AM, Harris Lapiroff 
> wrote:
>
> > The Django admin is a major—if not *the* major—selling point to
> > budding developers. I worry that externalizing it (hence making it a
> > *separate* piece of software that needs to be discovered and
> > installed, which seems simple but can be quite a challenge to new
> > coders) might take away Django's non-expert appeal. When I started
> > using Django, I knew no python. The only reason I was able to make
> > that work was because of the Django admin. If the admin gets kicked
> > out, I think it should be made *very* obvious where to find one.
> >
> > I'd be wary of putting them in core but I think using Bootstrap and
> > Less for a new admin (whether internal or external) would make its
> > development much faster. Dependencies should not be a problem. I think
> > jQuery is a pretty apt analogy here. You probably won't write much
> > javascript for the Django admin without learning jQuery. You can if
> > you want to. But most people don't need or want to write javascript
> > for the Django admin anyway. I think a framework like Bootstrap it
> > would actually simplify adding new features. It provides so many CSS
> > classes that there's a pretty good chance your feature wouldn't
> > require you to write even a line of CSS. I was able to convert an
> > unstyled app that I've been working on to functionally using Bootstrap
> > in just about an hour after starting to learn it.
> >
> > That having been said, I'd still be cautious with Bootstrap. It is a
> > young piece of software that is incredibly impressive and mind-
> > bogglingly easy to use, but obviously still in flux.
> >
> > On Feb 2, 5:38 pm, Sean Brant  wrote:
> >> On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor 
> wrote:
> >>
> >>> On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty 
> wrote:
> >>
>  On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant 
> wrote:
> > Is this up somewhere public? I've been fighting the urge to do this
> as
> > well. Using django-compressor with less on Heroku is a non-starter
> > since you can't install node. Having this as a Python module would be
> > handy.
> >>
>  Not yet, alas, but hopefully soon.
> >>
>  Adrian
> >>
>  --
>  You received this message because you are subscribed to the Google
> Groups
>  "Django developers" group.
>  To post to this group, send email to
> django-developers@googlegroups.com.
>  To unsubscribe from this group, send email to
>  django-developers+unsubscr...@googlegroups.com.
>  For more options, visit this group at
>  http://groups.google.com/group/django-developers?hl=en.
> >>
> >>> Perhaps this is too far in the future looking.  But at a certain point
> the
> >>> admin must become a separate project.  One of the major goals of
> >>> newforms-admin ('lo those years ago) was to demote the admin from
> special
> >>> status, with hooks inside core left and right, to "just an app".  Let's
> >>> carry that to the logical conclusion: just an app *outside of Django*.
> >>
> >>> That gives the maintainers the freedom to reinvent it, and use tools
> like
> >>> less or bootstrap without it needing to be an issue of policy for all
> of
> >>> Django.  Because when I first read saw this thread my thought was,
> "Hmm,
> >>> what unholy mess of requirements am I going to need if I want to just
> run
> >>> the test suite.  Will I still be able to write new features in forms
> without
> >>> needing to learn what the hell less or compass is?".  Several years
> ago, I
> >>> opposed using jQuery in the admin, on the principle that Django