On Wed, 2006-10-25 at 10:07 -0700, [EMAIL PROTECTED] wrote: > I was in the exact same boat a while back. You may be interested in > this thread: > > (http://groups.google.com/group/django-users/browse_thread/thread/69ad3da32daeb963/f54e6695f76fe73f#f54e6695f76fe73f). > > > I have been trying to get some momentum started on this front, but > haven't had any luck. I agree that things have been awfully quiet on > the development trunk, especially when there is so much code that > should be reviewed and merged. I can only assume that the developers > that call the shots are busy with there personal interests at the > moment. Many may respond to your question with something that says " > It needs real world testing", or "It will get done when it gets > done", both of which are a joke in my opinion. Most of the > projects have already seen allot of testing by the developers > themselves, and quite a few developers have taken the time work with > them. I wounder if Django itself went through a formal code review > and Q/A cycle before it was released? If so, who was the independant > firm that cerified it? I think it just worked good enough and was > pushed out. The folks that are on the "when it's ready" band > wagon should realize that software is never done. Or are you still > using punch cards?
I'm not sure if you are new to software development, new to open source development or merely frustrated because your personal itch is not being scratched. But this criticism does stand up to scrutiny. It would simply be unprofessional (and abnormal) software practice to dump a whole bunch of changes all at one in the main branch. The reason we have branches is so that various changes can be looked at in isolation. Notice how as people are testing, for example, the row-level permissions branch, they find bugs for that particular feature and Chris Long, the maintainer of that branch, fixes them. People don't have to worry too much that they are seeing some weird interaction between new features A, B and C. It is completely normal for code to be reviewed and in some sense "signed off" as acceptable for moving upstream, at least to some extent, before being merged into the main tree. It happens on every major open source project (and not just there). It doesn't require an independent firm -- you are constructing strawmen there -- but it does happen. You can see in the list archives and in blog posts by some of the Lawrence guys that Django did go through a "make it ready for release" phase prior to release. Whilst your frustration is, to some extent, understandable, please don't start throwing around clearly incorrect assertions like this. > Trying to test and develop against so many branches isn't practical. Yes it is. It happens a lot, both in Open Source and in the corporate world. It's not zero amounts of work, but neither is working on an unstable trunk. > For example, you could start writing an application on the RLP branch, > and would like to start using the schema evolution code. This is a > problem because that functionality isn't in the RLP branch. This > leaves you with two options: 1)Rip out the RLP code that you just > worked hard to create and then work with the schema evolution branch, > or, 2) Merge the two branches. But merging the two is really getting > out of line because it would be a branch of two development branches > that are built off of a development branch . You also get stuck with > trying to manage several version of Django. Yes, working against multiple branches at once is slightly trickier. Not insurmountable, but it does take some effort. However, somebody has to do it at some point in order to test things out. If somebody is in a position where they need this, they can help out by doing the merge of the relevant branches and helping us iron out the difficulties. > Now here is an idea t that will blow your mind. Why don't we just > merge these projects with the main development trunk, and allow > everyone to work with this code during there normal development cycle. You do realise that not all the branches can be merged just with "svn merge", right. Many of them affect the same places in the code and so will need careful attention as the changes are merged. You are offering to create a lot more work for the trunk maintainers, rather than seeing some of the benefits of parallel working streams that we have now. > Then when we run into issues/bugs they can be fixed in a cohesive > environment. It should be obvious that everyone would benefit by using > the same code base. When you think about it, isn't a development trunk > meant for developing new features and working out the kinks. Whenever a new feature is checked in, a bunch of related bugs start to be filed. It isn't always clear what caused those bugs, but fortunately, because we know what changed recently, so we have a few clues available to help us out. Your proposal is to basically churn the whole code base, so that when the flurry of new bugs arrive (and there will be a lot of tickets filed that range from wild feature requests to people confused about how to use something to actual bugs), it now becomes a complete Easter Egg hunt trying to find what might have caused it. Controlled, systematic releases into the trunk help mitigate that problem. It also means that those of fixing the bugs can slowly become familiar with the code changes one piece at a time, rather than having every file changed in the core as a result of possibly four of six different sub-projects. All of the Django source code branches are available to the public. It's not immediately clear why people think that trunk is going to be an infinitely better place to work than a branch that is synced with trunk once a week or once a fortnight or so. That just isn't true. So if a branch has the features you are after, use the branch. Some perspective would really help make this slightly difficult time easier for everybody. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-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 -~----------~----~----~----~------~----~------~--~---
