On Sun, 2004-09-19 at 22:35, email@example.com wrote:
I did not come up with the idea to revert the web2 commit on the spot. Commits which introduce broken tests have always been fair game for reversion. Since the web2 tests were _new_, perhaps a different policy might apply. I'd certainly be willing to entertain arguments to that effect to decide what should be done in the future. I do not think reverting the commit was unreasonable here, though.
No, I don't think that a different policy should apply - revision history exists for a reason.
This point is worth emphasizing. We don't have a very rigorous process in place for development, but this has always been the case - trunk should be in a working state at all times. If you check in code that breaks the tests, it is at the discretion of any other developer to decide that your code is toast: it doesn't matter if you are available on IRC in real time. You can fix your breakages locally, without everyone else waiting for you.
There is no release of Nevow.
There is. Although it's old. This is a very good reason for not releasing twisted.web2. Fortunately, since we have decoupled releases now, it doesn't affect anything else.
The first release of Twisted 2.0 will not be decoupled. It is important that we don't treat the releases as decoupled until we have actually successfully made at least one decoupled release of each project. I don't think this policy will change when project release cycles are separated though.
Even when trunk is in a completely working state, it is still difficult to get a release done right now, so I see no reason to accept tests which do not import, or tests which fail, in trunk. If you want to add a dependency on something new, this needs to be discussed before checking in.
Most of Twisted web2 does not/will not depend on Nevow. Generation of some server-generated pages does/will. Those tests should just be skipped if Nevow isn't installed. That they aren't is an issue, sure.
Do those server-side pages have simple, non-nevow fallbacks? If they can't, then perhaps we should be considering a merged release.
If you want to have any input on these technical matters I suggest participating on the twisted-web mailing list instead of just randomly removing code.
Personally I believe this is worth discussing generally, because these are not "web development" issues, although they do touch web code - I don't subscribe to twisted-web because I'm not interested in the particulars of HTTP rfc compliance or url argument parsing, but I most certainly *am* interested in circular dependencies threading through libraries which are distributed separately. There is perhaps a larger discussion here about the relationship between twisted-web and nevow, and Twisted and Divmod in general, that needs to happen on divmod-dev.
I am happy with my current level of avoidance of twisted web, discounting this most recent event. I hope that in the future web2 can be handled in such a way that it is not disruptive to those of us who are not interested in it.
Maybe I need to be a little more involved than I have been. I find the presence of both web and web2 in the same source tree a little upsetting - this harkens back the web.widgets / web.domtemplate / web.woven API disaster, which still haunts us.
Let's try to figure out which web server we are supporting and then actually support it, rather than having 9 different half-assed, half-supported implementations floating around.