1.0.1 release blockers?

[mrts]

There has been much reluctancy in letting triagers tag and prioritize
1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
perhaps discuss what are the things that really should be fixed before
it is released?

The only major issue I have encountered is http://code.djangoproject.com/ticket/8882
that makes inline formsets that have unique fields (that is, pretty
much every other use case for them) unusable. Looks like brosner is
already working on it -- thanks! -- and it would be perhaps wasteful
if 1.0.1 is released before he has finished.

I believe this does not fall to the often-quoted "this is your
personal issue, go write a patch" category (I have worked around it
and brosner is already on it) -- it is just a common use case that
doesn't work as advertised. There are probably other major bugs and it
would be nice if people brought them up. Also, it would be nice if
some restraint is exercised in regard the attitude-laden remarks that
are quick to arise in this type of discussions.

[Jacob Kaplan-Moss]

On Fri, Oct 31, 2008 at 4:38 AM, mrts <mr...@mrts.pri.ee> wrote:
> The only major issue I have encountered is http://code.djangoproject.com/ticket/8882

Thanks for the pointer; I'd agree this should get in.

Jacob

[alex....@gmail.com]

Ahh whoops, I have a patch for that(only covers unique right now),
will upload now.

Alex

On Oct 31, 9:26 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
> On Fri, Oct 31, 2008 at 4:38 AM, mrts <m...@mrts.pri.ee> wrote:
> > The only major issue I have encountered ishttp://code.djangoproject.com/ticket/8882

[alex....@gmail.com]

And whoops again, brosner has a patch that covers the parent fkey
issue. My patch covers the issue of duplicate data within the
formset.

On Oct 31, 9:26 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:

> On Fri, Oct 31, 2008 at 4:38 AM, mrts <m...@mrts.pri.ee> wrote:
> > The only major issue I have encountered ishttp://code.djangoproject.com/ticket/8882

[Karen Tracey]

On Fri, Oct 31, 2008 at 6:38 AM, mrts <mr...@mrts.pri.ee> wrote:

There has been much reluctancy in letting triagers tag and prioritize
1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
perhaps discuss what are the things that really should be fixed before
it is released?

Really, there is not reluctance to get input on what should be fixed before 1.0.1 is released.  It's just that input in the form of working patches with tests and doc is far more valuable than a simple bit on a ticket.  The list of tickets that are ready for checkin is not so big (and some of them are enhancements so not candidates for 1.0.1.) that we need some other bit to say "look at this before releasing 1.0.1".

The only major issue I have encountered is http://code.djangoproject.com/ticket/8882
that makes inline formsets that have unique fields (that is, pretty
much every other use case for them) unusable. Looks like brosner is
already working on it -- thanks! -- and it would be perhaps wasteful
if 1.0.1 is released before he has finished. 

It really depends on how close a fix is as to whether it would be worthwhile holding up a bugfix release on any one ticket. I'm not talking about this ticket in particular (which I haven't looked at and it sounds like it's already on others' radars so likely will get in, assuming it's not too terribly difficult to fix) -- I'm trying to get across that holding up a bugfix release in hopes of a not-yet-existent fix for a bug that's already in a shipped release doesn't make much sense, unless you've got some reason to believe a fix will be appearing real soon now.  There are already many bugs that have been fixed in the 1.0.X branch and will benefit users.  1.0.1 will be better than 1.0, and 1.0.1 released in the very near future with n-x bugs fixed is better than 1.0.1 released at some unknown future data with those those additional x bugs fixed.

Karen

[Joey Wilhelm]

I would like to suggest the following:
http://code.djangoproject.com/ticket/9245
http://code.djangoproject.com/ticket/6710

They both have fully functional patches... although granted the second has no tests.

[James Bennett]

On Fri, Oct 31, 2008 at 5:38 AM, mrts <mr...@mrts.pri.ee> wrote:
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?

We certainly can discuss such things. To open a discussion on a
particular ticket, post a working patch with unit tests.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Steve Holden]

Karen Tracey wrote:
> On Fri, Oct 31, 2008 at 6:38 AM, mrts <mr...@mrts.pri.ee
> <mailto:mr...@mrts.pri.ee>> wrote:
>
>
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?
>
>
> Really, there is not reluctance to get input on what should be fixed
> before 1.0.1 is released. It's just that input in the form of working
> patches with tests and doc is far more valuable than a simple bit on a
> ticket. The list of tickets that are ready for checkin is not so big
> (and some of them are enhancements so not candidates for 1.0.1.

> <http://1.0.1.>) that we need some other bit to say "look at this

> before releasing 1.0.1".
>
>
> The only major issue I have encountered is
> http://code.djangoproject.com/ticket/8882
> that makes inline formsets that have unique fields (that is, pretty
> much every other use case for them) unusable. Looks like brosner is
> already working on it -- thanks! -- and it would be perhaps wasteful
> if 1.0.1 is released before he has finished.
>
>
> It really depends on how close a fix is as to whether it would be
> worthwhile holding up a bugfix release on any one ticket. I'm not
> talking about this ticket in particular (which I haven't looked at and
> it sounds like it's already on others' radars so likely will get in,
> assuming it's not too terribly difficult to fix) -- I'm trying to get
> across that holding up a bugfix release in hopes of a not-yet-existent
> fix for a bug that's already in a shipped release doesn't make much
> sense, unless you've got some reason to believe a fix will be
> appearing real soon now. There are already many bugs that have been
> fixed in the 1.0.X branch and will benefit users. 1.0.1 will be
> better than 1.0, and 1.0.1 released in the very near future with n-x
> bugs fixed is better than 1.0.1 released at some unknown future data
> with those those additional x bugs fixed.
>

Well right, that'll be 1.0.2 if it's needed. Though with 1.1 on the way
it seems less than likely.

regards
Steve

[Tai Lee]

On Nov 1, 1:38 am, "Karen Tracey" <kmtra...@gmail.com> wrote:
>
> Really, there is not reluctance to get input on what should be fixed before
> 1.0.1 is released.  It's just that input in the form of working patches with
> tests and doc is far more valuable than a simple bit on a ticket.  The list
> of tickets that are ready for checkin is not so big (and some of them are
> enhancements so not candidates for 1.0.1.) that we need some other bit to
> say "look at this before releasing 1.0.1".

#8898 and #9482 are both simple bug fixes with patches that remain
unreviewed. #9214 is a simple backwards compatible enhancement with
patch.

I'm reluctant to mark them "ready for checkin" as I am the reporter,
but it's been 1-2 months for some of these with no review from
anybody, and at least the first two are very simple fixes for bugs
with no change in functionality.

How should one get attention for these tickets?

http://code.djangoproject.com/ticket/8898
http://code.djangoproject.com/ticket/9482
http://code.djangoproject.com/ticket/9214

[Karen Tracey]

On Sat, Nov 1, 2008 at 9:14 PM, Tai Lee <real....@mrmachine.net> wrote:

#8898 and #9482 are both simple bug fixes with patches that remain
unreviewed. #9214 is a simple backwards compatible enhancement with
patch.

I'm reluctant to mark them "ready for checkin" as I am the reporter,
but it's been 1-2 months for some of these with no review from
anybody, and at least the first two are very simple fixes for bugs
with no change in functionality.

How should one get attention for these tickets?

For each of these you mention, I see a reason it has not been committed, which I'll describe below.  In general, what will get fastest attention for 1.0.1 are clear bugs with patches that include tests and doc if appropriate.  If it sounds more like an enhancement than a bug, it's not likely a candidate for 1.0.1. If it doesn' t have tests, it stands less chance of getting in.  If there's confused discussion in the ticket that doesn't seem to have come to a clear consensus on the right answer, that'll likely slow things down.

http://code.djangoproject.com/ticket/8898

I suspect this one may be stalled because it is in design decision needed state with a last comment that makes it sound like the existing patch (added before the last comment) is not correct and that the right fix will require changes that are potentially backwards-incompatible ("users should be guided to use X if they want to use Y"...how is that different from what users are guided to do today and is there something they can do today that won't be allowed after this fix is made?)

The bug sounds like it should be fixed, but that last comment makes it sound like a proper fix is not yet available.  Therefore not something that can easily be simply committed but rather will require someone to spend some time researching the history of this type of field to make sure the right fix is developed.  This rather conflicts with what you say above about this being a simple fix, so please clarify in the ticket if that last comment and move to design decision needed was not meant to raise a red flag that the initially posted fix was not all that was necessary to fix this problem.

http://code.djangoproject.com/ticket/9482

This one is only two days old.  Give it time.  But there's an easy workaround (set the environment variable yourself before calling whatever script you are runnig), this is not something covered by the test suite so can't be tested to ensure it really doesn't break anything ("I can't see how this could possibly break anything" are some famous last words, and believe me I've said them myself), and it seems like a bit of an edge case (I haven't heard a lot of people needing to put code in a project's __init__.py file) all of which argue to me that it might not be a good candidate for 1.0.1.  But that's just me, and it is only two days old. 

http://code.djangoproject.com/ticket/9214

This one reads to me like a feature request, not a bugfix.  (You even say above it is an enhancement.)  1.0.X is bugfixes only so I'd be surprised if something like this goes into it.

Karen

[Tai Lee]

Thanks for your feedback, Karen.

> http://code.djangoproject.com/ticket/8898
>
> I suspect this one may be stalled because it is in design decision needed
> state with a last comment that makes it sound like the existing patch (added
> before the last comment) is not correct and that the right fix will require
> changes that are potentially backwards-incompatible ("users should be guided
> to use X if they want to use Y"...how is that different from what users are
> guided to do today and is there something they can do today that won't be
> allowed after this fix is made?)
>
> The bug sounds like it should be fixed, but that last comment makes it sound
> like a proper fix is not yet available. Therefore not something that can
> easily be simply committed but rather will require someone to spend some
> time researching the history of this type of field to make sure the right
> fix is developed. This rather conflicts with what you say above about this
> being a simple fix, so please clarify in the ticket if that last comment and
> move to design decision needed was not meant to raise a red flag that the
> initially posted fix was not all that was necessary to fix this problem.

I've put this ticket back to "accepted" as per your comment that the
bug should be fixed. As you say, the DDN and confused comments were
not intended to raise a red flag, and should have been taken to a
separate ticket. The suggested change would have been backwards
incompatible, anyway. IMHO, the bug should be fixed as it is,
regardless of any possible future changes.

There's still no comment in the ticket from a core developer or
anybody else, though. As this is a simple bug fix, can I (as the
reporter) mark this ready for checkin, as there is a patch with tests?

> >http://code.djangoproject.com/ticket/9482
>
> This one is only two days old. Give it time. But there's an easy
> workaround (set the environment variable yourself before calling whatever
> script you are runnig), this is not something covered by the test suite so
> can't be tested to ensure it really doesn't break anything ("I can't see how
> this could possibly break anything" are some famous last words, and believe
> me I've said them myself), and it seems like a bit of an edge case (I
> haven't heard a lot of people needing to put code in a project's __init__.py
> file) all of which argue to me that it might not be a good candidate for
> 1.0.1. But that's just me, and it is only two days old.

Famous last words, indeed. Can you see any way that setting
DJANGO_SETTINGS_MODULE *before* importing the project module could
break existing code? Wouldn't that mean that manually setting
DJANGO_SETTINGS_MODULE before calling any management commands would
also be broken? :)

As you say, this one is not so easy to test that it won't break
anything else (at least, I don't know how). Although it is easy to
reproduce.

Cheers.
Tai.

[James Bennett]

On Sun, Nov 2, 2008 at 5:54 AM, Tai Lee <real....@mrmachine.net> wrote:
> There's still no comment in the ticket from a core developer or
> anybody else, though. As this is a simple bug fix, can I (as the
> reporter) mark this ready for checkin, as there is a patch with tests?

You do know that Karen has a commit bit, right? If she's got concerns
about a ticket, then I at least take that as meaning it's got problems
and isn't ready for checkin.

[Tai Lee]

On Nov 2, 10:57 pm, "James Bennett" <ubernost...@gmail.com> wrote:
>
> You do know that Karen has a commit bit, right? If she's got concerns
> about a ticket, then I at least take that as meaning it's got problems
> and isn't ready for checkin.

Yes, I did notice that. However, as I said, there is still no activity
on the ticket. I've tried to clarify that the DDN was not intended to
prevent a fix being committed. Karen has indicated that it sounds like
the bug should be fixed, however without any review of the actual
patch (just the confused comments) I've left the ticket as "accepted",
even though it has a working patch with tests.

I guess my big question is, if a ticket has a patch with working tests
and/or documentation as appropriate, and is a simple bug fix only, can
the reporter mark it as "ready for checkin"? Then if a core developer
has a problem with the implementation of the fix, it can be marked
patch needs improvement and assigned back to the reporter.

[Karen Tracey]

On Sun, Nov 2, 2008 at 6:54 AM, Tai Lee <real....@mrmachine.net> wrote:

I've put this ticket back to "accepted" as per your comment that the
bug should be fixed. As you say, the DDN and confused comments were
not intended to raise a red flag, and should have been taken to a
separate ticket. The suggested change would have been backwards
incompatible, anyway. IMHO, the bug should be fixed as it is,
regardless of any possible future changes.

There's still no comment in the ticket from a core developer or
anybody else, though. As this is a simple bug fix, can I (as the
reporter) mark this ready for checkin, as there is a patch with tests?

No, please don't -- it'll get looked at as is. Marking ready for checkin is not a required stage to go through to get something in.  It's a flag that indicates someone other than the submitter has looked everything over and agrees with the patch.  It's a helpful but not necessary prerequisite to moving things along.  Having the submitter set it is useless -- barring comments to the contrary it's assumed that when a patch is attached the submitter thinks it is ready for checkin. 

...

Famous last words, indeed. Can you see any way that setting
DJANGO_SETTINGS_MODULE *before* importing the project module could
break existing code? Wouldn't that mean that manually setting
DJANGO_SETTINGS_MODULE before calling any management commands would
also be broken? :)

No, I can't see how it could break anything.  But I've proved to be sufficiently lacking in imagination in answering such questions enough times over the years that I've learned not to be overly impressed with that....

Karen

[Richard Davies]

I would like to nominate:

http://code.djangoproject.com/ticket/8754
http://code.djangoproject.com/ticket/9206

Both have patches which still apply, and just haven't been reviewed
yet.

Richard.

[mrts]

IMHO http://code.djangoproject.com/ticket/8193 is also important
enough to justify inclusion before 1.0.1 (see aslo discussion
http://groups.google.com/group/django-developers/browse_thread/thread/d27261561bc36d96
). Quoting James's signature: Django should be "technically correct --
the best kind of correct." Apart from being an overall improvement in
correctness, see the problem reports at http://code.djangoproject.com/ticket/8193#comment:12
this would address. I'll update the patch shortly.

Additionally, some bits from the already semi-fixed
http://code.djangoproject.com/ticket/8882 that initially started this
thread have been shifted to http://code.djangoproject.com/ticket/9493
, which should also be integrated to close remaining inline formset
validation issues.

[Bob]

On Oct 31, 5:38 am, mrts <m...@mrts.pri.ee> wrote:
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?
>

I have patches on a few tickets that have been bothersome:

#9076 - Inline formsets without a default ordering and PostgreSQL
backend can return a strange error when saving. This is somewhat
related to #9006, though my patch avoids the problem of indexing into
an unordered queryset entirely. From the CC list and comments, this
has caused issues for quite a few people, though there is a
workaround.

#9308 - I originally re-opened #7778 because the fix for it
unintentionally caused problems with my legacy database (foreign keys
are not deferred). The new ticket describes the problem better, so I
moved my patch over and closed #7778 again. The fix is simple and does
not break the tests from #7778.

On a somewhat related note, is there some reason that 1.0.1 and 1.1
milestones have not been created in Trac? It seems like triaging bugs
into one of these releases should happen in Trac, not the mailing
list.

-bob

[Russell Keith-Magee]

On Tue, Nov 4, 2008 at 2:58 AM, Bob <robert....@gmail.com> wrote:

> On a somewhat related note, is there some reason that 1.0.1 and 1.1
> milestones have not been created in Trac? It seems like triaging bugs
> into one of these releases should happen in Trac, not the mailing
> list.

Yes, there is a reason, and it has been given several times in recent
history. The v1.0.1 milestone has not bee created in Trac because it
will not in any way help us deliver the v1.0.1 release. There is no
difference between the "list of all bugs' and the "list of bugs that
we want to close for v1.0.1". We may not be successful in meeting this
goal, but that doesn't change the underlying goal.

In understand that twiddling milestone flags on tickets apparently
gives some people the warm, satisfying feeling that they are helping.
However, speaking as one of the core developers, it would be much more
helpful for that effort to be directed towards actually triaging new
tickets (validating that a bug exists, finding duplicates, correctly
classifying tickets etc), writing patches, and testing those patches.
These are the jobs that are hard to do, and aren't assisted by having
a new milestone flag to fiddle with in Trac.

The 1.1 milestone doesn't exist because we haven't decided what will
be in v1.1 yet. Once the discussion period is over (in a week or so),
the milestone will be opened, and tickets will be assigned.

Yours,
Russ Magee %-)

[mrts]

On Nov 4, 2:33 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

> Yes, there is a reason, and it has been given several times in recent
> history. The v1.0.1 milestone has not bee created in Trac because it
> will not in any way help us deliver the v1.0.1 release. There is no
> difference between the "list of all bugs' and the "list of bugs that
> we want to close for v1.0.1". We may not be successful in meeting this
> goal, but that doesn't change the underlying goal.
>
> In understand that twiddling milestone flags on tickets apparently
> gives some people the warm, satisfying feeling that they are helping.
> However, speaking as one of the core developers, it would be much more
> helpful for that effort to be directed towards actually triaging new
> tickets (validating that a bug exists, finding duplicates, correctly
> classifying tickets etc), writing patches, and testing those patches.
> These are the jobs that are hard to do, and aren't assisted by having
> a new milestone flag to fiddle with in Trac.

Except that most of the tickets that have been brought up in this
discussion already have patches, they just don't get the needed
attention from core devs. Which is of course understandable as Django
is a volunteer project. But the goal of fixing *all* bugs for 1.0.1 is
not realistic for exactly that reason, which is exemplified in
timeline (look at check-ins) -- apart from brosner's good work on
fixing the formset unique foreign key issues, there are only doc,
translation and CSS fixes in last 7 days. In last month, same pattern:
very few core and a lot of doc fixes. (Note that I'm not blaming
anyone here, it's quite understandable that devs are busy outside
Django -- it's just not fair to slap people with the standard "just
contribute patches to all bugs" answer in this light, especially if
they have already done so for bugs that they care for.)

Most other projects are managed by a priority queue and clear target
set for releases ("this has to go into 1.0.1, this can wait until
1.0.2"). No problem if discussions on the mailing list are the
preferred way of doing it instead of Trac tools -- until things really
get done.

[James Bennett]

On Tue, Nov 4, 2008 at 8:04 AM, mrts <mr...@mrts.pri.ee> wrote:
> Except that most of the tickets that have been brought up in this
> discussion already have patches, they just don't get the needed
> attention from core devs.

And if you feel that's the case, by all means bring them up. But there
isn't any special bit in Trac to set for it, and there's really no
great need for such a thing. So let it go, OK?

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Russell Keith-Magee]

On Tue, Nov 4, 2008 at 11:04 PM, mrts <mr...@mrts.pri.ee> wrote:
>
> Most other projects are managed by a priority queue and clear target
> set for releases ("this has to go into 1.0.1, this can wait until
> 1.0.2"). No problem if discussions on the mailing list are the
> preferred way of doing it instead of Trac tools -- until things really
> get done.

"Most other projects" is an ad hominem, so I won't respond to that.

Let me lay out the alternatives to you. Let us assume that we have a
milestone, and tickets get assigned to it:

Option 1: We don't release until all tickets on the milestone are complete.

Option 2: We release on a date, with as many bug fixes as we can manage.

I can guarantee you that Option 1 will result in a release that is
later than expected, for any value of "expected". The amount of time
available for development to the core team is not a constant, nor is
it particularly predictable. We (the core developers) wore a lot of
flack for waiting too long between 0.96 and 1.0. If we end up delaying
v1.0.1 so we can meet a milestone list, mark my words - there will be
a cry of "Why not just release a v1.0.0.1 with the interim fixes".

Option 2 gives us timely releases, each of which is better than the
last (i.e., less bugs). However, this doesn't require a milestone tag
- all bugs are targets, and the general level of noise on the mailing
list helps to prioritize the bugs that require immediate attention.
For example, the inline problems you mentioned, and the URL reversal
problems that were resolved early in the v1.0.X process were both
significant bugs. The decision to fix these was made without the need
for a milestone tag.

Yes - we set a milestone for v1.0, but that is a bad example of how
(and why) milestones work. The fact that a milestone worked for the
version 1.0 release is due to two extraordinary factors:

1) The mystique surrounding Version One ensured more attention than
normal from the core developers

2) Malcolm and Jacob just about killed themselves in the last few
weeks with the amount of effort they put in to make sure the 1.0
milestone list was complete.

I wouldn't base any planning process on the assumption that either of
these are guaranteed to happen again.

On top of that, we (the core developers) committed ourself to
backwards compatibility at the v1.0 release, and we had a lot of
little things that needed to be cleaned up before we made that
commitment. A milestone is a very convenient way to keep track of the
subset of issues that stood in the way of that goal.

Post v1.0, our only goal is "zarro boogs", delivered on a timely
schedule - again, we don't need milestones to keep track of this goal,
because every open ticket is a target. What we _do_ need is a
community that works on triage and bug fixes, and draws the attention
of the core devs to particularly annoying or confusing bugs.

Yours,
Russ Magee %-)

[mrts]

On Nov 5, 1:35 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

> On Tue, Nov 4, 2008 at 11:04 PM, mrts <m...@mrts.pri.ee> wrote:
>
> > Most other projects are managed by a priority queue and clear target
> > set for releases ("this has to go into 1.0.1, this can wait until
> > 1.0.2"). No problem if discussions on the mailing list are the
> > preferred way of doing it instead of Trac tools -- until things really
> > get done.
>
> "Most other projects" is an ad hominem, so I won't respond to that.

Yeah, that was imprecise and overgeneralized, sorry for that. I had
mainly Python and Debian/Ubuntu in mind, but I believe Gnome and
Firefox have a similar workflow. Python has release blockers (that may
become deferred blockers), Ubuntu and Debian have critical bugs that
are usually fixed before a release. There is a general sense of what
is important and what not in the bug database.

> Let me lay out the alternatives to you. Let us assume that we have a
> milestone, and tickets get assigned to it:
>
> Option 1: We don't release until all tickets on the milestone are complete.

Tickets in a milestone are prioritized. We don't release until all
_critical_ bugs on the milestone are fixed as other projects listed
above do. Final decision on whether something is critical or not is
made by core devs. There is a set timeline with a bit of flex to cater
for delays in getting critical fixes in. Even before minor releases
there is a string freeze so that translators have a known point in
time for contributing translations.

Mailing list discussions are good, but in an ideal world they would be
complemented by a severity tag in Trac to communicate priorities and a
classifier tag to separate bugs and features.

> Post v1.0, our only goal is "zarro boogs", delivered on a timely
> schedule - again, we don't need milestones to keep track of this goal,
> because every open ticket is a target. What we _do_ need is a
> community that works on triage and bug fixes, and draws the attention
> of the core devs to particularly annoying or confusing bugs.

You have that community. 712 out of 1249 open tickets have patches, I
personally usually write a patch if something disturbs me. But as of
now the list is just an unordered soup of trivial fixes, "I want a
pony" and larger issues. I really doubt anyone has a general overview
of all of it. I myself feel apprehensive at the bug mass -- how do I
know that I will not hit into something important hidden there, but
wading through the list to pick important bits apart from feature
requests is quite an effort.

All in all, I like Django itself a lot. The code and conceptual
structure is mostly a pleasure to look at, you all have done an
excellent job and deserve a lot of respect. So in no way do I want to
say that things are bad as they are. But the defensive attitude and
constant fighting (that has gone on for years) on the same issues has
caused a lot of bitterness (e.g. google django hate: a whopping
426,000 results, hopefully no more than a couple of first pages are
relevant *chuckle*) -- the main issue being that people do contribute
but they don't see it going anywhere. This is where Trac helps a
little by a) milestones: assuring that there is a known date when a
given ticket will be looked at b) priorities: assuring that when I
report something important it will not get buried under a ton of "I
want a pony" requests, also for effectively finding bits that need
attention and may disturb project development. A good process does not
work against people and even tries to take their psychology into
account, no?

Maybe I'm too outspoken as James suggests and I see some value in the
mailing list process, it is just that Trac would support it.

Over and out on this theme until it pops up again,
MS

[mrts]

On Nov 5, 2:31 pm, mrts <m...@mrts.pri.ee> wrote:
> little by a) milestones: assuring that there is a known date when a
> given ticket will be looked at

Let me clarify a little: "looked at" doesn't necessarily mean
"integrated", it may be deferred to the next or a future milestone,
i.e. it does not mean that core devs are somehow forced to give more
input to the project.

[Daniel Roseman]

Sorry to bring this discussion back to the original topic...

http://code.djangoproject.com/ticket/9498 is a pretty serious
regression for us, which will prevent us upgrading to 1.0.1. There is
a patch, and I've just added some tests - is there any chance this
will make it into the release?

Thanks,
DR.

[Brian Rosner]

Notice how I have not only marked the issue accepted, but I assigned
it to myself. I would think that is a decent indication that this is a
serious issue considering things are broken and that it will make the
release :)

--
Brian Rosner
http://oebfare.com