Should Django have a road map?

[Stefan Matthias Aust]

Over the last few weeks, we used Django to successfully create
prototype applications and it just worked great (well, large file
upload is broken, I had to patch our Django version with #2070 a
couple of times). What a relieve compared to Java web development! A
big "thank you" to all developers and this friendly user group.

However, to sell Django to my management for "real" applications, it
would be very helpful to have some kind of road map. We miss the
structure and guidance ;)

I'll try to explain my feelings:

There's no 0.97 version despites all that changes to SVN trunk for
months. The documentation clearly advertises the current trunk
version, but the book refers to 0.96. The django book project seems to
have died in Feb. The site does not explain why the missing chapters
where never written/published and what the current state is.
(Important) changes to the queryset API or admin UI are not applied in
favor to some branched development which seems to be ongoing for
months. No word on when it will hit the trunk. No word on when the
next Django version will be published. Or what it will contain. Bugs
like #2070 are open for more than a year. Of ~800 open tickets, 275
need a design decision, that is need the attention of the core team.
There are still 12 tickets from the last sprint (great effort, BTW)
left to check-in. The casual observer easily gets the impression that
work is sporadic, uncoordinated and not target-oriented, in one word:
chaotic.

While this is no problem in it self (and please do not feel offended,
that's not my intention), it makes it difficult to build products upon
that foundation. Is it useful to invest in the old admin UI? Or should
we go for the new one? When will the query API be improved (we need
aggregations, so I have to patch it)? Will there every be schema
evolution?

A lot of open source projects switched to a time boxed release scheme
because that builds the most trust with users. If the Eclipse
foundation (for example) publishes its mile stone road map you can be
sure they will meet the date and release on time. IMHO one of the (not
so secret) secrets of their enormous success.

The counter-example is the trac project which tells everybody that
they're now 3 months late with 0.11 and even have missed the next
milestone, too. This tells everybody "hey, we're not able to implement
a realistic schedule and are not even able to update our web page
after we learned that" ;)

So, I'd recommend to create a realistic road map. Release every two or
three months. 0.96 or 0.97 communicates that it's almost done. That's
obviously not the case. Just increment a single number. Tell your
users when they can expect larger refactorings. If the problem is lack
of time, try to find sponsors. The current "it's done when it's done"
state of mind makes it difficult to invest in something we do not know
whether, when and how it will evolve.

Should I manage to convince my management to continue using Django, I
should be able to dedicate one day per month to community work. That's
what I can offer in return to using the framework.

[As a side note: I actually have to defend Python/Django against Ruby
on Rails because that's the "nextgen agil" framework even the
management heard about and, frankly, it feels much more mature. This
is another reason I'd like to have something more concrete than
Django's ticket system. I originally picked Django because teaching
and learning Python was much easier than teaching Ruby and the magic
of Rails.]

One idea I was playing around in my mind was to create some kind of
"Django distribution", snapshotting the SVN version every month or so,
perhaps adding a few useful 3rd party libraries and creating a ready
to use and easily installable milestone version. That would be useful
for others too, I hope, but I do not want to fork or split the
development. However, I need some patches applied for our own work
faster than in the official version.

I'd like to know whether others feel the same and would like to see
(and discuss) a focused road map or whether it's just me who cannot
appreciate the creativity of chaos ;)

Thanks for reading my ramblings...

[Jon Atkinson]

There are some interesting points here, I look forward to the replies.

--Jon

Post by Stefan Matthias Aust
Over the last few weeks, we used Django to successfully create
prototype applications and it just worked great (well, large file
upload is broken, I had to patch our Django version with #2070 a
couple of times). What a relieve compared to Java web development! A
big "thank you" to all developers and this friendly user group.
However, to sell Django to my management for "real" applications, it
would be very helpful to have some kind of road map. We miss the
structure and guidance ;)
There's no 0.97 version despites all that changes to SVN trunk for
months. The documentation clearly advertises the current trunk
version, but the book refers to 0.96. The django book project seems to
have died in Feb. The site does not explain why the missing chapters
where never written/published and what the current state is.
(Important) changes to the queryset API or admin UI are not applied in
favor to some branched development which seems to be ongoing for
months. No word on when it will hit the trunk. No word on when the
next Django version will be published. Or what it will contain. Bugs
like #2070 are open for more than a year. Of ~800 open tickets, 275
need a design decision, that is need the attention of the core team.
There are still 12 tickets from the last sprint (great effort, BTW)
left to check-in. The casual observer easily gets the impression that
chaotic.
While this is no problem in it self (and please do not feel offended,
that's not my intention), it makes it difficult to build products upon
that foundation. Is it useful to invest in the old admin UI? Or should
we go for the new one? When will the query API be improved (we need
aggregations, so I have to patch it)? Will there every be schema
evolution?
A lot of open source projects switched to a time boxed release scheme
because that builds the most trust with users. If the Eclipse
foundation (for example) publishes its mile stone road map you can be
sure they will meet the date and release on time. IMHO one of the (not
so secret) secrets of their enormous success.
The counter-example is the trac project which tells everybody that
they're now 3 months late with 0.11 and even have missed the next
milestone, too. This tells everybody "hey, we're not able to implement
a realistic schedule and are not even able to update our web page
after we learned that" ;)
So, I'd recommend to create a realistic road map. Release every two or
three months. 0.96 or 0.97 communicates that it's almost done. That's
obviously not the case. Just increment a single number. Tell your
users when they can expect larger refactorings. If the problem is lack
of time, try to find sponsors. The current "it's done when it's done"
state of mind makes it difficult to invest in something we do not know
whether, when and how it will evolve.
Should I manage to convince my management to continue using Django, I
should be able to dedicate one day per month to community work. That's
what I can offer in return to using the framework.
[As a side note: I actually have to defend Python/Django against Ruby
on Rails because that's the "nextgen agil" framework even the
management heard about and, frankly, it feels much more mature. This
is another reason I'd like to have something more concrete than
Django's ticket system. I originally picked Django because teaching
and learning Python was much easier than teaching Ruby and the magic
of Rails.]
One idea I was playing around in my mind was to create some kind of
"Django distribution", snapshotting the SVN version every month or so,
perhaps adding a few useful 3rd party libraries and creating a ready
to use and easily installable milestone version. That would be useful
for others too, I hope, but I do not want to fork or split the
development. However, I need some patches applied for our own work
faster than in the official version.
I'd like to know whether others feel the same and would like to see
(and discuss) a focused road map or whether it's just me who cannot
appreciate the creativity of chaos ;)
Thanks for reading my ramblings...
--
Stefan Matthias Aust

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ramdas S]

Interesting observations.

I like the idea of a road map. But we do not have any full time people
working on Django. May be we can look at incrementing the version by
0.01every 500 SVN commits or so.

RS

Post by Stefan Matthias Aust
Over the last few weeks, we used Django to successfully create
prototype applications and it just worked great (well, large file
upload is broken, I had to patch our Django version with #2070 a
couple of times). What a relieve compared to Java web development! A
big "thank you" to all developers and this friendly user group.
However, to sell Django to my management for "real" applications, it
would be very helpful to have some kind of road map. We miss the
structure and guidance ;)
There's no 0.97 version despites all that changes to SVN trunk for
months. The documentation clearly advertises the current trunk
version, but the book refers to 0.96. The django book project seems to
have died in Feb. The site does not explain why the missing chapters
where never written/published and what the current state is.
(Important) changes to the queryset API or admin UI are not applied in
favor to some branched development which seems to be ongoing for
months. No word on when it will hit the trunk. No word on when the
next Django version will be published. Or what it will contain. Bugs
like #2070 are open for more than a year. Of ~800 open tickets, 275
need a design decision, that is need the attention of the core team.
There are still 12 tickets from the last sprint (great effort, BTW)
left to check-in. The casual observer easily gets the impression that
chaotic.
While this is no problem in it self (and please do not feel offended,
that's not my intention), it makes it difficult to build products upon
that foundation. Is it useful to invest in the old admin UI? Or should
we go for the new one? When will the query API be improved (we need
aggregations, so I have to patch it)? Will there every be schema
evolution?
A lot of open source projects switched to a time boxed release scheme
because that builds the most trust with users. If the Eclipse
foundation (for example) publishes its mile stone road map you can be
sure they will meet the date and release on time. IMHO one of the (not
so secret) secrets of their enormous success.
The counter-example is the trac project which tells everybody that
they're now 3 months late with 0.11 and even have missed the next
milestone, too. This tells everybody "hey, we're not able to implement
a realistic schedule and are not even able to update our web page
after we learned that" ;)
So, I'd recommend to create a realistic road map. Release every two or
three months. 0.96 or 0.97 communicates that it's almost done. That's
obviously not the case. Just increment a single number. Tell your
users when they can expect larger refactorings. If the problem is lack
of time, try to find sponsors. The current "it's done when it's done"
state of mind makes it difficult to invest in something we do not know
whether, when and how it will evolve.
Should I manage to convince my management to continue using Django, I
should be able to dedicate one day per month to community work. That's
what I can offer in return to using the framework.
[As a side note: I actually have to defend Python/Django against Ruby
on Rails because that's the "nextgen agil" framework even the
management heard about and, frankly, it feels much more mature. This
is another reason I'd like to have something more concrete than
Django's ticket system. I originally picked Django because teaching
and learning Python was much easier than teaching Ruby and the magic
of Rails.]
One idea I was playing around in my mind was to create some kind of
"Django distribution", snapshotting the SVN version every month or so,
perhaps adding a few useful 3rd party libraries and creating a ready
to use and easily installable milestone version. That would be useful
for others too, I hope, but I do not want to fork or split the
development. However, I need some patches applied for our own work
faster than in the official version.
I'd like to know whether others feel the same and would like to see
(and discuss) a focused road map or whether it's just me who cannot
appreciate the creativity of chaos ;)
Thanks for reading my ramblings...
--
Stefan Matthias Aust

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[cschand]

Stefan's observations have very interesting points. I am also looking
forwad to replies

cschand


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

Post by Stefan Matthias Aust
There's no 0.97 version despites all that changes to SVN trunk for
months.

Because we're not ready for a 0.97 release. The goals for the next
release and the general run up to Django 1.0 are pretty well-known,
even if they're not meticulously tracked with timers counting down,
and no amount of "road map" documentation will get them done any
faster.

Post by Stefan Matthias Aust
The documentation clearly advertises the current trunk
version, but the book refers to 0.96. The django book project seems to
have died in Feb. The site does not explain why the missing chapters
where never written/published and what the current state is.

The book isn't dead, and I'll leave further explanation to a search of
the mailing-list archive.

Post by Stefan Matthias Aust
(Important) changes to the queryset API or admin UI are not applied in
favor to some branched development which seems to be ongoing for
months.

Generally, the Django team works to keep trunk as stable as possible;
this means that large, destabilizing features get done in branches and
then merge back in. By their nature, and by the nature of open-source
development, it sometimes takes a while for this process to be
completed.

Post by Stefan Matthias Aust
No word on when it will hit the trunk. No word on when the
next Django version will be published.

I'll pause for a moment here and step out of responding as a Django
user, and step into responding as Django's release manager: the answer
is "when it's ready". If you have a foolproof way of figuring out when
that will be, you should stop writing code and start making millions
of dollars selling your secret to businesses which develop software.

Post by Stefan Matthias Aust
Or what it will contain. Bugs like #2070 are open for more than a year.

Yes, but with fairly constant activity. That one is a much harder
issue than it appears to be at first glance, as some of the folks
who've said "oh, this'll be simple" and started to work on it will
tell you.

Post by Stefan Matthias Aust
Of ~800 open tickets, 275 need a design decision, that is need the attention of
the core team.

Yup. Personally, I look at "design decision needed" as meaning "if
nobody makes a compelling argument for it, I'll come along and close
it eventually". And that's essentially what happens: if a ticket sits
at that stage for a long period of time with nobody coming forward and
making a case for it, it's probably not something that's worth doing.

Post by Stefan Matthias Aust
There are still 12 tickets from the last sprint (great effort, BTW)
left to check-in. The casual observer easily gets the impression that
chaotic.

And this is compared to the normal process of software development,
which is constant, rigidly-coordinated, always on-target and
well-ordered? ;)

Post by Stefan Matthias Aust
While this is no problem in it self (and please do not feel offended,
that's not my intention), it makes it difficult to build products upon
that foundation. Is it useful to invest in the old admin UI? Or should
we go for the new one? When will the query API be improved (we need
aggregations, so I have to patch it)? Will there every be schema
evolution?

1. If you intend to commit to running on a particular version of Django, yes.
2. When it's done.
3. There already is, it's called ALTER TABLE. If you mean automagic
deduction of changes, probably not. If you mean some non-SQL syntax
that's nonetheless equivalent, well, lots of people seem to want it
but so far only Derek and a couple of others have put their code where
their mouths are.

Post by Stefan Matthias Aust
A lot of open source projects switched to a time boxed release scheme
because that builds the most trust with users. If the Eclipse
foundation (for example) publishes its mile stone road map you can be
sure they will meet the date and release on time. IMHO one of the (not
so secret) secrets of their enormous success.

Eclipse is also in receipt of very generous funding from large
corporate sponsors. Who wants to lay odds on whether that has a larger
or smaller impact on their success than having a timeline document?

Post by Stefan Matthias Aust
The counter-example is the trac project which tells everybody that
they're now 3 months late with 0.11 and even have missed the next
milestone, too. This tells everybody "hey, we're not able to implement
a realistic schedule and are not even able to update our web page
after we learned that" ;)

Continuing with the theme: how much funding does Trac get from Fortune
500 companies?

Post by Stefan Matthias Aust
So, I'd recommend to create a realistic road map. Release every two or
three months. 0.96 or 0.97 communicates that it's almost done. That's
obviously not the case. Just increment a single number. Tell your
users when they can expect larger refactorings. If the problem is lack
of time, try to find sponsors. The current "it's done when it's done"
state of mind makes it difficult to invest in something we do not know
whether, when and how it will evolve.

"It's done when it's done" is all I can give you. "It's done even
though it's not" wouldn't make any sense, and neither would automatic
releases; I'll take quality over quantity any day of the week, and
"released later, but finished" over "released now, but doesn't work".

Post by Stefan Matthias Aust
One idea I was playing around in my mind was to create some kind of
"Django distribution", snapshotting the SVN version every month or so,
perhaps adding a few useful 3rd party libraries and creating a ready
to use and easily installable milestone version. That would be useful
for others too, I hope, but I do not want to fork or split the
development. However, I need some patches applied for our own work
faster than in the official version.

Some Linux distributions already package from Django's trunk on a
semi-regular basis; you might want to look into their offerings.

Post by Stefan Matthias Aust
I'd like to know whether others feel the same and would like to see
(and discuss) a focused road map or whether it's just me who cannot
appreciate the creativity of chaos ;)

Personally, I look on timelines and roadmaps as lies dressed up in
fancy clothing. When Fred Brooks wrote his famous book on software
management, nobody really had a handle on how to plan or schedule
software projects. Thirty-two years later, nobody really has a handle
on how to plan or schedule software projects.

Throw in the nature of an open source project like Django -- where
everyone is a volunteer working in their own personal time -- and it
becomes impossible to lay down schedules, timelines or roadmaps with
any sort of accuracy. They'd be fictions concocted for the sake of
soothing middle managers, and that's not a business I'd want to get
into.

That said, there's a very easy way to get a handle on Django's
development: watch the timeline and read the developers' mailing list.
Both of them are open to the public, both have more than enough
information to let you gauge where things stand and where they're
going. There are also several pages on the wiki explaining goals of
particular branches/changes, and some developers have even been known
to make their to-do lists publicly viewable.

Beyond that I don't think there's much we can do at the moment; Django
is entirely a volunteer effort and the developers -- correctly, I'd
say -- focus their time on getting things done rather than writing up
timelines and checklists of what they're going to do.

[Jon Atkinson]

Post by James Bennett

Post by Stefan Matthias Aust

Post by Stefan Matthias Aust
The documentation clearly advertises the current trunk

version, but the book refers to 0.96. The django book project seems to
have died in Feb. The site does not explain why the missing chapters
where never written/published and what the current state is.

The book isn't dead, and I'll leave further explanation to a search of
the mailing-list archive.

I think that searching the mailing list archives is missing the point.
Putting a statement on the index page of djangobook.com saying "No,
this isn't finished yet, we're still working on it", along with a
relatively recent date, would at least let people know that the book
hasn't been forgotten about, and would hopefully alleviate a lot of
redundant mailing list messages.

--Jon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Stefan Matthias Aust]

James,

thanks for your details answer. Let me put it right here: I'm not
complaining about the lack of dedication or progress in the
development of Django. It's more about visibility and marketing.

Post by James Bennett

Post by Stefan Matthias Aust
There's no 0.97 version despites all that changes to SVN trunk for
months.

Because we're not ready for a 0.97 release. The goals for the next
release and the general run up to Django 1.0 are pretty well-known,
even if they're not meticulously tracked with timers counting down,
and no amount of "road map" documentation will get them done any
faster.

It might be very obvious to you what is missing before 0.97 can be
released because you're deeply involved with the development and
exactly know it. However, I cannot easily find the answer on the web
site. Searching the mailing archive shouldn't be the only way to get
such kind of information - if that would answer the question at all.

Actually, I'm trying to follow the users mailing list for a couple of
weeks now (and I'm overwhelmed with information so I have to skip most
of the stuff) and couldn't answer the question what is planned for
0.97.

Post by James Bennett
The book isn't dead, and I'll leave further explanation to a search of
the mailing-list archive.

This is what I heard on this list, however I raised that issue because
it was the first question I was asked after my manager browsed a
little bit, found the book, noticed the dates and came to the
conclusion that if nothing changed since Jannuary, something ought to
be wrong.

Post by James Bennett
Generally, the Django team works to keep trunk as stable as possible;
this means that large, destabilizing features get done in branches and
then merge back in. By their nature, and by the nature of open-source
development, it sometimes takes a while for this process to be
completed.

Well, open source development is (or at least shouldn't be) not that
different to closed source development. When hacking something, you
should have an idea on what to achieve and when to achieve it or at
least for the progress towards the goal. Document that progress and do
not make it a secret. That is what I ask for.

Post by James Bennett
I'll pause for a moment here and step out of responding as a Django
user, and step into responding as Django's release manager: the answer
is "when it's ready". If you have a foolproof way of figuring out when
that will be, you should stop writing code and start making millions
of dollars selling your secret to businesses which develop software.

As a software developer my self, I can understand the "when it's
ready" mantra, but IMHO that's not an acceptable answer. I mentioned
the Eclipse project and how they managed to setup an trustworthy
release process. Not only IMHO, time based releases are better than
feature driven once, see for example
http://video.google.de/videoplay?docid=-5503858974016723264

Post by James Bennett

Post by Stefan Matthias Aust
Or what it will contain. Bugs like #2070 are open for more than a year.

Yes, but with fairly constant activity. That one is a much harder
issue than it appears to be at first glance, as some of the folks
who've said "oh, this'll be simple" and started to work on it will
tell you.

Well, the provided patch seems to work just fine. I understand that
something like this must be carefully applied because it might break a
lot of applications if done wrong because nearly everybody works on
the SVN trunk. However, if there were more stable releases, not
everybody would probably work on trunk and you could be more
riskaccepting, having on the other hand more people to check out the
code, getting quicker to a stable code base. (In theory, this sound so
easy, in practice, it's of course more difficult ;)

Post by James Bennett

Post by Stefan Matthias Aust
Of ~800 open tickets, 275 need a design decision, that is need the attention of
the core team.

Yup. Personally, I look at "design decision needed" as meaning "if
nobody makes a compelling argument for it, I'll come along and close
it eventually". And that's essentially what happens: if a ticket sits
at that stage for a long period of time with nobody coming forward and
making a case for it, it's probably not something that's worth doing.

Well, do the people who write those tickets know that they are
supposed to "defend" their tickets at the "developers court"? :) Right
now, it seems they are stalled. Would it help to distinguish bugs and
feature requests?

Post by James Bennett

Post by Stefan Matthias Aust
The casual observer easily gets the impression that
chaotic.

And this is compared to the normal process of software development,
which is constant, rigidly-coordinated, always on-target and
well-ordered? ;)

In an Morcoockish world view, neither true order or perfect chaos are
good :) If we assume, that a typical (open source) developer is a
worshiper of chaos, management is a faithful believer in the order.
I'm just striving for some balance here...

Post by James Bennett

Post by Stefan Matthias Aust
Will there every be schema evolution?

3. There already is, it's called ALTER TABLE. If you mean automagic
deduction of changes, probably not. If you mean some non-SQL syntax
that's nonetheless equivalent, well, lots of people seem to want it
but so far only Derek and a couple of others have put their code where
their mouths are.

Unfortune IMHO, because migrations and semi-automatic deployment
(capistrano or how it's called) are compelling reasons for Rails. I
saw that there's a new project split from the Django SVN at
http://code.google.com/p/deseb/ which I bookmarked for further study.
Is this the one by the Derek you mentioned?

Post by James Bennett
Eclipse is also in receipt of very generous funding from large
corporate sponsors. Who wants to lay odds on whether that has a larger
or smaller impact on their success than having a timeline document?

Their success of course does not original from a single timeline
document, but being reliable certainly helps to attract corporations.

Post by James Bennett
Continuing with the theme: how much funding does Trac get from Fortune
500 companies?

The question should be: What should Trac do to get more attention and
therefore eventually funding. IMHO it's one of the nicest web based
issues trackers and project management solutions out there. It has a
clean and easy to use UI, although installation is too difficult for
my taste. It definitely deserves more attention. However, such
attention can be easily lost by avoidable bad self-marketing.

Post by James Bennett
Some Linux distributions already package from Django's trunk on a
semi-regular basis; you might want to look into their offerings.

It's not that I cannot check out SVN and re-submit it to our own VCS,
but it just feels unstable.

Post by James Bennett
Personally, I look on timelines and roadmaps as lies dressed up in
fancy clothing. When Fred Brooks wrote his famous book on software
management, nobody really had a handle on how to plan or schedule
software projects. Thirty-two years later, nobody really has a handle
on how to plan or schedule software projects.

I have a different opinion: A road map is a statement of intent, a
priorization of features and a commitment. Note, that I didn't say
time line. Saying, for example, that automagical schema evolution is
not part of the road map is for example an important information. This
helps to decide whether to invest into the framework or not. While I
really appreciate Fred Brooks book cause it contains a lot of truth,
it shouldn't be used as a "proof" that software projects cannot be
planned at all but as a guide line of what is realistic and doable.

Post by James Bennett
any sort of accuracy. They'd be fictions concocted for the sake of
soothing middle managers, and that's not a business I'd want to get
into.

This is what I can understand but on the other hand should it be of
interest to make Django a viable solution for more than developers who
like what they can now, no questions asked :)

Post by James Bennett
Beyond that I don't think there's much we can do at the moment; Django
is entirely a volunteer effort and the developers -- correctly, I'd
say -- focus their time on getting things done rather than writing up
timelines and checklists of what they're going to do.

While I agree that developer time should not be wasted and the
volunteer work should be highly respected, I do not believe that
nobody has a plan on what to do next. This plan has to be coordinated
and should follow the "Django vision" of what fits into the project
and what not. It is my impression that currently, this vision is
shared by the developers but it is not written down. A road map would
be a manifested vision (if that's a word)...

Regards,

[James Bennett]

Post by Stefan Matthias Aust
It might be very obvious to you what is missing before 0.97 can be
released because you're deeply involved with the development and
exactly know it. However, I cannot easily find the answer on the web
site. Searching the mailing archive shouldn't be the only way to get
such kind of information - if that would answer the question at all.

It isn't the only way, and I didn't claim it was.

Post by Stefan Matthias Aust
Well, open source development is (or at least shouldn't be) not that
different to closed source development. When hacking something, you
should have an idea on what to achieve and when to achieve it or at
least for the progress towards the goal. Document that progress and do
not make it a secret. That is what I ask for.

Not having copious documentation of everything the dev team is doing
isn't the same as "making it a secret" ;)

Again, the easy way to see what's going on is to watch the Trac
timeline and the dev list. That lets you see commits, wiki changes and
ongoing discussions of Django development.

Post by Stefan Matthias Aust
As a software developer my self, I can understand the "when it's
ready" mantra, but IMHO that's not an acceptable answer. I mentioned
the Eclipse project and how they managed to setup an trustworthy
release process. Not only IMHO, time based releases are better than
feature driven once, see for example
http://video.google.de/videoplay?docid=-5503858974016723264

We'll just have to agree to disagree. What happens if Eclipse is
coming up on a stated release date with a showstopping bug they can't
fix in time? Do they say "time-based releases are better" and push a
broken product? (rhetorical question)

Post by Stefan Matthias Aust
Well, the provided patch seems to work just fine. I understand that
something like this must be carefully applied because it might break a
lot of applications if done wrong because nearly everybody works on
the SVN trunk. However, if there were more stable releases, not
everybody would probably work on trunk and you could be more
riskaccepting, having on the other hand more people to check out the
code, getting quicker to a stable code base. (In theory, this sound so
easy, in practice, it's of course more difficult ;)

Regardless of release frequency, we have a history of all but actively
encouraging people to work from SVN checkouts; the rate of Django
development has been such that there's almost always an attractive
feature or two in trunk that's not in the latest release, and we'd
have to switch to a weekly or even daily release schedule to prevent
that.

Post by Stefan Matthias Aust
Well, do the people who write those tickets know that they are
supposed to "defend" their tickets at the "developers court"? :) Right
now, it seems they are stalled. Would it help to distinguish bugs and
feature requests?

It's not a "court". Either somebody gets discussion going on the
ticket and a decision is reached, or nobody does and it eventually
gets closed when it's clear that nobody's actively working on/for the
ticket. And this is pretty much par for the course with open-source
projects: if you file a "drive-by" ticket with any project and never
follow up on it again, odds are nobody else is going to do it for you.

Post by Stefan Matthias Aust
Unfortune IMHO, because migrations and semi-automatic deployment
(capistrano or how it's called) are compelling reasons for Rails. I
saw that there's a new project split from the Django SVN at
http://code.google.com/p/deseb/ which I bookmarked for further study.
Is this the one by the Derek you mentioned?

Yup. It never ceases to amaze me how many people are willing to put
hours or days of time into lobbying for the feature, but never bother
to contribute so much as a single line of code to get it working. More
people should follow Derek's example: code speaks louder than words.

Post by Stefan Matthias Aust
Their success of course does not original from a single timeline
document, but being reliable certainly helps to attract corporations.

They got a bit of a head start with that, don't you think?

Post by Stefan Matthias Aust
It's not that I cannot check out SVN and re-submit it to our own VCS,
but it just feels unstable.

OK. That's your feeling and I can't argue with it. It's not my
feeling, but what can you do?

Post by Stefan Matthias Aust
I have a different opinion: A road map is a statement of intent, a
priorization of features and a commitment. Note, that I didn't say
time line.

And, again, it's easy to find these things out if you're genuinely
interested; the Trac timeline and the developers' list are both
well-advertised and publicly available. In the case of schema
evolution, there's been quite a bit of discussion of Derek's project
just recently, for example, which would have told you everything you
wanted to know.

I'm not convinced that, at this point, it's necessary to have a
mission statement for Django releases, or anything more formal than
the process we already have: my personal opinion is that people who
make technology choices based on the sorts of things that appeal to
middle managers are people who I'll happily let turn into some other
project's problem ;)

Post by Stefan Matthias Aust
While I agree that developer time should not be wasted and the
volunteer work should be highly respected, I do not believe that
nobody has a plan on what to do next. This plan has to be coordinated
and should follow the "Django vision" of what fits into the project
and what not. It is my impression that currently, this vision is
shared by the developers but it is not written down. A road map would
be a manifested vision (if that's a word)...

See above.

[Stefan Matthias Aust]

James,

Post by James Bennett
Not having copious documentation of everything the dev team is doing
isn't the same as "making it a secret" ;)

I believe in "clarification by overstatement" :)

Post by James Bennett
Again, the easy way to see what's going on is to watch the Trac
timeline and the dev list. That lets you see commits, wiki changes and
ongoing discussions of Django development.

I'm not arguing that I have no way to learn about what is going on
right now. It's about what will go on in the near future. As long as I
cannot read the Trac timeline for tomorrow and next week, following
all these detailed information do not provide the insight I'd like to
get ;)

Post by James Bennett
We'll just have to agree to disagree. What happens if Eclipse is
coming up on a stated release date with a showstopping bug they can't
fix in time? Do they say "time-based releases are better" and push a
broken product? (rhetorical question)

As the question is rhetorical, I will not answer that this has
happened and they are now prepared, see
http://litrik.blogspot.com/2007/09/preparing-for-m5a.html ;)

Post by James Bennett
It's not a "court".

Overstatement. See above.

Post by James Bennett
And, again, it's easy to find these things out if you're genuinely
interested; the Trac timeline and the developers' list are both
well-advertised and publicly available.

Let's agree that we disagree on this.

Regards,

[d***@gmail.com]

How about a management FAQ?
And then... (you'll hate this): For each answer which is emotionally
unsatisfying, what are the smallest changes you could make which would
allow you to tweak the answer to be more satisfying?

For example: A simple, pretty, easily accessible page that allows
voting on bugs and features, and shows the current top-voted items
might be a good companion to an "It'll get fixed when it gets fixed"
answer.

Ok, just an idea, I support your idealistic vision-- but with just
minor lip service to the real world of human decision-making I think
Django could probably quadruple its user base.

Post by James Bennett

Post by Stefan Matthias Aust
It might be very obvious to you what is missing before 0.97 can be
released because you're deeply involved with the development and
exactly know it. However, I cannot easily find the answer on the web
site. Searching the mailing archive shouldn't be the only way to get
such kind of information - if that would answer the question at all.

It isn't the only way, and I didn't claim it was.

Post by Stefan Matthias Aust
Well, open source development is (or at least shouldn't be) not that
different to closed source development. When hacking something, you
should have an idea on what to achieve and when to achieve it or at
least for the progress towards the goal. Document that progress and do
not make it a secret. That is what I ask for.

Not having copious documentation of everything the dev team is doing
isn't the same as "making it a secret" ;)
Again, the easy way to see what's going on is to watch the Trac
timeline and the dev list. That lets you see commits, wiki changes and
ongoing discussions of Django development.

Post by Stefan Matthias Aust
As a software developer my self, I can understand the "when it's
ready" mantra, but IMHO that's not an acceptable answer. I mentioned
the Eclipse project and how they managed to setup an trustworthy
release process. Not only IMHO, time based releases are better than
feature driven once, see for example
http://video.google.de/videoplay?docid=-5503858974016723264

We'll just have to agree to disagree. What happens if Eclipse is
coming up on a stated release date with a showstopping bug they can't
fix in time? Do they say "time-based releases are better" and push a
broken product? (rhetorical question)

Post by Stefan Matthias Aust
Well, the provided patch seems to work just fine. I understand that
something like this must be carefully applied because it might break a
lot of applications if done wrong because nearly everybody works on
the SVN trunk. However, if there were more stable releases, not
everybody would probably work on trunk and you could be more
riskaccepting, having on the other hand more people to check out the
code, getting quicker to a stable code base. (In theory, this sound so
easy, in practice, it's of course more difficult ;)

Regardless of release frequency, we have a history of all but actively
encouraging people to work from SVN checkouts; the rate of Django
development has been such that there's almost always an attractive
feature or two in trunk that's not in the latest release, and we'd
have to switch to a weekly or even daily release schedule to prevent
that.

Post by Stefan Matthias Aust
Well, do the people who write those tickets know that they are
supposed to "defend" their tickets at the "developers court"? :) Right
now, it seems they are stalled. Would it help to distinguish bugs and
feature requests?

It's not a "court". Either somebody gets discussion going on the
ticket and a decision is reached, or nobody does and it eventually
gets closed when it's clear that nobody's actively working on/for the
ticket. And this is pretty much par for the course with open-source
projects: if you file a "drive-by" ticket with any project and never
follow up on it again, odds are nobody else is going to do it for you.

Post by Stefan Matthias Aust
Unfortune IMHO, because migrations and semi-automatic deployment
(capistrano or how it's called) are compelling reasons for Rails. I
saw that there's a new project split from the Django SVN at
http://code.google.com/p/deseb/which I bookmarked for further study.
Is this the one by the Derek you mentioned?

Yup. It never ceases to amaze me how many people are willing to put
hours or days of time into lobbying for the feature, but never bother
to contribute so much as a single line of code to get it working. More
people should follow Derek's example: code speaks louder than words.

Post by Stefan Matthias Aust
Their success of course does not original from a single timeline
document, but being reliable certainly helps to attract corporations.

They got a bit of a head start with that, don't you think?

Post by Stefan Matthias Aust
It's not that I cannot check out SVN and re-submit it to our own VCS,
but it just feels unstable.

OK. That's your feeling and I can't argue with it. It's not my
feeling, but what can you do?

Post by Stefan Matthias Aust
I have a different opinion: A road map is a statement of intent, a
priorization of features and a commitment. Note, that I didn't say
time line.

And, again, it's easy to find these things out if you're genuinely
interested; the Trac timeline and the developers' list are both
well-advertised and publicly available. In the case of schema
evolution, there's been quite a bit of discussion of Derek's project
just recently, for example, which would have told you everything you
wanted to know.
I'm not convinced that, at this point, it's necessary to have a
mission statement for Django releases, or anything more formal than
the process we already have: my personal opinion is that people who
make technology choices based on the sorts of things that appeal to
middle managers are people who I'll happily let turn into some other
project's problem ;)

Post by Stefan Matthias Aust
While I agree that developer time should not be wasted and the
volunteer work should be highly respected, I do not believe that
nobody has a plan on what to do next. This plan has to be coordinated
and should follow the "Django vision" of what fits into the project
and what not. It is my impression that currently, this vision is
shared by the developers but it is not written down. A road map would
be a manifested vision (if that's a word)...

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Malcolm Tredinnick]

Post by Stefan Matthias Aust
James,
thanks for your details answer. Let me put it right here: I'm not
complaining about the lack of dedication or progress in the
development of Django. It's more about visibility and marketing.

Post by James Bennett

Post by Stefan Matthias Aust
There's no 0.97 version despites all that changes to SVN trunk for
months.

Because we're not ready for a 0.97 release. The goals for the next
release and the general run up to Django 1.0 are pretty well-known,
even if they're not meticulously tracked with timers counting down,
and no amount of "road map" documentation will get them done any
faster.

It might be very obvious to you what is missing before 0.97 can be
released because you're deeply involved with the development and
exactly know it. However, I cannot easily find the answer on the web
site. Searching the mailing archive shouldn't be the only way to get
such kind of information - if that would answer the question at all.
Actually, I'm trying to follow the users mailing list for a couple of
weeks now (and I'm overwhelmed with information so I have to skip most
of the stuff) and couldn't answer the question what is planned for
0.97.

Post by James Bennett
The book isn't dead, and I'll leave further explanation to a search of
the mailing-list archive.

This is what I heard on this list, however I raised that issue because
it was the first question I was asked after my manager browsed a
little bit, found the book, noticed the dates and came to the
conclusion that if nothing changed since Jannuary, something ought to
be wrong.

Post by James Bennett
Generally, the Django team works to keep trunk as stable as possible;
this means that large, destabilizing features get done in branches and
then merge back in. By their nature, and by the nature of open-source
development, it sometimes takes a while for this process to be
completed.

Well, open source development is (or at least shouldn't be) not that
different to closed source development. When hacking something, you
should have an idea on what to achieve and when to achieve it or at
least for the progress towards the goal. Document that progress and do
not make it a secret. That is what I ask for.

Post by James Bennett
I'll pause for a moment here and step out of responding as a Django
user, and step into responding as Django's release manager: the answer
is "when it's ready". If you have a foolproof way of figuring out when
that will be, you should stop writing code and start making millions
of dollars selling your secret to businesses which develop software.

As a software developer my self, I can understand the "when it's
ready" mantra, but IMHO that's not an acceptable answer. I mentioned
the Eclipse project and how they managed to setup an trustworthy
release process. Not only IMHO, time based releases are better than
feature driven once, see for example
http://video.google.de/videoplay?docid=-5503858974016723264

Post by James Bennett

Post by Stefan Matthias Aust
Or what it will contain. Bugs like #2070 are open for more than a year.

Yes, but with fairly constant activity. That one is a much harder
issue than it appears to be at first glance, as some of the folks
who've said "oh, this'll be simple" and started to work on it will
tell you.

Well, the provided patch seems to work just fine.

This sentence highlights a fairly big problem with trying to rush to
conclusion. "Seems to work just fine" is only one criteria on which a
patch is to be judged. Other necessary requirements security,
portability, and maintainability (both simplicity and robustness). All
of those latter three have been issues with various patches in #2070 in
the past, as can be seen from the comments in the ticket and on
django-dev about it. Given the size and intrusiveness of the patch it
takes some time to review each major change. We will land it at some
point and it's a shame we haven't done so previously, but the delay
hasn't been because we've all been taking a nap or partying heavily.

[...]

Post by Stefan Matthias Aust

Post by James Bennett

Post by Stefan Matthias Aust
Of ~800 open tickets, 275 need a design decision, that is need the attention of
the core team.

Yup. Personally, I look at "design decision needed" as meaning "if
nobody makes a compelling argument for it, I'll come along and close
it eventually". And that's essentially what happens: if a ticket sits
at that stage for a long period of time with nobody coming forward and
making a case for it, it's probably not something that's worth doing.

Well, do the people who write those tickets know that they are
supposed to "defend" their tickets at the "developers court"? :) Right
now, it seems they are stalled. Would it help to distinguish bugs and
feature requests?

Firstly, realise that there are obviously differences of opinion (James
said "personally" in his reply, quite correctly) and practice about how
we use these particularly statuses. We do tend to collapse a few
separate things into single items like "design decision needed", but
it's a considered trade-off and has been discussed both here and on
django-dev in the past why we are doing that.

Setting aside the hyperbolic language, I'd like to point out that
"design decision needed" quite often means just that, too -- and I say
this as one of the people who helps make those decisions and resolve
those tickets. It's not just a holding place where tickets go before
they die. Quite a few bug reports and enhancements requests (mostly the
latter) need some serious thought before we go one way or the other. The
logic being that once we make a decision, it's much easier if we are
able to consistently refer to the earlier decision during any repeats of
the issue. That requires us to get it mostly right when we do make the
decision. We are not going to be rushed into making decisions merely to
show faux-progress when we can't back it up with thinking.

Of course, lower priority issues are going to languish a bit longer than
more pressing needs. Somebody who wants to count open tickets instead of
looking a bit deeper isn't going to like that, but since we're not
catering to that audience, it's not really a big deal. The substance is
in the ticket bodies, not their status or our response speed.

We intentionally removed severity and priority fields from our Trac,
since although they are very useful on one level, they are also highly
prone to be abused or misunderstood in a system where anybody can adjust
them. They added a maintenance burden that wasn't justified. This means
people looking at a ticket that might still be open after a while are
going to have to spend a little bit of time searching the mailing
archives and other places (all of which show up in Google), but this
isn't a truly onerous requirement if somebody genuinely cares about an
issue.

Regards,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Stefan Matthias Aust]

Post by Malcolm Tredinnick
Of course, lower priority issues are going to languish a bit longer than
more pressing needs. Somebody who wants to count open tickets instead of
looking a bit deeper isn't going to like that, but since we're not
catering to that audience, it's not really a big deal. The substance is
in the ticket bodies, not their status or our response speed.

I'm sorry if I somehow offended you by counting tickets.

I wanted to point out that because of the large number of "design
decision needed" and the span of time some tickets are already
existing *plus* the lack of an easy to browse and communicate road
map, one can jump to the conclusion development is overstrained and/or
unfocussed. Please note, I do *not* imply that it is that way, but it
puts an otherwise great project into a bad light and makes it more
difficult to argue for. I'm offering a point of view here which you -
obviously - do not like but which is IMHO important to understand and
to deal with. (Ignoring it is one valid way to do, but there might be
better ways ;)

Post by Malcolm Tredinnick
We intentionally removed severity and priority fields from our Trac,
since although they are very useful on one level, they are also highly
prone to be abused or misunderstood in a system where anybody can adjust
them. They added a maintenance burden that wasn't justified.

I agree with that.

Post by Malcolm Tredinnick
This means
people looking at a ticket that might still be open after a while are
going to have to spend a little bit of time searching the mailing
archives and other places (all of which show up in Google), but this
isn't a truly onerous requirement if somebody genuinely cares about an
issue.

I'd like to reword (and overstate) your statement: "If you're too lazy
to search for the existing information yourself, you're not worth it."
Is that correct? This means, we're arguing about whose responsibility
it is to provide overview and road map information. My point is: it is
the responsibility of the project which wants to get considered for
usage. Your (and James) point is, I think: if it was said once, it can
be found. That feels elite, IMHO.

I appreciate your opinion.

[Malcolm Tredinnick]

On Mon, 2007-10-01 at 17:36 +0200, Stefan Matthias Aust wrote:
[...]

Post by Stefan Matthias Aust
I'd like to reword (and overstate) your statement: "If you're too lazy
to search for the existing information yourself, you're not worth it."
Is that correct?

Of course not. Please stop trying to inflame the conversation in this
fashion.

Maintaining information in more than one place is a burden. We are all
volunteers. Ergo, we try to keep the effort required to maintain stuff
to a minimum. The reason I made the point that all of this information
is available via Google is because it means there is already a one-stop
point for finding this stuff. You type a reasonably sensible query in,
spend a few minutes reading the top few links and you're away.

It's a pragmatic decision and not unique to Django. Please stop trying
to reframe the issue as denigrating the people who use the product,
because that is clearly not our intention (take the volume of traffic on
this list and others as clear evidence as to where our intentions lie).

Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Marty Alchin]

Post by Malcolm Tredinnick
Maintaining information in more than one place is a burden. We are all
volunteers. Ergo, we try to keep the effort required to maintain stuff
to a minimum. The reason I made the point that all of this information
is available via Google is because it means there is already a one-stop
point for finding this stuff. You type a reasonably sensible query in,
spend a few minutes reading the top few links and you're away.

I won't comment on most of this discussion, but I'll add to this
point. Something I consider to be a cornerstone of Django development
(and perhaps open source in general) is this: if you'd like to see
something done, go ahead and do it. As Malcolm rightly states, this
information is freely available, as is all the information in Trac.
Both sources also offer RSS feeds to pull in new updates. If you'd
like a one-stop information resource tying all of this together, by
all means, write one. Django would actually make that a fairly easy
task, I expect.

You may well argue that it shouldn't be your responsibility, and that
it should be taken on by the project administrators. But set aside,
for a moment, the issue of who *should* do it, and at least realize
that it can in fact be done without any approval or blessing from
anyone. And yes, I know it wouldn't be a fully automated process, and
that somebody would have to babysit the information and make the
appropriate links. The manual portion of it is part of the reason the
core developers haven't seen fit to take it on.

One way to look at it is this: Would you rather we aggregate
information or write code? It's clear we can't do both simultaneously
with much success, so we have to pick one or the other. I, for one,
choose to write code, but there are probably others who would love to
devote time to something like this. If that's the case, by all means,
find them and get it started. The information's out there. If it's not
available the way you'd like it, by all means do something about that.
Don't just complain that nobody else is doing so.

-Gul

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joe]

Post by James Bennett
I'll pause for a moment here and step out of responding as a Django
user, and step into responding as Django's release manager: the answer
is "when it's ready". If you have a foolproof way of figuring out when
that will be, you should stop writing code and start making millions
of dollars selling your secret to businesses which develop software.

In the business world, we set goals and track our progress to them.
In the act of tracking our goals, we learn lessons that improve our
development processes and increase our productivity. Django's team
can do the same. Set a goal, even if it is "Let's shoot to make the
trunk stable on 10/10 so we can tag the code."

Post by James Bennett
"It's done when it's done" is all I can give you. "It's done even
though it's not" wouldn't make any sense, and neither would automatic
releases; I'll take quality over quantity any day of the week, and
"released later, but finished" over "released now, but doesn't work".

And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.

Post by James Bennett
Personally, I look on timelines and roadmaps as lies dressed up in
fancy clothing. When Fred Brooks wrote his famous book on software
management, nobody really had a handle on how to plan or schedule
software projects. Thirty-two years later, nobody really has a handle
on how to plan or schedule software projects.

I disagree. There are ways to plan and manage software development
and to minimize risk. Build in padding time for disasters. Don't set
one big goal, set a bunch of little ones. Update your plan when
things don't go as planned.

Start simple. Shoot to have a stable trunk on a certain date.

Post by James Bennett
Generally, the Django team works to keep trunk as stable as possible;

If this is true, what is the disadvantage to tagging a release every
couple of months? It would provide a serious benefit to those of us
who have to deal with corporate red tape.

I know this may seem a little harsh and may get your blood stirred up,
but I ask you to consider it rationally as a way to help us project
managers with restrictive corporate oversight.

Regards,

Joe


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Stefan Matthias Aust]

Joe,

Post by Joe
[...]
And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.
[...]

You explained my points much better than I could (in plain English at least ;)

Thanks.

[Derek Anderson]

actually, "it's done when it's done" can be sold in a corporate
environment. it has the unfortunate characteristic of being the closest
thing to truth when modeling software development, and no amount of
pre-planning or chart-making is going to get you a more accurate answer.

some key facts to present to your management when making your case:

* developers are unable to give unbiased time estimates when they know
their performance will be judged by comparison to them later
(it's OK to ask, but never say "but you said...")
* individual feature deadlines encourage either:
- slacking because you know you're head of schedule
- hacking because you know you're behind schedule
both of which are detrimental to quality and productivity
* final performance should be judged via post-game analysis (when the
scope and complexity of a problem are known) and pre-game
preconceptions should be given little-to-no weight
* day-by-day performance can be had by monitoring VCS/bugzilla, with no
performance penalty to the developer. (as long as you enforce
frequent commits - teach them about temp. branches if they're going
to be breaking existing functionality for days on end)

and don't say "but my employer/phb is too conservative for this". i've
run dev teams for telcoms and the us military, two of the most
hard-nosed waterfall-lovin' organizations ever to have existed. it
takes a while to prove it right to them, but given persistence without
dickishness it is possible. (and most PHB's aren't actually evil, just
confused by the mystical beast that is programming, annoyed at being
treated like a moron because they don't the the computing equivalent to
"what's the proper timing sequence for a ford 302 V8", and suspicious of
programmers who have a history of outright lying to them)

btw, why do you think OSS is beating the pants off of closed-source
stuff anyway? we don't have more money. we don't have smarter people.
what we have is a vastly more efficient development model.

anyway, my $.02.
derek

p.s. btw, it's career suicide just walk in and start with "we're going
to abandon everything you trust and go with what is described above".
prerequisites include:
* building strong trust relationships with your superiors, and making
sure that when they don't agree with you, they believe you're truly
arguing in the best interests of the org.
* proving first that you can make *their* preferred development models
work, before you try changing them.
* and don't try to change things wholesale. break them in a piece at a
time, each time starting with "let's try an experiment"

p.p.s. as far as release dates go, it's ok to set them. just have it
be known that the deliverable feature set is an always changing target.
done features are definitely in, in progress features are in flux
between making the release or the next one. and your unknown factor
naturally shrinks as you get closer and closer to the date. with
frequent releases, you'll find the users don't bitch too much when you
tell them "sorry, X didn't make it into this one because it {'took
longer','fell to higher priority work'}"

p.p.p.s. still reading? sorry, this turned into a much longer email
than i anticipated. =p

Post by Stefan Matthias Aust
Joe,

Post by Joe
[...]
And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.
[...]

You explained my points much better than I could (in plain English at least ;)
Thanks.

--
looking to buy or sell anything?

try: http://allurstuff.com

it's a classified ads service that
shows on a map where the seller is
(think craigslist + google maps)

plus it's 100% free :)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joe]

Derek,

I agree with you that the waterfall method of software development is
broken and we don't use it here.

However, we do set deadlines and goals, and we try to make them an
accurate estimation of time required to complete work.

How do we do this? Using a lot of the techniques that you said
above. We never have a deadline that is more than 6 weeks away. It
allows any errors that do get into our timelines to have a minimal
impact. It allows us to be flexible with changing requirements,
and...well, go read an agile development book if you want the rest of
the spiel.

However, I don't even see as much as an "we will have x done in 1
week" in the Django environment. I understand Malcom's arguments
about volunteering and unpredictable development timelines, but to not
even try to shoot for a simple, easy to reach milestone seems like you
are underestimating yourself and your colleagues.

To simply say I don't want to set a milestone just to watch us miss it
ignores that fact that milestones have several benefits:

1) A common, distinct, achievable goal
2) A way to measure progress and learn about weak and strong points in
your development process
3) A tangible accomplishment to make people feel like there is
progress being made
4) Pressure/incentive to complete a task in a timely manner

I don't think the majority of the django core team share my point of
view, so I am willing to accept "it is what it is". I just hope that
my arguments have opened consideration to a few compromises that will
help both the corporate user and the underpaid :) Django commiter.

Post by Derek Anderson
actually, "it's done when it's done" can be sold in a corporate
environment. it has the unfortunate characteristic of being the closest
thing to truth when modeling software development, and no amount of
pre-planning or chart-making is going to get you a more accurate answer.
* developers are unable to give unbiased time estimates when they know
their performance will be judged by comparison to them later
(it's OK to ask, but never say "but you said...")
- slacking because you know you're head of schedule
- hacking because you know you're behind schedule
both of which are detrimental to quality and productivity
* final performance should be judged via post-game analysis (when the
scope and complexity of a problem are known) and pre-game
preconceptions should be given little-to-no weight
* day-by-day performance can be had by monitoring VCS/bugzilla, with no
performance penalty to the developer. (as long as you enforce
frequent commits - teach them about temp. branches if they're going
to be breaking existing functionality for days on end)
and don't say "but my employer/phb is too conservative for this". i've
run dev teams for telcoms and the us military, two of the most
hard-nosed waterfall-lovin' organizations ever to have existed. it
takes a while to prove it right to them, but given persistence without
dickishness it is possible. (and most PHB's aren't actually evil, just
confused by the mystical beast that is programming, annoyed at being
treated like a moron because they don't the the computing equivalent to
"what's the proper timing sequence for a ford 302 V8", and suspicious of
programmers who have a history of outright lying to them)
btw, why do you think OSS is beating the pants off of closed-source
stuff anyway? we don't have more money. we don't have smarter people.
what we have is a vastly more efficient development model.
anyway, my $.02.
derek
p.s. btw, it's career suicide just walk in and start with "we're going
to abandon everything you trust and go with what is described above".
* building strong trust relationships with your superiors, and making
sure that when they don't agree with you, they believe you're truly
arguing in the best interests of the org.
* proving first that you can make *their* preferred development models
work, before you try changing them.
* and don't try to change things wholesale. break them in a piece at a
time, each time starting with "let's try an experiment"
p.p.s. as far as release dates go, it's ok to set them. just have it
be known that the deliverable feature set is an always changing target.
done features are definitely in, in progress features are in flux
between making the release or the next one. and your unknown factor
naturally shrinks as you get closer and closer to the date. with
frequent releases, you'll find the users don't bitch too much when you
tell them "sorry, X didn't make it into this one because it {'took
longer','fell to higher priority work'}"
p.p.p.s. still reading? sorry, this turned into a much longer email
than i anticipated. =p

Post by Stefan Matthias Aust
Joe,

Post by Joe
[...]
And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.
[...]

You explained my points much better than I could (in plain English at least ;)
Thanks.

--
looking to buy or sell anything?
try:http://allurstuff.com
it's a classified ads service that
shows on a map where the seller is
(think craigslist + google maps)
plus it's 100% free :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mark Green]

Post by Stefan Matthias Aust
Joe,

Post by Joe
[...]
And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.
[...]

You explained my points much better than I could (in plain English at least ;)

Throwing in my 2 cents here...

I basically agree with all that has been said, as in: it would be great
to have a stable, predictable timeline - but it's unrealistic to achieve
that without at least one full-time person to do the housekeeping.

Since that full-time person doesn't exist I'd like to propose
something in between that I have seen implemented successfully
even in very small projects:

0. Realize that creating a roadmap takes zero time and only very
little effort. You get it for free, from your ticket-system.

1. Get sorted. Take advantage of the trac milestones and, more
importantly, ticket relations (does trac have them nowadays?).
The future will become *much* clearer once you have added hierarchy
to the ticket swarm. It forces you to decide which things to do
first (Milestone 1) and which to delay for a later date.
At the same time a roadmap emerges naturally because the
"almost-done things" bubble up and become more visible.

2. Don't bother with actual calendar dates. An occassional rough
estimate "could be ready at" never hurts but "70% done, ticket-wise"
gives a much better indication of progress anyways. Better yet,
instead of picking randomly, people can then specificially
choose to work on tickets that are relevant to the next
milestone or to the particular feature that they're after.

3. Maybe investigate on a better ticket system.
The trac ticketing sucks very hard in all regards
and is beaten hands down by http://mantisbt.org or
http://redmine.org. I hate to say but even the dreaded
JIRA does it better. Well, long story short, you want
custom workflow/ticket states, so your tickets can't be
"ready for checkin" and "new" at the same time. You want
a clean UI and a working search that doesn't hurt everytime
you use it. You want to draw clear parent/child relationships
all the way up to the milestones.
Ofcourse a new ticket-system is not a must but having fought
my own share of uphill battles against trac I can tell from
expirience that many trac-users don't that they're missing
a fair share of essential features.

In summary, I think this whole discussion should really be
about transparency, not about fixed dates.

Programming schedules don't work with fixed dates.
"It's done when it's done" is not an excuse, it's a
honest summary of the situation.

So all we need to do is add more transparency to the state of affairs
and that's simply a matter of using better tools or using the existing
tools better.

I don't think the call for a roadmap would have appeared if
somewhere on the django site it read like:

---snip---

Milestone 7 (16%, 40 of 240 tickets open, aggregate eta: 01-Apr-2009)
- Sub-Goal 1: old admin to new admin
(66%, 14 of 21 tickets open, eta: 01-12-2007)
- Sub-Goal 2: enforce winnie-pooh.css for all sites
(0%, 1 of 1 tickets open)
- etc.

---snip---

Ofcourse the ETA doesn't really mean anything (just some numbers
magic that a good ticket system can do) but the above view is imho
the closest to a "roadmap" that an OSS project can get.
And, believe it or not, towards the end of a Sub-Goal those figures
often converge to surprisingly accurate estimates.

Last but no least, don't underestimate the motivational factor
of more transparency. People like the feeling of actually causing
an impact on something (the fame-factor). With the current trac
there's just an anonymous sea of tickets, not really inviting
to give or take yet another drop. A little more structure
and clustering would provide much better positive feedback
to the contributor here. It just *feels* better to close ticket
6 of 10 on a Sub-Goal, pushing it from 50% to 60%, than to close
one random ticket out of hundreds without knowing what other tickets
may be interacting with or even blocking the issue at hand.

Well, this is getting too long but I hope some of my ideas
don't sound too far fetched to some of you. :)

-mark



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Malcolm Tredinnick]

Post by Joe

Post by James Bennett
I'll pause for a moment here and step out of responding as a Django
user, and step into responding as Django's release manager: the answer
is "when it's ready". If you have a foolproof way of figuring out when
that will be, you should stop writing code and start making millions
of dollars selling your secret to businesses which develop software.

In the business world, we set goals and track our progress to them.
In the act of tracking our goals, we learn lessons that improve our
development processes and increase our productivity. Django's team
can do the same. Set a goal, even if it is "Let's shoot to make the
trunk stable on 10/10 so we can tag the code."

Guess what? It works that way in the Open Source world, too. Django
isn't unusual in the way it works. Currently our goal is "work to get
all the features on the VersionOneFeatures wiki page done", plus
incorporating new stuff that we learn needs to be incorporated along the
way. The fact that our goal isn't time-based isn't in any way
revolutionary -- lots of corporate projects are run on similar lines. If
you want to set a deadline just to hear the sound of it whooshing by,
this isn't the place for that.

Nobody working on a major project wants to just run along with no point
to their work and that's not how we operate. There is, however, a
difference of perspective needed: we are targeting particular features
at the moment, rather than a moment in time. This is more productive at
this point simply because of the nature of the features and the time we
have available.

Post by Joe

Post by James Bennett
"It's done when it's done" is all I can give you. "It's done even
though it's not" wouldn't make any sense, and neither would automatic
releases; I'll take quality over quantity any day of the week, and
"released later, but finished" over "released now, but doesn't work".

And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.

Come on! :-) Your analogy is a little strained. If your bosses said "I
want everybody to commit to these deadlines, but you're all going to do
it whilst working as volunteers and in between your other commitments
and some of you will wander off due to lost interest or life requiring a
change or priorities", you wouldn't be surprised to find time goals much
harder to meet. Trying not to bring up the "firing" word in this
context. It's too much of a stretch.

It's fairly clear to me from reading this thread that a few people are
trying desperately to match up commercial software development with open
source development. No problems there; there's generally a very large
overlap and almost everything on the technical level carries across. On
the managerial level, things are a bit different, though. Firstly, you
can make this easier by not assuming Django is different from almost any
other open source project out there. Every project that is currently in
a successful time-based release process had a period when they were
feature based to get to a certain base point. Django is still in that
preliminary phase. We may or may not move to time-based releases later
on -- that hasn't been discussed and there are certainly valid arguments
on both sides, so it isn't a no-brainer. Every large project that
manages to set a line on the calendar and hit it has ended up having
people working on it full time. Look at how GNOME 2.0 got released. Look
at how Apache 2.0 got released. Look at the preliminary and ongoing Perl
6 work. In all of those cases, it was not done entirely by volunteers
and it still was very, very difficult to timetable except in the last
few months prior to a release. That's both a pro and a con about open
source development: predicting timetables is hard because of the nature
of the contributions.

Don't get sucked into expecting a total match with operating practices
in the commercial world in that respect: in exchange for you being
somewhat beholden to your employer's wishes, they *employ* you.

[...]

Post by Joe

Post by James Bennett
Generally, the Django team works to keep trunk as stable as possible;

If this is true, what is the disadvantage to tagging a release every
couple of months? It would provide a serious benefit to those of us
who have to deal with corporate red tape.

One disadvantage from that kind of model is security: we would either
have to keep security fixes up to date for a much larger number of
releases or EOL releases much faster, which is also a not insignificant
downside in the corporate world.

Another is credibility and QA: either you have to have periodic freezes
prior to these snapshots to stabilise things, bring translations up to
date, etc, or else they mean nothing. In the latter case, it isn't
benefiting anybody because you could just create a snapshot yourself to
satisfy the Red Tape Department (want to make a 20071001 release? Tar up
a checkout from today and you're done!).

Seriously, guys, these sorts of threads aren't new. They've come up
before in Django and regularly make appearances in other projects. They
also don't tend to be particularly productive except as a way for people
to let off steam. There isn't a serious contributor on this list who
isn't aware of how things work in the corporate world. For most of us,
that's where we work. Teaching us how to suck eggs isn't really needed.
A lot of people on this list and particularly on django-dev also all
pretty experienced in the open source world and give a lot of time and
resources to that arena. Bagging our decisions -- which unsurprisingly
aren't made based on a whim -- doesn't help anybody; you or us.

Juggling the corporate image is very much one aspect of managing an open
source project and we (channelling all the maintainers for a moment) are
certainly not unsympathetic to that side of things. In the past we have
made decisions that are real compromises purely on the grounds that it
will work better on the business front. However, it is only one aspect.
You aren't describing any thoughts that haven't gone through lots of
minds in the past and whilst I can appreciate that frustrations build up
as time goes by, I would ask that you try to understand the flip side
and spend a bit of time looking at how analogous projects are working.

We are all focused on getting to 1.0 as quickly as possible. We've
chosen to be feature-based at the moment. In full awareness that that
will not be a perfect match for everybody's requirements. Time-based
release processes wouldn't be a perfect match either. It's all about
compromise. That's why we did 0.96 before launching into a bunch of
backwards-incompatible changes, for example. It's why we released 0.95
when we did, too. We're trying to keep most people as happy as we're
able to, whilst maintaining a reasonably steady course towards a very
significant milestone.

Your voices are being heard and the same has always been true.

Best wishes,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[staff-gmail]

Malcolm,
well said - I just wasted a bunch of time writing a response that was
similar - sooo, do you think it's worthwhile to pull this together on a
about / welcome / introduction page under a heading like "How Django
Works". Then when these comments come, they can be pointed to the
page. If you think it's worthwhile, I'll post some text to a
documentation ticket.

Post by Malcolm Tredinnick

Post by Joe

Post by James Bennett
I'll pause for a moment here and step out of responding as a Django
user, and step into responding as Django's release manager: the answer
is "when it's ready". If you have a foolproof way of figuring out when
that will be, you should stop writing code and start making millions
of dollars selling your secret to businesses which develop software.

In the business world, we set goals and track our progress to them.
In the act of tracking our goals, we learn lessons that improve our
development processes and increase our productivity. Django's team
can do the same. Set a goal, even if it is "Let's shoot to make the
trunk stable on 10/10 so we can tag the code."

Guess what? It works that way in the Open Source world, too. Django
isn't unusual in the way it works. Currently our goal is "work to get
all the features on the VersionOneFeatures wiki page done", plus
incorporating new stuff that we learn needs to be incorporated along the
way. The fact that our goal isn't time-based isn't in any way
revolutionary -- lots of corporate projects are run on similar lines. If
you want to set a deadline just to hear the sound of it whooshing by,
this isn't the place for that.
Nobody working on a major project wants to just run along with no point
to their work and that's not how we operate. There is, however, a
difference of perspective needed: we are targeting particular features
at the moment, rather than a moment in time. This is more productive at
this point simply because of the nature of the features and the time we
have available.

Post by Joe

Post by James Bennett
"It's done when it's done" is all I can give you. "It's done even
though it's not" wouldn't make any sense, and neither would automatic
releases; I'll take quality over quantity any day of the week, and
"released later, but finished" over "released now, but doesn't work".

And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.

Come on! :-) Your analogy is a little strained. If your bosses said "I
want everybody to commit to these deadlines, but you're all going to do
it whilst working as volunteers and in between your other commitments
and some of you will wander off due to lost interest or life requiring a
change or priorities", you wouldn't be surprised to find time goals much
harder to meet. Trying not to bring up the "firing" word in this
context. It's too much of a stretch.
It's fairly clear to me from reading this thread that a few people are
trying desperately to match up commercial software development with open
source development. No problems there; there's generally a very large
overlap and almost everything on the technical level carries across. On
the managerial level, things are a bit different, though. Firstly, you
can make this easier by not assuming Django is different from almost any
other open source project out there. Every project that is currently in
a successful time-based release process had a period when they were
feature based to get to a certain base point. Django is still in that
preliminary phase. We may or may not move to time-based releases later
on -- that hasn't been discussed and there are certainly valid arguments
on both sides, so it isn't a no-brainer. Every large project that
manages to set a line on the calendar and hit it has ended up having
people working on it full time. Look at how GNOME 2.0 got released. Look
at how Apache 2.0 got released. Look at the preliminary and ongoing Perl
6 work. In all of those cases, it was not done entirely by volunteers
and it still was very, very difficult to timetable except in the last
few months prior to a release. That's both a pro and a con about open
source development: predicting timetables is hard because of the nature
of the contributions.
Don't get sucked into expecting a total match with operating practices
in the commercial world in that respect: in exchange for you being
somewhat beholden to your employer's wishes, they *employ* you.
[...]

Post by Joe

Post by James Bennett
Generally, the Django team works to keep trunk as stable as possible;

If this is true, what is the disadvantage to tagging a release every
couple of months? It would provide a serious benefit to those of us
who have to deal with corporate red tape.

One disadvantage from that kind of model is security: we would either
have to keep security fixes up to date for a much larger number of
releases or EOL releases much faster, which is also a not insignificant
downside in the corporate world.
Another is credibility and QA: either you have to have periodic freezes
prior to these snapshots to stabilise things, bring translations up to
date, etc, or else they mean nothing. In the latter case, it isn't
benefiting anybody because you could just create a snapshot yourself to
satisfy the Red Tape Department (want to make a 20071001 release? Tar up
a checkout from today and you're done!).
Seriously, guys, these sorts of threads aren't new. They've come up
before in Django and regularly make appearances in other projects. They
also don't tend to be particularly productive except as a way for people
to let off steam. There isn't a serious contributor on this list who
isn't aware of how things work in the corporate world. For most of us,
that's where we work. Teaching us how to suck eggs isn't really needed.
A lot of people on this list and particularly on django-dev also all
pretty experienced in the open source world and give a lot of time and
resources to that arena. Bagging our decisions -- which unsurprisingly
aren't made based on a whim -- doesn't help anybody; you or us.
Juggling the corporate image is very much one aspect of managing an open
source project and we (channelling all the maintainers for a moment) are
certainly not unsympathetic to that side of things. In the past we have
made decisions that are real compromises purely on the grounds that it
will work better on the business front. However, it is only one aspect.
You aren't describing any thoughts that haven't gone through lots of
minds in the past and whilst I can appreciate that frustrations build up
as time goes by, I would ask that you try to understand the flip side
and spend a bit of time looking at how analogous projects are working.
We are all focused on getting to 1.0 as quickly as possible. We've
chosen to be feature-based at the moment. In full awareness that that
will not be a perfect match for everybody's requirements. Time-based
release processes wouldn't be a perfect match either. It's all about
compromise. That's why we did 0.96 before launching into a bunch of
backwards-incompatible changes, for example. It's why we released 0.95
when we did, too. We're trying to keep most people as happy as we're
able to, whilst maintaining a reasonably steady course towards a very
significant milestone.
Your voices are being heard and the same has always been true.
Best wishes,
Malcolm

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Tim Chase]

Post by staff-gmail
similar - sooo, do you think it's worthwhile to pull this together on a
about / welcome / introduction page under a heading like "How Django
Works". Then when these comments come, they can be pointed to the
page. If you think it's worthwhile, I'll post some text to a
documentation ticket.

...but is there a roadmap for when this will make it into the
documentation?

<grins, ducks, and runs>

-tim




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Henning Hraban Ramm]

Post by Tim Chase

Post by staff-gmail
similar - sooo, do you think it's worthwhile to pull this together on a
about / welcome / introduction page under a heading like "How Django
Works". Then when these comments come, they can be pointed to the
page. If you think it's worthwhile, I'll post some text to a
documentation ticket.

...but is there a roadmap for when this will make it into the
documentation?

Here's one of many roadmaps for Django:
http://tinyurl.com/23au8c


Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net
https://www.cacert.org (I'm an assurer)



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[staff-gmail]

okay,okay, I'll just write up something and submit it :) I didn't see
any welcome or about page on the main site so I'll work on that and
include this stuff. Now back to coding.

Post by Tim Chase

Post by staff-gmail
similar - sooo, do you think it's worthwhile to pull this together on a
about / welcome / introduction page under a heading like "How Django
Works". Then when these comments come, they can be pointed to the
page. If you think it's worthwhile, I'll post some text to a
documentation ticket.

...but is there a roadmap for when this will make it into the
documentation?
<grins, ducks, and runs>
-tim

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joe]

Malcolm,

I may not agree with everything you said, but I appreciate you taking
the time to write a response and address my concerns in a logical,
thoughtful manner .

Are you sure there is no compromise on doing a "stable" tag every few
months? Unless you religiously monitor the timelines and the google
groups, it is a little difficult to pick a good time to tag the trunk
between major merges and refactors.

I know there are concerns about this (end of life on releases, or
security fixes on releases, etc.). I am not really sure how this can
(if this can) be accomplished, but I think it would really help us
"corporate middle managers" out!

Maybe you can tag "Release Candidates" with no guarantee of bug fixes?

Regards,

Joe

Post by Malcolm Tredinnick

Post by Joe

Post by James Bennett
I'll pause for a moment here and step out of responding as a Django
user, and step into responding as Django's release manager: the answer
is "when it's ready". If you have a foolproof way of figuring out when
that will be, you should stop writing code and start making millions
of dollars selling your secret to businesses which develop software.

In the business world, we set goals and track our progress to them.
In the act of tracking our goals, we learn lessons that improve our
development processes and increase our productivity. Django's team
can do the same. Set a goal, even if it is "Let's shoot to make the
trunk stable on 10/10 so we can tag the code."

Guess what? It works that way in the Open Source world, too. Django
isn't unusual in the way it works. Currently our goal is "work to get
all the features on the VersionOneFeatures wiki page done", plus
incorporating new stuff that we learn needs to be incorporated along the
way. The fact that our goal isn't time-based isn't in any way
revolutionary -- lots of corporate projects are run on similar lines. If
you want to set a deadline just to hear the sound of it whooshing by,
this isn't the place for that.
Nobody working on a major project wants to just run along with no point
to their work and that's not how we operate. There is, however, a
difference of perspective needed: we are targeting particular features
at the moment, rather than a moment in time. This is more productive at
this point simply because of the nature of the features and the time we
have available.

Post by Joe

Post by James Bennett
"It's done when it's done" is all I can give you. "It's done even
though it's not" wouldn't make any sense, and neither would automatic
releases; I'll take quality over quantity any day of the week, and
"released later, but finished" over "released now, but doesn't work".

And this is the biggest disconnect between Django's team and the
business world. If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for." And, you know what?
Most of the time our estimates are pretty close. And by tracking how
we do on our estimates, we can make them even more accurate.

Come on! :-) Your analogy is a little strained. If your bosses said "I
want everybody to commit to these deadlines, but you're all going to do
it whilst working as volunteers and in between your other commitments
and some of you will wander off due to lost interest or life requiring a
change or priorities", you wouldn't be surprised to find time goals much
harder to meet. Trying not to bring up the "firing" word in this
context. It's too much of a stretch.
It's fairly clear to me from reading this thread that a few people are
trying desperately to match up commercial software development with open
source development. No problems there; there's generally a very large
overlap and almost everything on the technical level carries across. On
the managerial level, things are a bit different, though. Firstly, you
can make this easier by not assuming Django is different from almost any
other open source project out there. Every project that is currently in
a successful time-based release process had a period when they were
feature based to get to a certain base point. Django is still in that
preliminary phase. We may or may not move to time-based releases later
on -- that hasn't been discussed and there are certainly valid arguments
on both sides, so it isn't a no-brainer. Every large project that
manages to set a line on the calendar and hit it has ended up having
people working on it full time. Look at how GNOME 2.0 got released. Look
at how Apache 2.0 got released. Look at the preliminary and ongoing Perl
6 work. In all of those cases, it was not done entirely by volunteers
and it still was very, very difficult to timetable except in the last
few months prior to a release. That's both a pro and a con about open
source development: predicting timetables is hard because of the nature
of the contributions.
Don't get sucked into expecting a total match with operating practices
in the commercial world in that respect: in exchange for you being
somewhat beholden to your employer's wishes, they *employ* you.
[...]

Post by Joe

Post by James Bennett
Generally, the Django team works to keep trunk as stable as possible;

If this is true, what is the disadvantage to tagging a release every
couple of months? It would provide a serious benefit to those of us
who have to deal with corporate red tape.

One disadvantage from that kind of model is security: we would either
have to keep security fixes up to date for a much larger number of
releases or EOL releases much faster, which is also a not insignificant
downside in the corporate world.
Another is credibility and QA: either you have to have periodic freezes
prior to these snapshots to stabilise things, bring translations up to
date, etc, or else they mean nothing. In the latter case, it isn't
benefiting anybody because you could just create a snapshot yourself to
satisfy the Red Tape Department (want to make a 20071001 release? Tar up
a checkout from today and you're done!).
Seriously, guys, these sorts of threads aren't new. They've come up
before in Django and regularly make appearances in other projects. They
also don't tend to be particularly productive except as a way for people
to let off steam. There isn't a serious contributor on this list who
isn't aware of how things work in the corporate world. For most of us,
that's where we work. Teaching us how to suck eggs isn't really needed.
A lot of people on this list and particularly on django-dev also all
pretty experienced in the open source world and give a lot of time and
resources to that arena. Bagging our decisions -- which unsurprisingly
aren't made based on a whim -- doesn't help anybody; you or us.
Juggling the corporate image is very much one aspect of managing an open
source project and we (channelling all the maintainers for a moment) are
certainly not unsympathetic to that side of things. In the past we have
made decisions that are real compromises purely on the grounds that it
will work better on the business front. However, it is only one aspect.
You aren't describing any thoughts that haven't gone through lots of
minds in the past and whilst I can appreciate that frustrations build up
as time goes by, I would ask that you try to understand the flip side
and spend a bit of time looking at how analogous projects are working.
We are all focused on getting to 1.0 as quickly as possible. We've
chosen to be feature-based at the moment. In full awareness that that
will not be a perfect match for everybody's requirements. Time-based
release processes wouldn't be a perfect match either. It's all about
compromise. That's why we did 0.96 before launching into a bunch of
backwards-incompatible changes, for example. It's why we released 0.95
when we did, too. We're trying to keep most people as happy as we're
able to, whilst maintaining a reasonably steady course towards a very
significant milestone.
Your voices are being heard and the same has always been true.
Best wishes,
Malcolm

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Malcolm Tredinnick]

On Mon, 2007-10-01 at 12:18 -0700, Joe wrote:
[...]

Post by Joe
Are you sure there is no compromise on doing a "stable" tag every few
months? Unless you religiously monitor the timelines and the google
groups, it is a little difficult to pick a good time to tag the trunk
between major merges and refactors.

Look, I agree and can sympathise with this. I don't know of a perfect
solution here -- and I've been involved in similar release discussions
in other projects, trying to work out how to help distributors (Red Hat,
Suse, Mandriva, etc) stay in sync. In the end, they really have to
either pick a released version or -- in the periods between releases --
take a snapshot and work with that.

The hard part about sticking a less formal "stable" tag on something is
working out what it means and when would be the right moment to do so.

As a practical issue, at almost any given moment in time (certainly more
often than not), a random snapshot is going to be relatively bug free.
We really are serious about keeping the tree running as perfectly as
possible at any given moment and if somebody checks in something that
breaks the tree in a big way, it has an expected lifetime measured in
hours, not days. So how do we pick one moment as being more stable than
another and worthy of a tag?

Flipping that around and saying that we could therefore pick any moment
to tag just to satisfy the corporate arena is one of the things that
doesn't usually happen in open source projects. If your constraints are
such that running against a snapshot is not approved, then playing word
games to pretend something isn't a snapshot (whether we play the games
or you do with an internal snapshot) is the sort of futile approach that
only leads to disillusionment when whoever is in charge of policies find
out they've been had.

There are a lot of us running Django trunk in production environments.
However, as the original poster in this thread discovered, many uses are
also going to require patches against trunk in certain circumstances --
so things aren't "stable for all uses". Most of the popular trunk
modifications that people are making are on the table for resolution in
one form or another prior to 1.0 -- and that is one of the triggers for
when we will be ready to release. So right this minute is no more or
less stable than last week or next week. However, it's also quite a way
away from where will be at 1.0, so it's not really stable in the sense
of "unmoving".

The other slight concern here is that it's kind of solving a non-problem
to a certain extent (and I say that realising this whole thread is
revolving around that very contention and varying interpretations of
it)...

The original open sourcing of the Django subversion tree was in July,
2005. Django 0.90, the first release was in November, 2005 and 0.91 was
December 2005. They were very early "make an initial tarball" releases.
0.95 was the post-magic-removal release (a major stability point after a
period of instability and change) release in July 29, 200., 0.96 was
March 23, 2007 and was motivated by being a stability point prior to a
large number of changes leading up to 1.0.

So we're churning out releases (very) approximately every eight months
after getting the first tarballs out there, although that's actually
driven by being "stabile point-in-time based". That schedule would mean
that if we released 1.0 at the end of this year, it would be about the
same gap.

Post by Joe
I know there are concerns about this (end of life on releases, or
security fixes on releases, etc.). I am not really sure how this can
(if this can) be accomplished, but I think it would really help us
"corporate middle managers" out!
Maybe you can tag "Release Candidates" with no guarantee of bug fixes?

The problem I would see here is that marking something as a "release
candidate" when it isn't leads to credibility problems for us down the
track. You say you're trying to work through middle-manager problems in
your organisation; we have the same issue with our community-at-large.
If we start saying something is a release candidate when it's really
miles away from that, when will they know which are the *real* release
candidates. This might be solved by a change in terminology, but then
you're back where you started with slapping a label on an essentially
arbitrary snapshot, which you can do yourself.

There seem to be two problems here: the practical one of when to take a
snapshot (pretty much any time is as good as any other) and the paper
one of what the label is on that snapshot and we're really can't do much
more than make releases (and genuine release candidates as we'll do
leading up to 1.0) when we think the right moment arrives.

None of the above was the answers you were hoping to hear, I realise.

I think you'll find that everybody who's bothered to participate in this
thread is not unsympathetic to the problem, but putting an artificial
stamp on something isn't the solution here. Either you can run code that
isn't an official release -- without all the overhead we put into making
sure a release is a good moment QA-wise -- or you can't. The middle
ground of trying to create a blessed non-release that isn't just a
snapshot doesn't really hold up.

Best wishes,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee]

Post by Stefan Matthias Aust
There are still 12 tickets from the last sprint (great effort, BTW)
left to check-in. The casual observer easily gets the impression that
chaotic.

Yes, of course it's chaotic.

We can't commit to a timelime because our time is volunteered.
Sometime other things (family, work, etc) take priority; For example -
I thought I was going to get a full weekend free over the sprint, but
then my son required extra attention, so I didn't get to spend as much
time as I would have liked.

This also affects our ability to commit to a feature set - many (all?)
of the core developers use Django in their day jobs - and if their day
job suddenly demands a feature, then that feature is going to get
sudden attention, even if it wasn't on the grand plan. Conversely, if
someone comes along and volunteers to do a big block of work (e.g.,
the Oracle branch), we're not going to turn them away because it
wasn't on the plan.

This is all just an extension of the Golden Rule: He who has the gold,
makes the rules. In the case of volunteerism - he who volunteers makes
the rules.

As a result, it's also very easy to fix. Let's see how serious you
are. You say that your employer wants to use Django, but doesn't like
the loose timelines, etc. Whether software or hardware, every
guarantee has an actuarial cost, and the stronger the guarantee, the
higher the cost. What is your boss willing to pay for what sort of
guarantee? How much is a solid timeline worth to your employer?

I'm actually serious here - I would love to see Django become a
financially self sustaining project, but it's hard to judge how much
actual commercial interest there is in such a proposition. Anyone
should feel free to respond, and if you don't want the magic
number/terms public for commercial-in-confidence reasons, feel free to
mail me privately.

Post by Stefan Matthias Aust
Will there every be schema
evolution?

To weigh in on this topic specifically - if you have been following
the threads on this, you should know that there are several offerings
already available (Derek's deseb project being the most visible so
far). A search of recent archives will also reveal that I am hoping to
be able to make an announcement in this area in the very near future.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---