Hi, Jorge et al. On Sunday March 22, 2009 22:02:42 Jorge Vargas wrote: > > If we're supposed to be in a feature-freeze, that's for people to be > > confident that from now on things aren't going to change, unless a > > critical bug has to be fixed, so that they can start building software > > and writing about TG2 with the guarantee that their product isn't going > > to expire some days later. > > I think you missed the point either here or of feature freeze. if the > API is keep intact (which from talking to precious) I believe it was. > then the change can go into the feature freeze and nothing should > break. And it is not a big problem. This isn't really a new feature is > spliting it in half. And making the old one call the 2 new ones. It's > more like refractoring and the first rule of refractoring is that you > should not break anything.
Of course the API changed! There are two new modules and two new functions. And of course it's a refactoring. Nobody here said the opposite. I agree, it's a much needed refactoring, but it's changing the API and isn't fixing a bug, so from my point of view it shouldn't be applied in a feature-frozen branch. If you think that I missed the point of a feature freeze, then I guess we have different concepts of what it is. Mine is that nothing must change unless there's a bug to be fixed (enhancements out); and I'd say that I'm not alone. > > On the other hand, independent of the article I wrote, I think we must > > comply with the feature freeze strictly, specially in non-trivial changes > > like this (splitting a function into three ones, defined in newly-created > > modules each). > > again that is not feature freeze it's just code cleanup, this is as > harmless as splitting a file in two "cleanup" sounds nicer, agreed. But, well, you can describe it as "refactoring", "enhancement", etc... But not as a "cleanup". Where's the "cleanup"? I repeat, I support the change, I think it makes sense, I think it's absolutely necessary. But I'm opposed to the following things in a feature freeze: 1.- Adding features (as the name implies), 2.- Changing the API. Even if it's backwards compatible and thus won't break the software, it will definitely outdate text written relying on the part of the API that changed. > > The more complex a change is, the more chances to introduce a bug. And at > > this point we shouldn't take the risk of introducing bugs, but just fix > > the remaining ones. > > Right I do agree with you on this, but from Chris commit history I > think we can all agree he has never broken the trunk. Chris P is a brilliant developer, I know, but it's not about who makes the changes, it's about we're all human -- We are all error-prone. The thing is that at this point we can't afford making mistakes. "If it ain't broken, don't fix it" should be our motto for the 2.0 branch -- there we should fix broken stuff, not inefficient stuff. The 2.1 branch should be to fix both broken and inefficient stuff. > > Finally, I think this change has to be moved to the upcoming 2.1 branch > > (trunk, when there's a 2.0 branch). I love the idea, I think think it's > > reasonable, but I think it's too late to go in v2.0. Otherwise, this will > > be bad for PRs. > > So the final decision on this is to keep it out? because that just > threw a snowball on me. "Keep it out"? Who suggested that? I suggested that it was moved to the 2.1 branch, not discarded. > In order to get started with the new turbogears.org we need pages 0.1 > released which now depends on this, which means we need TG2.1 which is > unreleased, which means I need to either break the security policy of > the server (installing unreleased software) or install a hacked > version of TG2.0rc1 in order to get this going. I understand the problem, and I'm sorry that this inefficiency was found this late. > And as I said above this is all api stable, nothing will break with > the FIRST stage of the changes (needed for pages) the second set of > changes should be 2.1 only. It wouldn't be stable if it changed. Stable is stable. I agree that Chris' changeset works and is a backwards compatible API change, as well as that I didn't find a bug in it. But: 1.- It's not only about the software being backwards compatible. It's about having an stable API to give people the confidence that they can write text on its current API which won't get outdated a few days later. 2.- If it ain't broken, don't fix it. You'd take the risk of introducing bugs. Cheers. -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
