Suggestion to make Chuck Norris happy again
Christoph Zwerschke
Norris really does not like it. It looks like this is caused by the fact
that we now use Crank which is missing in the current index. This also
reveals an issue with the test setup in general. The Jenkins script is
installing the dependencies from http://tg.tgy/current/index/. To do it
properly we should add another directory /next/ parallel to /current/ on
the TG server. In the beginning, /next/ should be a copy of /current/.
When we update or add to our requirements, the packages in /next/ should
be adapted, e.g. put Crank in here or a newer version of WebOb. The
tests setup should then install from /next/ and at the time we create a
new release we already have our packages ready and just need to rename
/next/ to /current/.
-- Christoph
Alessandro Molina
handle the insertion of new dependencies inside the project during the
development process. Not having it makes a bit useless Jenkins itself
as you are not able to know if things are broken for real as they
always result being broken due to missing/wrong dependencies.
> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears Trunk" group.
> To post to this group, send email to turbogea...@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears-tru...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears-trunk?hl=en.
>
Mengu
On Feb 10, 5:25 pm, Alessandro Molina <alessandro.mol...@gmail.com>
wrote:
> handle the insertion of new dependencies inside the project during the
> development process. Not having it makes a bit useless Jenkins itself
> as you are not able to know if things are broken for real as they
> always result being broken due to missing/wrong dependencies.
>
>
>
>
>
>
>
> On Fri, Feb 10, 2012 at 11:37 AM, Christoph Zwerschke <c...@online.de> wrote:
> > The TG 2.1 tests on the Jenkins server are currently failing and Chuck
> > Norris really does not like it. It looks like this is caused by the fact
> > that we now use Crank which is missing in the current index. This also
> > reveals an issue with the test setup in general. The Jenkins script is
Christoph Zwerschke
the corresponding branches in our Git repository. The "development"
directory contains the Crank package which made Chuck really happy.
Is the development branch supposed to work with Python 2.4? There are
two issues that currently break it, namely jinja_lookup (which I fixed
already) and Crank which also may be easily fixable but I haven't looked
at it yet.
-- Christoph
Alessandro Molina
Michael can probably confirm this as I remember him adding version
check inside the TG source code.
If we didn't it is probably the right time to do it as the python3
development branch also drops support for python2.5, so dropping 2.4
support might lead to a softer upgrade path.
Christoph Zwerschke
> I remember Python2.4 support being dropped with the last release.
> Michael can probably confirm this as I remember him adding version
> check inside the TG source code.
There is only a version check that allows Py2.4 to work by adding
pysqlite and hashlib. We could remove this and simplify other code when
we really want to drop Py2.4. We should then also make Jenkins test with
Py2.5 and 2.7 instead of 2.4 and 2.6.
I'm currently a bit confused about our roadmap and which branch will
become which version. Is there a protocol of our decisions in January?
-- Christoph
Alessandro Molina
About roadmap when I spoke with Michael to was going to post a
reorganized version of the notes of the metting to make things more
clear even for users.
I'm currently managing work this way:
development branch -> 2.2
pylons-less branch -> 2.3
python3 branch -> whatever will be after that
I often merge changes from lower version branches into higher version
branches to keep things in sync.
Christoph Zwerschke
> I'm currently managing work this way:
>
> development branch -> 2.2
> pylons-less branch -> 2.3
> python3 branch -> whatever will be after that
And the "next" branch is for the next 2.1.x bugfix release, right?
Alessandro Molina
Uhm,
Actually I always thought that the next branch was only for release
process like stated on
http://www.turbogears.org/book/appendices/preprelease.html#finalizing-changes-on-next-branch
I always used the "development" branch for bugfixes that should have
gone in the next to come release.
Christoph Zwerschke
> Actually I always thought that the next branch was only for release
> process like stated on
> http://www.turbogears.org/book/appendices/preprelease.html#finalizing-changes-on-next-branch
Makes sense, then this is only intended as a temporary branch.
> I always used the "development" branch for bugfixes that should have
> gone in the next to come release.
But if that next release will be 2.2 and we later want to release a
2.1.5 bugfix we should also have a separate 2.1 branch (which still
supports Py2.4 and works without Crank). Since the development branch
has already progressed to Crank, we need to create the 2.1 branch from
the masteror the last "next" branch. There is already a brach-2.0.
-- Christoph
Alessandro Molina
>
> But if that next release will be 2.2 and we later want to release a 2.1.5
> bugfix we should also have a separate 2.1 branch (which still supports Py2.4
> and works without Crank). Since the development branch has already
> progressed to Crank, we need to create the 2.1 branch from the masteror the
> last "next" branch. There is already a brach-2.0.
>
That is a good question and I don't think there is currently an
official answer to that.
I was indeed thinking that some changes like the fix to doctype
management and multipagination would make sense in a 2.1.5 bugfix
release.
It can make sense discussing if we want to push out a bugfix release
or not before 2.2