Zope support through the community: sorting
Zopistas, there is currently a heaty and controversial debate at http://dev.zope.org/Wikis/DevSite/Proposals/ExtendedDTMLSorting It is concerned with Oleg's great "Sorting Patch" that provides (almost) general, easy to use sorting facilities all over Zope's framework (DTML, Python Scripts, External Methods, ZPT, ....). There seems to be danger that this great support through a community member will have a fate similar to Tino's "in" patch: that the incorporation into the Zope core is far too long delayed because important DC people fear "feature bloat". If you are interested in sorting along the lines * case sensitive/insensitive * ascending/descending * locale aware * multi-column you should go to the above site and voice your opinion. As a general note: It seems to me that DC is far too reluctant to accept contributions to Zope from community members: * patches fixing bugs * patches implementing missing but useful features In my view * bug fixing patches should always be accepted unless the patch is not easily understandable. * feature patches should be accepted, if it makes Zope more consistent (as the upcoming "urlparam_expr" patch) or easier to use (as Oleg's sorting patch or Tino's in patch). Great reluctance towards these contributions risks Zope to lose community support. I can tell from experience the frustration caused by DC ignoring contributions. I invested considerable time to file several important ZCatalog bug reports with patches into the collector for Zope 2.1.6, just to see them ignored in all versions of Zope 2.2. Only for Zope 2.3.1, the issues have been addressed. I still advice people to file bug reports and patches into the Collector, but personnaly I already start to think whether it is worth the effort.... Dieter
On Fri, 13 Apr 2001, Dieter Maurer wrote:
there is currently a heaty and controversial debate at http://dev.zope.org/Wikis/DevSite/Proposals/ExtendedDTMLSorting
It is concerned with Oleg's great "Sorting Patch" that provides (almost) general, easy to use sorting facilities all over Zope's framework (DTML, Python Scripts, External Methods, ZPT, ....).
Thank you for support!
It seems to me that DC is far too reluctant to accept contributions to Zope from community members:
* patches fixing bugs * patches implementing missing but useful features
In my view
* bug fixing patches should always be accepted unless the patch is not easily understandable.
* feature patches should be accepted, if it makes Zope more consistent
This is where the problem lies - DC feels like my patch is not consistent. It is exccessive feature; it has no companion patch in dtml-tree sort, etc. :) Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
There seems to be danger that this great support through a community member will have a fate similar to Tino's "in" patch:
that the incorporation into the Zope core is far too long delayed because important DC people fear "feature bloat".
It is not "feature bloat" in this case that is the main issue, it is (as stated in my comments in the proposal) the complexity this adds. Please understand that we are sometimes put in a difficult position - we get beaten up all the time about "zope being too complex", then get beaten up by other folks when we question a feature because we don't want to add to the complexity :) I would prefer that this discussion continue in the proposal area rather than on the list.
If you are interested in sorting along the lines
* case sensitive/insensitive * ascending/descending * locale aware * multi-column
you should go to the above site and voice your opinion.
You are correct.
As a general note:
It seems to me that DC is far too reluctant to accept contributions to Zope from community members:
* patches fixing bugs * patches implementing missing but useful features
I disagree, though I can see how it comes across that way. I think that a lack of resources to respond quickly enough plays a large part (but that is largely invisible to the community, so I can't fault you for your perception).
In my view
* bug fixing patches should always be accepted unless the patch is not easily understandable.
* feature patches should be accepted, if it makes Zope more consistent (as the upcoming "urlparam_expr" patch) or easier to use (as Oleg's sorting patch or Tino's in patch).
Great reluctance towards these contributions risks Zope to lose community support.
I agree with the first point, and it is generally true though there is often currently too much lag time. There will be good news forthcoming that will help that significantly soon. The second point is subjective - what is "more consistent" to one is sometimes "more inscrutible" to others. The whole point of the Fishbowl is to help us all come to smart decisions and reasonable compromises on such things. The Fishbowl also suffers a certain amount of neglect - which is another thing that we are trying to rectify. The Good News alluded to should help that a bit as well. I assure you that we are aware of, and not happy about, the frustrations you are feeling, but we _are_ working on fixing the process problems that are causing that.
I can tell from experience the frustration caused by DC ignoring contributions.
I invested considerable time to file several important ZCatalog bug reports with patches into the collector for Zope 2.1.6, just to see them ignored in all versions of Zope 2.2. Only for Zope 2.3.1, the issues have been addressed.
I still advice people to file bug reports and patches into the Collector, but personnaly I already start to think whether it is worth the effort....
It is worth the effort. I wish that we had a staff of dedicated Collector sweepers to make sure that every issue was taken care of quickly - we currently don't have that (yet! stay tuned). Right now, chances are that if there is any Collector sweeping being done it is likely to be me doing it, and that doesn't scale nearly enough to deal with everything in a timely manner. That will be changing. But in the meantime (not long), please understand that there is no great conspiracy against incorporating patches or features - we are simply trying to the best we can with what we have. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
It is not "feature bloat" in this case that is the main issue, it is (as stated in my comments in the proposal) the complexity this adds. Please understand that we are sometimes put in a difficult position - we get beaten up all the time about "zope being too complex", then get beaten up by other folks when we question a feature because we don't want to add to the complexity :)
I feel your words like the neverending discussion between windoze and unixes ......my opinion is that if you want to do powerful things you need , or you have to develop, powerful stuff. Personally i come from the database world where things like sorting are very important. And where is the complexity? If you don't need that feature, simply don't use it. If with your words you mean the complexity of the code, i'm sure that most people said "zope is too complex" when the accompainig documentation was too old to be useful and when the source code wasn't commented a lot ...but it's one issue for many open source projects, not only for zope...I don't think other projects stops introducing new features in that situation, especially when they are really useful as the Oleg's one I think that's more difficult to find an application where a powerful sort doesn't help. :-) I'm sorry for my bad english. azazel
I feel your words like the neverending discussion between windoze and unixes ......my opinion is that if you want to do powerful things you need , or you have to develop, powerful stuff. Personally i come from the database world where things like sorting are very important. And where is the complexity? If you don't need that feature, simply don't use it. If with your words you mean the complexity of the code, i'm sure that most people said "zope is too complex" when the accompainig documentation was too old to be useful and when the source code wasn't commented a lot ...but it's one issue for many open source projects, not only for zope...I don't think other projects stops introducing new features in that situation, especially when they are really useful as the Oleg's one
I think that's more difficult to find an application where a powerful sort doesn't help. :-)
I am not arguing the requirement or the usefulness of what Oleg has done, I'm arguing the proposed implementation. For those who are following this thread, I've added a comment to the proposal with an idea that I think may be a good solution that could make everyone happy: http://dev.zope.org/Wikis/DevSite/Proposals/ExtendedDTMLSorting If not then we'll go back to the drawing board, but this is what the Fishbowl is _for_ folks. It is for providing an open forum for everyone interested to champion their agendas and to come to sound, well thought out (and sometimes well argued) decisions. And it usually works, which is what makes it worth all of these black eyes and lumps on my head... :) Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd writes:
There seems to be danger that this great support through a community member will have a fate similar to Tino's "in" patch:
that the incorporation into the Zope core is far too long delayed because important DC people fear "feature bloat".
It is not "feature bloat" in this case that is the main issue, it is (as stated in my comments in the proposal) the complexity this adds. But the added complexity is really small: about 10 to 15 lines of description:
Instead of "sort=col,col,col,..." you now have "sort=colsort,colsort,colsort,..." with "colsort" either * col * col/compare * col/compare/direction
Please understand that we are sometimes put in a difficult position - we get beaten up all the time about "zope being too complex", then get beaten up by other folks when we question a feature because we don't want to add to the complexity :) I think, I have addressed this in a proposal comment:
* high level sort support adds (a bit of) complexity * if you need advanced sorting (and already case-insensitve sort is currently advanced!) then, without high level sort support, you need a very complex solution (in Python). * many Zope users need better sort support - e.g. case insensitive sort (--> mailing list archives), locale aware sorts (--> users in South America, Europe, Asia). They either are/get advanced Python programmers or feel that Zope is far too complex, because simple things are not easy to get. Accepting the patch will not increase but decrease the complexity for all people that need better sort support. I think this is the majority.
....
DM: In my view
* bug fixing patches should always be accepted unless the patch is not easily understandable.
* feature patches should be accepted, if it makes Zope more consistent (as the upcoming "urlparam_expr" patch) or easier to use (as Oleg's sorting patch or Tino's in patch).
Great reluctance towards these contributions risks Zope to lose community support. BL: I agree with the first point, and it is generally true though there is often currently too much lag time. There will be good news forthcoming that will help that significantly soon.
The second point is subjective - what is "more consistent" to one is sometimes "more inscrutible" to others. Yes, sometimes. But often, it should be easy to come to an agreement.
For example: Zope DTML attributes often come in two variants: "branches/branches_expr", "type/type_expr", "sort/sort_expr",.... It has a reason that this is so... Sometimes, only a single attribute is there. This can have two reasons: the second one is not needed or it was forgotten or not implemented due to resource shortage at the time of implementation. Now, people stumble against that lack (me, for example against the missing "urlparam_expr"). They may say, hay, I could help to make Zope better (I did not, in this case, but used a cookie - with a comment about the badly designed "urlparam" in the source of my code) and file a patch into the Collector. It should not be difficult to see that Zope gets more consistent with such a patch. I think, it should be easy, too, for Oleg's patch: The usefulness/complexity ratio is extremely good. Nevertheless, I expected it would make problems and adviced him to make his features alvailable in an easy to use external method such that the Zope community is less dependent on DC in this respect.
BL: The whole point of the Fishbowl is to help us all come to smart decisions and reasonable compromises on such things. In my view, the Fishbowl should be used only for big things.
I can understand, that projects like Tino's patch or "Administration and Configuration" go through the Fishbowl. Everything, that has either big impact or requires extensive resources with DC. I would be seriously concerned, if there would be an "urlparam_expr" project in the Fishbowl before this patch could be accepted. I would also not have expected a Fishbowl project for Oleg's patch. The patch is local, finished. Everything DC needs to do is apply it (I know, this is already done in CVS) and add a dozen lines in the Online Help and the Zope book. The resource consumption with the Fishbowl project is one to two orders of magnitude larger than this.
DM: I still advice people to file bug reports and patches into the Collector, but personnaly I already start to think whether it is worth the effort....
BL: It is worth the effort. .... resource shortage to sweep the Collector ....
That will be changing. Good!
I will be (a bit) patient.
....
Dieter
there is currently a heaty and controversial debate at
http://dev.zope.org/Wikis/DevSite/Proposals/ExtendedDTMLSorting
Cool... that's what it's there for. Also probably means the right decision will be reached...
There seems to be danger that this great support through a community member will have a fate similar to Tino's "in" patch:
What has happened to that?
It seems to me that DC is far too reluctant to accept contributions to Zope from community members:
* patches fixing bugs * patches implementing missing but useful features
Nah, they just wanna have confidence in Zope so that everyone else can have confidence in it. It's a shame if people see that as reluctance, but does DC really strike you as a group not interested in the community? I think DC's VC (acronym overload ;-) based open sourcing Zope on levereging the community in exactly this way so I'm sure it's not like that...
* bug fixing patches should always be accepted unless the patch is not easily understandable.
Well, that's a tough definition. Maybe DC's definition of 'understandable' is different, given they diudn't write the patches ;-)
* feature patches should be accepted, if it makes Zope more consistent (as the upcoming "urlparam_expr" patch)
What a horrible name :-( How does that make Zope more consistent?
or easier to use (as Oleg's sorting patch or Tino's in patch).
You know I agree with that ;-)
I invested considerable time to file several important ZCatalog bug reports with patches into the collector for Zope 2.1.6, just to see them ignored in all versions of Zope 2.2. Only for Zope 2.3.1, the issues have been addressed.
Hmmm, that's a little surprising. Are you sure your patches solved the problem in the way that would bring most long term good? I much prefer a ZCatalog which now has unit tests and timing measurements...
I still advice people to file bug reports and patches into the Collector, but personnaly I already start to think whether it is worth the effort....
Hmmm... I'd like to anyone get the kindof response you do from the collector from someone like Microsoft or Oracle ;-) cheers, Chris (who doesn't like all this DC bashing on the lists given how much easier they make my life!)
There seems to be danger that this great support through a community member will have a fate similar to Tino's "in" patch:
What has happened to that?
Evan put up a proposal derived from Tino's patch at http://dev.zope.org/Wikis/DevSite/Proposals/PrefixedTagVariables ... it's not quite the same but it serves the same purpose.
I invested considerable time to file several important ZCatalog bug reports with patches into the collector for Zope 2.1.6, just to see them ignored in all versions of Zope 2.2. Only for Zope 2.3.1, the issues have been addressed.
Hmmm, that's a little surprising. Are you sure your patches solved the problem in the way that would bring most long term good? I much prefer a ZCatalog which now has unit tests and timing measurements...
Actually, Dieter got a raw deal from DC on those patches... they did the right thing, and variations on his patches actually made it in to the Catalog (finally) after we were able to get the Catalog "ownership" straightened out enough to make some poor sap nominally responsible for it. That's currently me. ;-) Hopefully some stuff currently being fleshed out at DC will make contribution to Zope materially easier for some community members. - C
participants (6)
-
aZaZel -
Brian Lloyd -
Chris McDonough -
Chris Withers -
Dieter Maurer -
Oleg Broytmann