Sunday 21 February 2010 8:48:02 am

In January in Geneva it was announced that the public would no longer get maintenance releases and that such releases would only be available for eZ Publish Premium customers.

On the side of Premium it was said that this adds value to the subscription.

On the side of the community it was said that the .0 releases (released every 6 months) will be much more stable now because of the improved development process. Technically the community can also access eZ's SVN trunk, but of course it would then be hard to know which specific commit number represents what status of the CMS.

http://www.mugo.ca
Mugo Web, eZ Partner in Vancouver, Canada

Wednesday 24 February 2010 7:06:32 am

Hello,

This is a translation of the post I sent to ezpublish-france.fr about the point of view of Kristof Coomans:

EZ Systems announced in January, in Geneva, that the community will arrange no more version of maintenance of eZ Publish.

The reason behind this decision is the development of the paying offers (Partner Premium) proposed by eZ Systems. See the Peter Keung's comment above.

Even if, as indicates it Peter Keung, the quality of 2 annual versions put at the disposal of the community is better than in the past because of a better process of development, it remains not less true that this decision marks sharply an ebb of interest for the community on behalf of eZ Systems.

Beyond the economic interests which eZ Systems has to protect (what is understandable), this decision questions me all the more towards the following points:

1 °/ On good authority, eZ Systems tells to be conscious of the role and the impact of the activity of the community on its economic model: I site paul Wilson: «A strong community ecosystem is central to the future of eZ Systems. I think this can be taken as a given. Achieving this means finding ways for people to best gain and contribute value through their participation in the community.» - on May 25th, 2009.

2 °/ A new community site was recently born.: http: // share.ez.no

3 °/ A very recent call was thrown in the direction of the community for the translation of eZ Publish.

The very simple question that I arise is the following one:

After such a decision was taken by eZ Systems, for which interest the community can hope at the moment in return of its investment, whatever level it is ?

Today, my answer to this question is: versions of eZ Publish containing bugs that it becomes very difficult to maintain (see Peter Keung's same comment about the use of SVN to maintain up to date eZ Publish).

As things stand at the present, I admit to be in the incomprehension as for the contradictory position of eZ Systems and share the point of view of Kristof Coomans (in answer to Peter Keung's comment - see above).

Proposition:

The new biannual versions integrate the corrections of bugs but integrate new ones bound to the new systematically added features.

Wouldn't it thus be possible, for lack of enjoying versions of maintenance up to date, that when a new N version go out (in March and in September), a version of maintenance N-1 is put at the disposal of the community?

It has, it seems to me, the merit to protect the advantages of the paying solutions, while allowing the community to have a debug version, although late of a version because it will not integrate the new features of the version N.

Besides, wouldn't it be possible that a documentation detailed about the update of eZ Publish via SVN is published on-line ?

Regards,

Pascal

Ce qui embellit le désert c'est qu'il cache un puits... quelque part... (A. de Saint-Exupéry) - http://luxpopuli.fr/eZ-Publish

Wednesday 03 March 2010 9:44:39 pm

Technically the community can also access eZ's SVN trunk, but of course it would then be hard to know which specific commit number represents what status of the CMS.

What about tagging in SVN? This would make it easier for community members to get a specific version through SVN.

Regards Robin

I think that's kind of the point, they don't want to make it easy for the community?

www.dbinformatics.com.au

We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.

Thursday 04 March 2010 1:13:44 am

You're probably right Kristof, creating an official Community Manager position is a very obvious sign that eZ systems is turning its back to the community. I'm sure it actually is the very definition of this job :-)

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Thursday 04 March 2010 2:07:49 am

Everything about eZ Publish releases was as far as I know explained by Atila when he talked in Geneva about the new agile organisation we've been using for a few month: http://share.ez.no/blogs/ez/wrap-up-and-slides-of-the-2010-ez-winter-conference-in-geneva/atila-mellilo-ez-engineering-agile-organisation-methods-and-quality.

The summary is simple: 2 stable (for real) releases a year. .0 release will no longer be considered unstable, beta quality, but real production stuff, tested on every level. So far, I don't think anyone can say this was a failure.

The decision was indeed made not to release maintenance releases. They were mandatory before 4.2, since there were ALWAYS critical issues in them. Let's be honest. If a critical issue is located in one of them, a reverberation release might be published, but this situation hasn't shown up yet.

Regarding your proposal, it of course makes a lot of sense. I'm sure Nicolas will escalate it, but nothing has been made private, in regards to the source code, and as mentioned here, eZ publish can be patched from SVN, even though this does require some knowledge of it. I really can't tell if a decision will be made in that sense from us, but it is obvious that at least a few members of the community are more than able to assist everybody in exploiting the source code repository and fix critical issues in between releases.

Regarding the community aspect, it's not really an area where I can tell much. Nicolas will definitely come back at you later on about this.

And don't take me wrong: I'm a strong defendant of the community aspect of eZ publish, and will keep participating, even if it's not much, but business decisions still have to be made...

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Thursday 04 March 2010 2:49:03 am

I remain confident in the will of eZ Systems to serve its economic interests without going against those of the community. What does not have to forbid us to remain watchful ;-)

Absolutely ! That is one point of an uncommon business model: you have to take chances ;)

And trust me, these decisions are also debated among eZ systems employees.

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Thursday 04 March 2010 8:18:41 am

Dear community,

I am hoping, through this post, to make things clearer on this very topic. Please find my detailed answers below:

@kristof :

Please find some good information on how engineering currently works here :

http://share.ez.no/blogs/ez/wrap-up-and-slides-of-the-2010-ez-winter-conference-in-geneva/atila-mellilo-ez-engineering-agile-organisation-methods-and-quality

As you will note, things have heavily changed.

“I also can say I do not understand the reasoning they bring forward. If they need to make a maintenance release for eZ Publish Premium anyway, there is no additional cost in making it publicly available. I would think that eZ Systems should be able to ensure the quality of such a maintenance release for eZ Publish Premium.”

As you know, packaging a release is different from patching a piece of software. The eZ Publish Premium offer's interest resides in the patching of an eZ Publish instance. This is very different from packaging a full version of a software, the latter comprising, on top of applying a bunch of patches:

• a global QA run
• continuous development processes, including builds of all packages involved in a release
• a specific sprint in the development process where the QA team and the engineers exchange back and forth to reach the required quality level for a given release, be it minor or tagged as “maintenance”

“Announcing then on the other side to the community that the quality of the .0 releases will be more stable because of the improved development process, sounds to me like they are minimizing the importance of the former publicly available maintenance releases (which where equal to the maintenance releases for eZ Publish Premium) and also the quality thereof. “

I will go straight to the point here, sorry for the raw approach: I am afraid you miss realizing how much the development process of eZ Publish has changed. YES, the 'x.0' releases are production-ready and stable. NO, there is not anymore a need for an immediate reverberation release like in the past, because the quality of the 6-monthly releases is dramatically higher. So in short: NO, eZ is not minimizing the importance of the releases known as maintenance releases, we just made sure they are not mandatory anymore. I am sure every person working with eZ Publish is happy not to have to migrate to every minor version every 2 months, and rather focus on the major releases, every 6 months only. Isn't this facilitating the work of any community user of eZ Publish ?

@pascal :

“Even if, as indicates it Peter Keung, the quality of 2 annual versions put at the disposal of the community is better than in the past because of a better process of development, it remains not less true that this decision marks sharply an ebb of interest for the community on behalf of eZ Systems.”

I must confess I do not agree here Pascal. As a daily user of eZ Publish, and without Premium agreement (talking about share.ez.no here), I am very happy of the product's orientation towards a higher quality and better stability, which affects everybody in the ecosystem: community members, partners, end customers, all benefit without exception of the nowadays high-end quality of the eZ Publish. It indeed allows to not worry about upgrading or applying patches every 1 or 2 months. And I can tell you we are torturing the product on the community portal.

Also, as you know, I was appointed as Community Manager a few months ago. This discipline is a direct translation of eZ's focus and dedication to her community, and more generally to opensource. I am not working for free, meaning this move represents an investment for the company, which contradicts the idea of an ebb of interest. It is rather a HUGE CHANGE, very positive one, carrying a strong message. I think putting the community's history in perspective with the recent events will help all understand that eZ has never been as focused on her community as now. Do not fear changes, although often disturbing at first, they are made for the best. Finally, even the partner program was remolded to better suit the needs of freelancers and small to medium companies not willing or not able to engage a commercial relationship with eZ. This is yet another sign of eZ's commitment to her community: allowing for doing business within the community for free. This reworked part of the partner program is the Community Program, which I think deserves 20 minutes of everyone's attention: http://share.ez.no/community-program

“After such a decision was taken by eZ Systems, for which interest the community can hope at the moment in return of its investment, whatever level it is ?”

Continuing the explanation started above, eZ invests a lot in her product, engineering team. The product benefits from these investments, in turn beneficial to any member of the ecosystem. The product is available at all times, under different forms:

• packaged, every 6 months: major release
• packaged, between the 6-monthly releases, should a major issue arise
• in the public SVN repository, anytime, the latest version is present there.

I agree, extracting the product from SVN requires a few skills, that about any developer-lookalike has or can easily find around him. Should someone critically rely on the product to the point of needing bug-fixed versions more often than every 6 months, it probably means they are doing a substantial amount of business with it. So yes, if a 6-monthly migration is not often enough, and the involved team would not like, or can not extract the product from the public SVN repository, considering the Premium offer is an option. This is simply how eZ Systems makes a living, enabling them to sustainably grow, innovate, and share the constantly improved product with you guys. There has always been a vendor backing up eZ Publish, since the first minute, this is the model eZ chose. How can this be reproached ?

@robin :

SVN tagging actually exists, for every major branch:

• trunk : http://pubsvn.ez.no/nextgen/trunk/
• 4.2 stable : http://pubsvn.ez.no/nextgen/stable/4.2/
• 4.1 stable : http://pubsvn.ez.no/nextgen/stable/4.1/
• 4.0 stable : http://pubsvn.ez.no/nextgen/stable/4.0/
• more unstable branches are available there (down to 3.8!)

@brendan :

See answer to Robin above. It is easy. As easy as in any OSS project.

These remarks actually scare me a bit. Have you guys not ever taken a look at eZ Publish's public repository ? Anybody can get every single commit through email : http://lists.ez.no/mailman/listinfo/sdk-svn , to stay informed of what is going on at the most bleeding edge level in the product. That is useful, I am telling you.

@kristof:

As explained to Pascal above, the community focus has never been as big as nowadays. It is about time to re-assess one's consideration of the eZ Community, evacuate the accumulated frustration (which I do understand, please do not get me wrong). I tend to think you could directly benefit from one of this focus' facets : the Community Program ( http://share.ez.no/community-program ).

Thank you guy for this feedback. This is globally constructive, and as you have said this move lacked communication. We owe you apologies for this, we realize this did not help understand that it was a beneficial and positive one rather than harmful. Please continue this thread if you need to exchange more on the subject.

EDIT: this topic ressembles this one : http://share.ez.no/forums/general/roadmap-for-version-4.2.1/

Cheers and see your around the community!

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Thursday 04 March 2010 9:38:22 am

@roland

"I hope also the next releases will demonstrate that indeed, the quality of ".0" releases has significantly changed !"

We have experienced this, and appreciate it as the pain of upgrading between .0.x releases is not going to be missed. We have experienced much better quality in the 4.2 release than in previous ones, and look forward to more of the same.

http://www.thinkcreative.com
Turning Ideas Into Strategic Solutions

Thursday 04 March 2010 2:29:08 pm

Hi Gaetano,

I thought we already discussed this.

If at somepoint we would make a bad ".0" release, a one that bad that it would be prejudicial for all to keep it as an available package for the public, we would of course consider to replace this by an updated package. This is not standard maintenance, so i would not use the term "major issue" (which relates too much to our support services), but more "exceptionnal issue in the release quality". For instance a release that is broken and that can not be installed, even for a simple evaluation.

Hopefully, this will not arrive, but we can not be 100% sure about that.

If it shall arrive, it might be related to a security issue, however, to your question, no, all security-related defects would not fall into that category at all !

Cheers,

Roland

--
Roland Benedetti
eZ Systems, Product Management

Thursday 04 March 2010 10:41:17 pm

Thanks to Roland and Nicolas for the detailed info, too bad that it came as a surprise to some of us.

Gaetano wrote:

Any takers?

Or does it sound like too much time needed with an unclear return on investment?

The community maintenance releases might indeed be a tricky and difficult thing. Not only do they need to get compiled, but also update procedures and instructions will have to be prepared when new major release is out, etc.

Three questions regarding this issue:

1. How many man-hours (roughly, approximately) have been required to release a bug-fix release so far?
2. Would eZ be willing to help the community or whoever takes up this task to become good at it? Share experiences, procedures, previous mistakes, etc? ;)
3. Since eZ is interested in professional services, how much would it cost (roughly) to have eZ maintain the bugfix releases (say per release) every one-two months? Maybe we can open-fund it? ;) Would eZ be interested? ;)

Cheers,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu