fresh-start branch

James Tauber

unread,

Feb 4, 2011, 2:13:54 PM2/4/11

to pinax-c...@googlegroups.com

I recently moved from one apartment to another in the same complex. We had a two-week overlap where we had access to both places so rather than move everything over at once, we moved things we most wanted first, made sure they were set up and then moved on to the next thing. Anything that needed replacing or we didn't want anymore, we left in the old place until the last day when we threw it out.

The Pinax team are undertaking a very similar approach to getting Pinax ready for 0.9 release. There are parts of Pinax that are mature and in production use; there are parts that need cleaning up; and there are parts which need to be replaced completely. Rather than doing all that in-place, we've set up a new branch called fresh-start.

We've moving things over incrementally, starting with foundational starter projects and only the pieces they need. This means that, early on, the fresh-start branch will be pretty sparse (like my new apartment was the first few days). But the stuff that's there will be production ready, or very close to it, and will be reflective of the plans for the 0.9 release. This also gives us an opportunity to do a better job of tests and documentation by helping prioritize our time to the most important and stable parts of the codebase.

If there's stuff in Pinax master that isn't in the fresh-start branch, it could be that we simply haven't gotten to it yet. Or it could mean we're deprecating its usage and plan an alternative approach in the new branch (and hence 0.9). If in doubt, please ask us our plans.

We are in the process of setting up an alternative issue tracking system instance for the fresh-start branch (which will still be based on Pinax, of course). This will help us focus on the code being prepared for release rather than sorting out issues in code that will be discontinued anyway. We will keep you posted on this new tracking system.

James

david wilson

unread,

Feb 5, 2011, 12:49:50 AM2/5/11

to pinax-c...@googlegroups.com

When are you hoping to finish the full 0.9 release and I assume we will be part id that. It sounds like we will need our cycle around it?

> --
> You received this message because you are subscribed to the Google Groups "Pinax Core Development" group.
> To post to this group, send email to pinax-c...@googlegroups.com.
> To unsubscribe from this group, send email to pinax-core-de...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pinax-core-dev?hl=en.
>

limist

unread,

Feb 23, 2011, 2:59:11 PM2/23/11

to pinax-c...@googlegroups.com

This is excellent; for one thing, I'd dearly love to have the whole shebang of Pinax unit tests pass again. It'd also help keep Pinax in the role of being a canonical example of Django usage, w.r.t. apps, configuration, integration code, etc.

What can those of us not on the Pinax core team do, to help accelerate this effort? Will someone review pull requests if we fork this branch and do some useful work?

Skylar Saveland

unread,

Feb 23, 2011, 6:08:54 PM2/23/11

to pinax-c...@googlegroups.com

I like the idea a lot, James.

I should probably make a separate thread. But, along a similar vein ... I was recently building up a zero project so as to have an example project in a pluggable app that I'm building.

First, I just can't stand the base template that doesn't get copied into your source control. So, I copied base.html to my templates directory and stripped it to:

{% load i18n %}

<!DOCTYPE html>

<head>

<title>{% block head_title_base %}{% if SITE_NAME %}{{ SITE_NAME }} : {% endif %}{% block head_title %}{% endblock %}{% endblock %}</title>

{% block extra_head_base %}{% block extra_head %}{% endblock %}{% endblock %}

</head>

<div id="nav">{% block nav %}{% endblock %}</div>

<div id="subnav">{% block subnav %}{% endblock %}</div>

<div id="body">{% block body %}{% endblock %}</div>

<div id="footer">{% block footer %}{% endblock %}</div>

{% block extra_body_base %}{% block extra_body %}{% endblock %}{% endblock %}

</body>

</html>

The base.html template is ugly (not the design of the pages but the html source itself), sorry :) No self-respecting frontend guyirl is going to allow the base template to come from framework magic. Also, is everyone going to want to {% include "facebox_js.html" %} on every page? I would say that most websites are not.

Anyways, that wasn't my main point. I really should have made a separate thread or two :-)

Second, I didn't want people to have to install pinax to run my sample project. So, I stripped out imports of pinax from the settings. I even had the idea of maintain a project, "nopinax", just a (further) stripped down zero project, geared to run with django latest stable without further dependencies. Maybe there can be a "nopinax" project within pinax instead ;).

See you guys at Pycon!

Skylar

On Wed, Feb 23, 2011 at 2:59 PM, limist <k...@limist.com> wrote:

This is excellent; for one thing, I'd dearly love to have the whole shebang of Pinax unit tests pass again. It'd also help keep Pinax in the role of being a canonical example of Django usage, w.r.t. apps, configuration, integration code, etc.

What can those of us not on the Pinax core team do, to help accelerate this effort? Will someone review pull requests if we fork this branch and do some useful work?

--

Dylan Clendenin

unread,

Feb 23, 2011, 10:32:08 PM2/23/11

to pinax-c...@googlegroups.com, Skylar Saveland

I'm sad I'm not going to PyCon simply because I can't personally slap you upside your head for coming into my beloved Pinax mailing list and talking all that mess.

Just kidding my friend. You better help do something about it at the sprints though.

--
Dylan Clendenin
831.331.1484

Reply all

Reply to author

Forward