Should Django have a road map?
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... -- 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
There are some interesting points here, I look forward to the replies. --Jon On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > > 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... > > -- > 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
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 On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > > > 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... > > -- > 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?
Re: Should Django have a road map?
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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > 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. > 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. > (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. > 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. > 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. > 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. > 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. And this is compared to the normal process of software development, which is constant, rigidly-coordinated, always on-target and well-ordered? ;) > 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. > 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? > 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? > 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
Re: Should Django have a road map?
> > > 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
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. 2007/10/1, James Bennett <[EMAIL PROTECTED]>: > On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > > 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. > 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. > 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. > 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 > > 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 ;) > > 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? > > The casual observer easily gets the impression that > > work is sporadic, uncoordinated and not target-oriented, in one word: > > 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 so
Re: Should Django have a road map?
> 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." > "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. > 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. And, I already know your going to say this: > 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > 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. > 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. > 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) > 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. > 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. > 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. > 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? > 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? > 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 m
Re: Should Django have a road map?
On Mon, 2007-10-01 at 14:21 +0200, Stefan Matthias Aust wrote: > 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. > > 2007/10/1, James Bennett <[EMAIL PROTECTED]>: > > > On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > > > 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. > > > 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. > > > 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. > > > 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 > > > > 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. [...] > > > 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
Re: Should Django have a road map?
Joe, 2007/10/1, Joe <[EMAIL PROTECTED]>: > [...] > 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. -- 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
James, 2007/10/1, James Bennett <[EMAIL PROTECTED]>: > 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" :) > 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 ;) > 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 ;) > It's not a "court". Overstatement. See above. > 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, -- 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
2007/10/1, Malcolm Tredinnick <[EMAIL PROTECTED]>: > 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 ;) > 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. > 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. -- 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
On Mon, 2007-10-01 at 06:05 -0700, Joe wrote: > > 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. > > "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. [...] > > 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
Re: Should Django have a road map?
On Mon, 2007-10-01 at 17:36 +0200, Stefan Matthias Aust wrote: [...] > 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
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. Malcolm Tredinnick wrote: > On Mon, 2007-10-01 at 06:05 -0700, Joe wrote: > >>> 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. > > >>> "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. >
Re: Should Django have a road map?
> 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? -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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
On 10/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
Am 2007-10-01 um 18:46 schrieb Tim Chase: >> 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
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. Tim Chase wrote: >> 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? > > > > -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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Should Django have a road map?
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. On Oct 1, 6:13 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > > > 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. > > > 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. > > > 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) > > > 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. > > > 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. > > > 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. > > > 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? > > > 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
Re: Should Django have a road map?
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
Stefan Matthias Aust wrote:
> Joe,
>
> 2007/10/1, Joe <[EMAIL PROTECTED]>:
>> [...]
>> 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-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Should Django have a road map?
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 On Oct 1, 11:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2007-10-01 at 06:05 -0700, Joe wrote: > > > 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. > > > > "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 l
Re: Should Django have a road map?
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.
On Oct 1, 3:05 pm, Derek Anderson <[EMAIL PROTECTED]> wrote:
> 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,
Re: Should Django have a road map?
On Mon, 2007-10-01 at 12:18 -0700, Joe wrote: [...] > 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. > 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
Re: Should Django have a road map?
On Mon, 2007-10-01 at 17:07 +0200, Stefan Matthias Aust wrote: > Joe, > > 2007/10/1, Joe <[EMAIL PROTECTED]>: > > [...] > > 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-users@googlegroups.com To unsubscribe from this group, send email to [EM
Re: Should Django have a road map?
On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > > 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. 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. > 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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
