Development on 3.5+

[Hannes Papenberg]

Hi folks,
it has been a month now since 3.4.0 has been released and I'm wondering
when we can pick up on development again. There was a time when we aimed
for a minor release every 6 months and so far we either delivered a
totally botched release or it took greatly longer than expected. At the
same time, a lot of people are talking about Joomla 4.0 and we hit
barriers in our code over and over again. But instead of working on
future releases, we currently all sit there like rabbits in front of a
snake and look at the latest release. We currently act like one of those
prejudices about construction sites: One is working and 10 people are
watching.

Yes, it is a problem when a release is not optimal and breaks some stuff
and yes, we have to fix those things. But the fixes for the bugs in
3.4.0 were coded and tested by maybe 5-10 people. What did all the
others do during that time? Or should I come to the VERY bad assumption
that the whole development of Joomla is based only on the shoulders of
those few people?

If we really aim for a minor release (and with actual features in it)
every 6 months, then we can't waste 1-2 months before the release and
another one afterwards during which no serious PRs are handled. So far
we the development went like this:

- Pew, the last release was really exhausting. Lets take a break for a
month.
- Ok, so what are the plans for the next minor release again? Hmm, ok,
lets discuss that.
- Discussion takes another month.
- Start coding. Get delayed because of personal reasons. Provide a PR.
Have one or two people stop that PR since they could write it even
better than the original guy, you just have to wait a bit.
- "No, we can't merge anything anymore, we are to close to the release"
(about 1-2 months before the release)
- Release
- Pew, the last relese was really exhausting...

And that process doesn't even take the frequent "4.0/5.0/whatever.0 is
going to be so great if we implement this" discussions into account.

I've said it before and I'm saying it again: Please start parallel
development. We have people that volunteered to be release managers.
These people should get their branch in which they oversee the work for
that release, keep it in sync with staging and make sure that
contributions are accepted even if right now others are releasing a new
version. We would have to develop at least 3.5, 3.6 and most likely even
3.7 in parallel in order to both achieve high quality releases and
releases filled with note-worthy features.

At the same time we have a HUGE amount of legacy code that we need to
clean up for 4.0. I don't care if you guys are really going to delay 4.0
until everything is rewritten or not, but I want to have a branch where
I can finally remove all those $_something vars and methods. Where I can
clean up all the JError stuff and remove all that legacy code.

All that said: What do I have to do to make this happen? I am offering
you my time to do the grunt work for something like that.

Regards,
Hannes

[Leo Lammeirnk]

Missing this? "A Half-Baked Experiment" That for sure should have grabbed your (!) attention since it is so hugely important?

[sovainfo]

Looking at the roadmap it means removing the other extensions. Sofar only for messages a repository was created. What does it take to create the other ones?

And where can I find the lessons learned from weblinks or any information about decisions?

[dgt41]

A good reading will be https://github.com/joomla-extensions/weblinks/issues?q=is%3Aissue+is%3Aclosed
together with the open issues still there

[Allrude]

Have you even read what Hannes wrote Leo ? that and Michael experiments are to different things, both meant to help us get a better Joomla.

Please don't frustrate volunteers like Hannes who offer there time to help and ask for the right environment to get things rolling

I have seen you comments and discussions in the past years and find them often (to say the least) not very helpful

Some people might even consider you a troll, 

so don't react immediately negative when Hannes  ays or preposes something just because you and he had different opinions in the past

Regards 

Ruud 

Op woensdag 25 maart 2015 16:35:12 UTC+1 schreef Leo Lammerink:

[Hannes Papenberg]

It would be REALLY bad if the only features of the next 2 minor releases
would be to remove further core extensions. I hope that that roadmap is
not valid anymore, because it would mean that the code to rewrite the
routing in Joomla has to wait another 2 years until it is going to get
merged. Considering that it is waiting for that for the last 3 months
already, that would be bad news. The new media manager, although indeed
not ready yet, also wont need another 2.5 years to be brought up to par
with our code quality standards.

Based on those facts, I think it is safe to say that the roadmap will
not happen in that way and that it is not possible for a project like
ours to plan 3.5 years into the future. What we can do however is to
commit to delivering for example 3 releases in the next 1.5 years, 3.5,
3.6 and 4.0 if we start working on each of those now. 3.5 could contain
removing com_messages, improving the GUI a bit, implementing the new
routing and improving our unittests by ~10%. 3.6 could include the new
media manager and new MVC classes and 4.0 would aim at reviewing the
backend in terms of useability and creating a new, better concept for
the backend. From my perspective, those are reachable goals that could
be reached in 1/2, 1 or 1.5 years respectively and where people can work
on right now and right away.

Hannes

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.

[Roberto Segura]

Hi Hannes,

We have already discussed this through Skype and I told you everything that is explained here so it's a bit surprising to see this posts. I'll use it to try to explain to the community what is required and expected for version 3.5.

I'm happy to see you so interested in moving things and willing to contribute. Thanks for that. All that energy will be needed and welcome once the things are prepared.

First of all Joomla v3.4.1 has been released 4 days ago. Please keep calm. As far as I know the PLT is the most interested in releasing v3.5 faster than v3.4.

What is blocking us? I'll try to explain it. Summary: is my fault.

The main thing we want for v3.5 is to have a unique rendering system for everything:

- Views (the main issue)
- Modules
- Plugins
- Fields

The goal is to make sure that everything in joomla can be overriden and (if possible) using the same way. And that's where we are now. I've been discussing with George about the best way to achieve this mainly because backwards compatibility. The original idea was to use current JLayout with some improvements but ensuring that a custom renderer can be used to replace it in the future with a more advanced system (which is the natural evolution).

For that there are mainly two issues:

- Current layouts are not receiving the same kind of data. Ideally we should use arrays but mainly in views the view is being passed to layouts and view functions are used inside.
- Linked to the previous issue is that existing overrides have to work with any system that we use.

So the options are:

- Find the way to make JLayout B/C with current overrides.
- Check if an override exists for the current view and if so use the current rendering system. If not switch to the new rendering system.

Additionaly if we are going to change the rendering system we may use a better designed rendering system using interfaces to allow developers to replace it with any other rendering system already available like Twig, Blade or whatever developers want to use. My original idea was to create something like Michael did in his Joomla Next. A Joomla rendered based in the current JLayout but architechturally improved.

Once that is solved there is a ton of issues to create and assign. I want to create tons of small tasks like "Convert field to Layout", "Convert module to Layout", etc. Anybody without needing to understand the main concept will be able to collaborate picking any of those small tasks.

So the steps are:

1. Prepare and test the rendering system.
2. Migrate one of the different parts that need to use the new renderer to use them as example to follow to other devs.
3. Create the documentation to spread how this new rendering system works and has to be used.
4. Create the small tasks
5. Get the people working on the tasks.

My idea was that to be able to "disconnect" actively from the development at point 4 and then be able to review other features that people wants to see in v3.5 like:

- New routing system
- New media manager
- Core CCK.

I hope that 2 first are inside. Third is on the air.

I think that explains it quite well.

As I have told you through Skype life rules and I have started to collaborate with a new company so I've been trying to understand their team, their workflow and what is expected from me. Additionally I'm trying to clean my pending jobs queue. I need to settle things to make sure that I have the stability required to manage v3.5 properly. That's is mainly why I've been searching for a stable job. We don't receive money for contributing to Joomla and everybody needs to mix his daily job with the project. I hope people understands that.

So please keep that energy up but avoid talking like the the world is going to end tomorrow. There is a plan and v3.5 will be great.

See you in the IDE.

[Bakual]

We could start parallel development if the release managers wanted to do that. So far, it wasn't something that was requested from them. And I don't see a reason to start 3.6 already with code merging. Now it's the time to think what 3.6 may be, and Chris is already doing that actively. There may even be a code sprint to prepare things in a fork and then create the PRs when needed. This is actually what Roberto did with his frontend team for 3.5.

So parallel development happens already as of today. There was work done for 3.5 and already is done for 3.6. Some of your own work may end up in 3.5 as well.
Development doesn't only start when there is a branch created to merge things. It starts much earlier ;)

[Hannes Papenberg]

Hello Roberto,
thank you for your reply. Let me make clear that I'm not criticising
your work or the speed in which you are approaching the whole topic. My
post was not so much aimed at "When are we starting development of 3.5?"
(although it was the trigger for my mail) but an attempt to point the
problem in our system. I don't want to say "error", but it is at least a
"problem".

The problem that I see is, that we are developing very linearly. Develop
something, release it and only after that release you take a look what
could come next, who should work on this, etc. At the same time we have
features that will not be done in a 6 or 12 months-period and those that
are willing to work on such a feature so far were told "Build it and
only after you've done that, we will take a look". There are VERY few
people that will invest a year of their spare time when they aren't even
assured that their work is valued, will get considered and that they
will get support from those making the decisions.

Long story short: We need to have versions developed in parallel with
release managers who are "responsible" for this and ONLY this version.
We need those people to be able to calmly stand at the sideline, even
when there are issues in the latest release and concentrate on their
release that maybe is another 12 months down the road. We need to have a
3.5-dev AND a 3.6-dev branch now and as I said, I really would love to
see a 4.0-dev branch, too. And we need seperate people that manage each
of those branches. Only concentrating on the next release, regardless if
it is a minor- or a patch-release is not going to work.

Hannes

[Michael Babker]

I actually agree with you for the most part.  But I do have one caveat.  The project has historically been working on or maintaining 2-3 major versions of software for most of it's life (I'd say there was a short overlap of when 1.0 and 1.5 were supported while 1.6 was in development and likewise for 1.5 and 2.5 with 3.0).  These last few months are the first time the project has actually only had a single major version on its plate.  I know I for one am actually somewhat relieved about this.  Even though it does mean we're stagnating a bit on planning for and preparing our future, I think the break is somewhat needed for those who've been involved for the last few years, especially if we'd like them to be involved going forward.  I think we're naturally starting to get antsy about putting a vision together for a new major version, evidenced by some of the recent chat on this list and some of the code concepts and ideas floating around.  And right now there's no pressure to deliver on any of it.

I think for right now we're OK putting priorities one and two on ensuring 3.4 is rock solid and stable while working on code for 3.5, without necessarily getting too involved beyond that.  I'd only stay in that state for a couple more months though.  I'd say no later than June we should be putting a heavy focus on 3.6 and future 3.x releases and start putting together a *SOLID* foundation for what we want 4.0 to be, between gathering ideas that are floating around now and things that may pop up in the near future and demonstrating concepts with code and no later than the end of this year have a proper vision for a 4.0 release and how 3.x can be augmented to help with the transition to the next major version.

So to sum things up, enjoy the slow period for a little bit and get your ideas written out (and even code concepts to demonstrate) because I really do hope that as the year progresses we're once again moving full speed ahead and producing amazing software for the millions of sites powered by our platform.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com <mailto:joomla-dev-cms+unsub...@googlegroups.com>.
To post to this group, send email to joomla-dev-cms@googlegroups.com <mailto:joomla-dev-cms@googlegroups.com>.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

[Roberto Segura]

Thanks Hannes. I think I missunderstood your message yes.

About branches I don't agree with having parallel branches for different minor versions. I do for major versions.

Maintaining one branch updated with changes done in both is not easy and I cannot think how frustrating that would be for the v3.6 maintainer. As Thomas said there is a lot of work that has to be done before a release and preparing a feature like the webservices can be dome developed meanwhile in another repo. Something specific. Another example can be the media manager or your routing improvements. Code that is already there awaiting to be ready to be merged.

If you have felt frustrated because your router changes were not merge merged imagine something like that for v3.6. Most people won't direcly code anything as you already said a couple of times.

So the features are there and being developed. The goals are there and being worked. Actually we need more people contributing and maintaining than releases on sight.

Regards,

> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[Leo Lammeirnk]

@Allrude you interpenetrate my message completely wrong and don't get involved in inter-human relationships where you have nothing to contribute. And no they are not completely different at all since if we (Joomla) would decide to pursue the entire new methods as initiated by Michael a lot of work Hannes is kindly proposing would be a waste of his very valuable time and that's why I pointed him so wrong perception Ruud!

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Allrude]

Glad to hear that Leo, i don't agree with you but thats happening to you more often so nothing new there.

Op donderdag 26 maart 2015 04:31:54 UTC+1 schreef Leo Lammerink:

[ssnobben]

I don't think Hannes missed this Leo and what is all about but I guess he is frustrating about the process guide lines and of what to do next? And I see others abandon Joomla for this reason before too so its important to create an environment that encourage positive energy, easy of contribution and clear guidelines.

I also miss/don't see a clear dev strategy top down with chosen dev method and planning, guidelines. Maybe bcs I am not coder in the core of Joomla? There are docs here and there but as far as I know/see not the overview picture how you turn the for example road map http://developer.joomla.org/cms/roadmap.html into clear dev strategies? Good Roberto start sharing his ideas and would be good if this could be formally written down too. Then all the arguments could be viewed understood and also discussed....

So its good also to discuss how this really working practically and how this could be done in a better improved clear way to meet up with what Joomla community want to achieve.

How is this road map set into action today and how should it work better so it could be broken down to understandable coding chunks?

Michaels initiave is great Leo but how do people with positive energy and enthusiasms like Hannes get into right coding/coding directions is crucial for Joomla future.We are all people and have different circumstances in life and timing. Hannes want to do things now! So give him that possibility Joomla!

I also think that this overview dev guidelines/execution should be more clear/decisive even that Joomla is a voluntary project and have been improved a lot regarding the different processes but seems that not all people doesn't understand what's going on and what to do next? Or don't know where to find it?

For me Hannes is crying for help what to do next and having a lot of positive energy to contribute but doesnt know what to do next? Maybe better transparency directions decisions about what core people discuss and thinking about decisions/ideas/future directions for the whole community is good for letting all people knowing whats going on. Also good if doing some notes summarise these notes monthly and make them public on Magazine www.joomla.org with comments so people feels that they are involved in the Joomla communty process and show whats going on. Connect devs with other people in the Joomla community. I also would like to see Joomla magazine as the first thing you see on Joomla.org to better engage new people to Joomla. What you think?

I had a post about this too https://groups.google.com/forum/#!topic/joomla-dev-cms/Zhkilq_uRNI Leo and quote Paul also..and for me this should be the starting point to discuss and analyse on every level of Joomla progress.

"Paul wrote

- discussions about high level goals/objectives
"...a Joomla dev strategy that could be continuously updated/changed and describe the Joomla dev method"

What, How, When, Who, Where, and Why?

Start in the right end with analysis, that's going on now here great and then document a chunk of focuses shared dev document on right level on what should be achieved/goals with expected gant schemes. Change it if not working but then dependencies can be over viewed and planned better. One model could be to try to organise voluntarily different people responsible for different important core chunks (but not all core development) maintainers Drupal word that are responsible for execution and manning that specific code ie router group leader Hannes.

Hannes set up goals, time lines, dependencies, sync everything and reporting every month to Joomla chosen core dev leader/community.

So the idea is to split up some of Joomla dev in different important core chunks with one dev chief that have the total overview dev responsibility for the total core dev.

Well just my 3 cents...

[Joseph Cardwell]

Worth a $1.50 if a penny :)

> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[ssnobben]

Well things happens now didnt see this before even I know OSM had new ideas etc and discussions, proposals are here so thats good.

http://community.joomla.org/blogs/leadership/1856-community-feedback-on-the-proposal-for-a-new-organizational-structure-and-methodology.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+JoomlaCommunityCoreTeamBlog+%28Joomla!+Core+Team+Blog%29

Lets improve be positive and discuss on all levels and if things doesnt work Joomla community can change it..Take this chance now to participate into the discussions to make a new step forward for Joomla as a whole..

http://forum.joomla.org/viewtopic.php?f=704&t=880994