Re: 1.0.1 release blockers?
On Tue, Nov 4, 2008 at 11:04 PM, mrts <[EMAIL PROTECTED]> 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 %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: 1.0.1 release blockers?
On Tue, Nov 4, 2008 at 8:04 AM, mrts <[EMAIL PROTECTED]> 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." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket 9483
Hey Karen, Thanks for your fast reply. Well, I searched around and it seems that a lot of people aren't too happy with Python's default title() functionality. ( http://muffinresearch.co.uk/archives/2008/05/27/titlecasepy-titlecase-in-python/ ) >From a publishing point of view, I don't know for sure Python's method is correct. Personally, I don't think so. It is logical to put a capitalized letter after a semicolon, but that's certainly not the case if it's in a word ( Like Foo;bar, from my example ). > 1 - the existing behavior mirrors Python so is unsurprising in a > Python-based framework Ok, but then you would to actually change the documentation accordingly. It now states that it converts a string to title case and what Python title method does is not what it "should" do. ( I already discussed that ). > 2 - changing it at this point is backwards-incompatible True, maybe put this patch to 2.0? > 3 - you can easily write your own filter to title case in whatever manner > you want That's also true, but you can almost override any component that is in Django, thus saying this sounds like "Yeah, you can override everything anyway." So, in conclusion, I think this should be put into 2.0, under the condition that we can confirm Python's title method isn't publishing- friendly. We need someone in publishing to back us up on this one. Another solution would be to change the documentation, because what we do now probably isn't "proper" title casing. Greets, Henk. On 4 nov, 14:44, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > On Tue, Nov 4, 2008 at 8:08 AM, H. de Vries <[EMAIL PROTECTED]> wrote: > > > > > > > Hey all, > > > I pretty new to developing for Django itself and for that reason I > > have question. > > > 4 days ago I submitted a bug and I wrote a patch and tests for it. I > > noticed through the timeline that there are people that review > > tickets. > > > Problem is, I haven't had any response on my ticket yet. How long does > > it usually take for someone to review a ticket that has a patch and > > tests? > > > I know in open source projects things can sometimes take a while. It > > would awesome if my patch would make it into 1.0.X ( if that isn't too > > late, I just read on the blog today about the beta and the 1.0.X > > branch ). > > > This is the ticket I'm talking about: > >http://code.djangoproject.com/ticket/9483 > > Four days is not very long. I personally have not responded on that ticket > because I have no background in publishing or editing to know what the > correct behavior is for converting to "title case". You assert that the > current behavior is wrong, but to me it actually looks correct; I was hoping > someone connected to publishing with more of a clue in this area than I > would chime in, but four days has not been long enough for any such > qualified people to have the time. > > Regardless of what is technically correct for title casing, I'd be leery of > changing the existing title filter at this point. It seems like there may > be people using it who expect the current behavior, and to suddenly change > the behavior would be backwards-incompatible for them. So my inclination > would be to close that ticket as wontfix based on the fact that: > > 1 - the existing behavior mirrors Python so is unsurprising in a > Python-based framework > 2 - changing it at this point is backwards-incompatible > 3 - you can easily write your own filter to title case in whatever manner > you want > > But like I said I don't know what is technically "correct" for title casing, > so if what you are proposing is the generally accepted way than perhaps > there is a case to be made for including in Django a filter that does casing > that way. > > Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.0.1 release blockers?
On Nov 4, 2:33 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
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.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Ticket 9483
On Tue, Nov 4, 2008 at 8:08 AM, H. de Vries <[EMAIL PROTECTED]> wrote: > > Hey all, > > I pretty new to developing for Django itself and for that reason I > have question. > > 4 days ago I submitted a bug and I wrote a patch and tests for it. I > noticed through the timeline that there are people that review > tickets. > > Problem is, I haven't had any response on my ticket yet. How long does > it usually take for someone to review a ticket that has a patch and > tests? > > I know in open source projects things can sometimes take a while. It > would awesome if my patch would make it into 1.0.X ( if that isn't too > late, I just read on the blog today about the beta and the 1.0.X > branch ). > > This is the ticket I'm talking about: > http://code.djangoproject.com/ticket/9483 > > Four days is not very long. I personally have not responded on that ticket because I have no background in publishing or editing to know what the correct behavior is for converting to "title case". You assert that the current behavior is wrong, but to me it actually looks correct; I was hoping someone connected to publishing with more of a clue in this area than I would chime in, but four days has not been long enough for any such qualified people to have the time. Regardless of what is technically correct for title casing, I'd be leery of changing the existing title filter at this point. It seems like there may be people using it who expect the current behavior, and to suddenly change the behavior would be backwards-incompatible for them. So my inclination would be to close that ticket as wontfix based on the fact that: 1 - the existing behavior mirrors Python so is unsurprising in a Python-based framework 2 - changing it at this point is backwards-incompatible 3 - you can easily write your own filter to title case in whatever manner you want But like I said I don't know what is technically "correct" for title casing, so if what you are proposing is the generally accepted way than perhaps there is a case to be made for including in Django a filter that does casing that way. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ticket 9483
Hey all, I pretty new to developing for Django itself and for that reason I have question. 4 days ago I submitted a bug and I wrote a patch and tests for it. I noticed through the timeline that there are people that review tickets. Problem is, I haven't had any response on my ticket yet. How long does it usually take for someone to review a ticket that has a patch and tests? I know in open source projects things can sometimes take a while. It would awesome if my patch would make it into 1.0.X ( if that isn't too late, I just read on the blog today about the beta and the 1.0.X branch ). This is the ticket I'm talking about: http://code.djangoproject.com/ticket/9483 Thanks, Henk. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 beta available
it is actually only the space in the version in setup.py, here is a
diff to current trunk that would use an underscore instead
Index: setup.py
===
--- setup.py(revision 9333)
+++ setup.py(working copy)
@@ -68,7 +68,7 @@
# Dynamically calculate the version based on django.VERSION.
version = __import__('django').get_version()
if u'SVN' in version:
-version = ' '.join(version.split(' ')[:-1])
+version = '_'.join(version.split(' ')[:-1])
setup(
name = "Django",
i don't know what the versioning spec is for django so it is hard for
me to tell if this is ok, but it produces a file without spaces when
doing for example python setup.py sdist it genereates Django-1.1_pre-
alpha.tar.gz for the current trunk which should be ok on pypy.
On Nov 3, 10:31 pm, Ian Holsman <[EMAIL PROTECTED]> wrote:
> James Bennett wrote:
> > See the weblog entry:
>
> >http://www.djangoproject.com/weblog/2008/oct/31/101-beta/
>
> > And the downloads page:
>
> >http://www.djangoproject.com/download/
>
> > As previously mentioned, this is mainly a preview to let people get a
> > feel for what's been fixed/improved in the 1.0.X line since the 1.0
> > release, and a reminder to anyone who's interested in helping to fix
> > an issue in the 1.0.X codebase that time is running short leading up
> > to the 1.0.1 release :)
>
> do you have a list of fixes/changes available?
> or a URL to hit to get this? it will make people's lives a bit easier if
> they want to focus on testing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
