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