I agree we need to mention dependencies, though, as some will, for example, assume DUA
and I think it’s much better to just say it assumes DUA than “it has to be a 100% Pinax project!” (which doesn’t make sense but people think that way)
Patrick Altman
@paltman
i was thinking for DUA we could make it optional
most dependency on DUA is for LoginRequiredMixin or decorator
and i think we can use DUA if it exists but roll back to contrib.admin if not
should the preamble include a brief bit about what Pinax is?
James Tauber
@jtauber
@paltman I’d love some system that automatically diffs starter projects that are based on one another so we remember to make upstream or downstream updates
ages ago I suggested whether actually making starter projects forks of each other (or at least branches) would enable us to use Git/Github for that but that seemed to complicate things
a better approach might just be something for modeling upstream relationship and providing easy diffing
but it seems tantalisingly like Git could be used for it :-)
Patrick Altman
@paltman
yeah
it might be worth experimenting with a pinax-project repo
put zero on master and then branch from there
account branch for PPA for example
then if PPA had versions it would breanch from account to things like account-1.2, account-1.2
i’d like to revisit this as branches
as that seems like that is really what they are
long lived branches
i guess the only difference with a typical branch is that they are never designed to merge upstream
but only get updates from upstream
James Tauber
@jtauber
it occurs to me that locally you could have, say, PPA, with two remotes set up: one the master of the PPA repo and one the PPA-branch of the pinax-project repo. That’s how you could basically keep them in sync