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 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 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 -~----------~----~----~----~------~----~------~--~---
