|
Friday 05 January 2007 6:15:30 am
I question (politely) the checks and balances which weigh the actual resulting implementation of another's needed features, like the ones in question in this thread is (and will continue to be the opinion of me and apparently others of the community) of poor design and implements at the very least the functionality in a way that is of most benefit to eZ systems not the community. #1 - I welcome the best of eZ system's additions to eZ publish. This is not one of them. #2 - <i>"As we also take a great deal of responsibility for clients buying eZ Publish Now, we don't allow these clients to change content class definitions. That have the potential to easily break the site completely."</i> eZ systems implemented features which benefit them and their goals to specifically support good features (done badly) in eZ publish. Where these features placed in a specification available on ez.no? I think that at least the settings should have been omitted from eZ publish by default as the functionality added to 3.9 uses them. #3 - <i>"I agree that this change in the default configuration is not of a big benefit to the community. Frankly, it was never meant to be either."</i> Which I think is why many in the community are upset that the community has little resolve to prevent features which are implemented in a way which creates a natural disadvantage and crippled the community product/release. I think you should have implemented a flexible design for these features and not a static one which cripples eZ publish by default. You <b>are</b> telling users to get ready to go through a lot just to experiment with a web app package, it's a great way to choke off new users to the community. I continue to be confused with why the community is a second concern when implementing functionality in such a clearly tacked on way which hurts the community but not be concerned about the negative feature(s) introduced as a direct side affect of the implementation chosen by eZ systems. An no one wants to fork eZ, those who do are mad. We simple do not want negative features to be introduced like this ... ever. It's stunts like this that drive users away (to a competitor) and pressure vendors other than eZ systems. <i>We thought the community would think that was okay, but maybe we were wrong...</i> I think you did not go far enough with the design of the implementation. It's a few patched on additions that can be done cheeply and quickly but not completely or well. It's just enough for you and not nearly enough (features/design) for the rest of us to really use well. <i>"Anyway, this is all about a (small) configuration issue. It is anyway possible for us to add this configuration settings to eZ Publish Now clients by a simple script. It is a little bit hassle, but it is something we can live with. It won't be that much effort for us to comply with you (the community) in this particularly case. I'll put this on the to-do list for 3.9.1</i> This is not limited to a small configuration issue. It speaks to the gaps between the community and eZ systems, both in terms of communication of issues surrounding this addition, the testing and warning users of the new problems introduced for them by eZ systems. It speaks to how little thought we receive in times like this where you could have implemented most of these settings additions in your eZ Publish Now Service (scripts), yet instead <i>you kinda did the least possible</i> and just dumped as sizeable load of bad ideas in setting and code form (for others than eZ systems itself) into eZ publish trunk. <i>Regarding "the community release", I don't feel that this issue makes that a contradiction. AFAIK, we have incorporated more community wishes in this release than what we have done in any previous release. However, I would also admit that we where not able to include as many pathes and community contributions as we hoped for when we started the 3.9 release cycle. That is something we need to work on.</i> It just shows the distance between the average member in the community not directly associated with eZ systems business model and the open source / free community. eZ releases free / open source software but their development model is very proprietary. The development of eZ publish come from or goes through eZ systems primarily, the development of eZ publish is a much more distant activity which really happens offline and is rarely directly engaging of the community (not counting eZ partners or eZ celebs)
The almost always stale information on the page, http://ez.no/community/developer
is a clear sign of this. Where it's a side thought for advertising but not collaboration.
The developer section recently added toolbar to the community page is little more
than a page to advertise eZ publish not provide developer resources to see this feature's design being implemented and share a discussion with eZ systems before release. Any developer quickly sees clearly the break between collaborative development and observer community. eZ community overall observe and reacts to compensate not collaborate to the public at large, you have to know someone to get in good to get new features or design issues discussed offline. <i>"Regarding response time, I am sorry. Of course we care what the community things."</i> I respect your post on the subject and thank you for it. Please don't lead the community into these pitfalls so silently with such an anticipated release. We really might have be able to avoid these threads after a major release. <b>Summary</b>
- Please don't avoided how badly implemented it all of the individual features are from our perspective and don't tread on eZ publish.
- It's a bad implementation from a settings addition level, to a setup level, to a runtime / debug level, from a user role and permission level, to a template level, heck to a php kernel level .. and i really want the whole thing to be addressed properly. I still believe it should be implemented at a role permissions level not at a site/access level.
- It's slips like this that lead to the worst parts of eZ
- This subsystem tacked on in this way could have the settings striped out of the default package but that still leaves the parts of the features that are bad not addressed.
- I have to use the bad designs that make it into eZ publish ...
- I don't mean to be mean, and perhaps it's my fault for not saying anything this whole time till recently even when I knew . but it's just ... retarded implementation overall for both parties.
- and what are the odds it will be replaced with what i describe with polish in 2007, i hope but i fear the past may overtake the matter all to quickly. and part of me, is screaming that, where this all is lacking wasn't kept in check and still feels like a blind person being guided by their companion into harms way (who can revert the evil that regardless of intent is introduced into eZ publish's svn).
//kracker
<i>I support the community, I've never known ..</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|
