I wasn't advocating creating new branches or stuff, just *saying* on
the website whether the current dev branch (svn trunk) is in heavy
dev, feature freeze or bugfixes only. It's only a matter of
communication, I certainly did not advocate maintaining a new "stable
but cuting edge" svn branch.
-1 What's the benefit of that over our current system where 0.96 is
stable (except for major security fixes), and the active development
is going on in trunk? This has been documented:
http://www.djangoproject.com/weblog/2007/apr/06/changes/ - people
should be using the 0.96 release on
On Apr 25, 9:50 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> use a kernel or gcc-like terminology for the branches.
+1
User can use a stable SVN version (with bugfix state) and there exist
a heavy dev branch for experimentals. This branch can have a "feature
freeze state". In this time
As an bug reporter, I have a small suggestion to make: use a kernel or
gcc-like terminology for the branches. The main page could list 0.96
and (trunk or dev or 0.97) and clearly state that the 0.96 branch is
only accepting bugfixes and that the trunk branch is under heavy dev,
with fixes
On Wed, 2007-04-25 at 00:24 -0700, Simon G. wrote:
[...]
> Maybe we could tag these somehow ("outstanding"?) so that the next
> time a dev. gets some ticket time, they can glance over them and give
> some feedback (wontfix, pls. improve patch, will-do-it-when-I-have-
> time, etc).
If it's marked
Evening all,
Speaking as a triager, I originally thought that an "easy-fix"
category would help solve these issues.
However, after doing quite a bit of ticket twiddling, these easy fix/
low hanging fruit don't hang around very long anyway. The tend to get
closed pretty quickly, even without
On Tue, 2007-04-24 at 09:17 -0700, Vinay Sajip wrote:
> > > What's the thinking on documentation-only patches? While they are just
> > > as worthy of review and critical assessment as code patches, there is
> > > less of a concern about affecting trunk stability, and less impact
> > > analysis
> > What's the thinking on documentation-only patches? While they are just
> > as worthy of review and critical assessment as code patches, there is
> > less of a concern about affecting trunk stability, and less impact
> > analysis work needed.
>
> Not true. We try to be very careful about the
On Mon, 2007-04-23 at 13:28 -0700, Vinay Sajip wrote:
> > > I think it's very easy to underestimate the amount of work required in
> > > checking in a patch. It seems like a simple handful-of-lines patch like
> > > yours
> > > should be a no-brainer, but there's a whole bunch of steps I (or any
> > I think it's very easy to underestimate the amount of work required in
> > checking in a patch. It seems like a simple handful-of-lines patch like
> > yours
> > should be a no-brainer, but there's a whole bunch of steps I (or any
> > other bug fixer) has to go through before we can check a
On 4/18/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 4/18/07, Daniel Brandt <[EMAIL PROTECTED]> wrote:
> > Something has been bugging me for a while..
>
> This type of complaint seems to come up every few months. I'm always tempted
> to
> ignore it because I have a hard time
On Wed, Apr 18, Jonathan Daugherty wrote:
>
> # 7. Run the regression tests against every supported version of Python
> #with every database backend available.
>
> Do you have a resident buildbot? That could be used to run the
> regression tests on (all pythons) x (all databases).
Jacob Kaplan-Moss wrote:
> I've filed tickets and bugs against many other projects, and as you
> might expect the results run the gamut from "fuck you"[1] to being
> checked in instantly.
> ...
> [1] No prizes for guessing which project this was.
I'll have a shot anyway: RoR? ;-}
# 7. Run the regression tests against every supported version of Python
#with every database backend available.
Do you have a resident buildbot? That could be used to run the
regression tests on (all pythons) x (all databases). It would still
take time, of course, but it could at
On Wed, Apr 18, Daniel Brandt wrote:
>
> Something has been bugging me for a while..
>
> Check out http://code.djangoproject.com/ticket/3012 for a pretty
> critical patch to the locmem cache backend. The patch is accepted and
> ready for checkin, and more than two weeks have passed since. The
15 matches
Mail list logo