Were I given the keys to the kingdom...

[Arantor]

Hmm, I'm not entirely sure what point you're trying to make up there

And yeah, in a lot of ways this seems like rumination on the state of play, and how far some of the SMF forks have already gone in terms of implementing some or all of the things I'd love to see in SMF core. I also forgot proper timezone support. It's not enormous a job but it's enough hassle that you can't just do it in an afternoon, at least not properly.

Github doesn't rock - but here's the thing. Several people who do like Github - and Git by extension - have complained about local repos being damaged. This doesn't sound like a good system to me. The other thing as mentioned is that I have a much more iterative style and the whole fork/branch thing doesn't actually work so well for how I build stuff.

[iamjanco]

I can't say Github rocks either, though it does work for the purposes we're currently using it for. It can be complicated to use, especially for the inexperienced, and it's usually because of such folks things get damaged.  I've seen chunks of a repo lost, usually because of people who have access to it. For instance, git's Windows client can be especially quirky to use if things aren't set up correctly (or if the client isn't used properly), and for whatever reasons there are those who continue to insist on using such tools even though there are more reliable ways to accomplish things like repo updates, pushes, etc. Fortunately, we've been a small group during the projects I've been working on these past few years, and when it's choked on something, we've been able to repair the damage quickly.

[live627]

I have bricked a repo about a dozen times. And Github certainly does not rock. Its developers keep changing it for the worse. I liked it best in early 2012. Now it's too social...

[Burke ♞ Knight]

Turning into Git-Book...

[Arantor]

And this is why I much prefer SVN. It isn't as shiny and flashy but it works reliably and just great for my needs

[Arantor]

OK, so I think this topic has served its initial purpose, which is to establish what I'd do were I in charge of SMF development for 3.0. And, pleasantly, the take I have on things seems to be consistent with what everyone else seems to believe 3.0 should be.

So, the question then is 'what happens next?'

We've seen what the state of play for 2.1 is, and I'm a bit hesitant to jump in with that; 2.1 is two years in and I wouldn't want to significantly disrupt things. I'd like personally to see 2.1 emerge in its present form sooner rather than later and just get it out.

But that does raise the question of 2.2 or 3.0 and who's going to do what. I could, legitimately, just run off and do my own thing; this is not unheard of. But I don't believe that's best for either me or this project.

And sure, this shouldn't be taken as a definitive 'SMF 3.0 must be these things', nor a definitive 'only these things' list, but as a set of things I think should be in 3.0 or shortly afterwards. I have the skills to implement most of these myself, it's only things like the responsive theme I couldn't just do myself.


So, this really raises the question of how everyone (and I strongly invite team members, especially Devs and Customizers in this; they're the ones primarily working with code) wants SMF 3.0 to occur. I take the view that now is the perfect time to start implementing - 2.1's patches can be rolled into 3.0 as they occur, where relevant, but I'm aware that some people might want to see 2.1 further along than it currently is (to which I take the view that this is unnecessary; a major point release necessarily means major changes and thus only relevant patches need including). You may of course disagree; please do let me know if this is the case.

I'm having this debate in public because I feel the future of the software is important and it affects many people - and I believe there should be openness and honesty about that. I believe SMF's future is uncertain as it stands and I want to get people involved with its future to remove that uncertainty and put SMF back where it belongs. I've heard - and added my own input - about what I believe the next iteration of the SMF we all know and love should contain.

Now I'm asking how we get there. I could just go away and build it, and have my own little fiefdom where I'm the little king and call the shots all the shots and serve no-one but myself. It's extremely practical but a little unrewarding at times because you end up having to do everything yourself rather than working with others to share the load a little better.

I'm willing to get involved to help make 3.0. I'm even willing to step up and lead that endeavour, but I don't want to undermine anything in the 2.1 line, and while I would contribute bug fixes and such to that, I don't see my being heavily involved in 2.1. I don't want to do another fork, I've done that and while it is rewarding in some respects, it's an enormous mountain in others. It's not something I really want to entertain at this point in my developmental career, so to speak.

From my perspective I don't like Git, and to be honest I don't really like the idea of committing substantial changes with it either, so I'm positing the suggestion of building it on an SVN repo myself for the big stuff and committing it to Github down the line when I've done the really big stuff and then let everyone have a crack at it for improving and polishing. I'm aware this sounds arrogant; it's not meant to be. It's an awareness of myself, I work best when I'm able to iterate over and over before sending a commit off and I don't tend to do branches and piecemeal units like Git promotes. So in a private repo I'd be able to make bigger changes and then iterate on them quickly as issues arise before submitting something with the big stuff done, that I see as important, before opening it up to everyone. I am, as will be known, very protective of my work - I put a lot of myself into it.

So, I guess what I'm asking is, is this an acceptable situation for me to dive in and start working or do we need to find some other compromise(s) (or developer(s)) to get this stuff moving? The stuff outlined in this topic is really out of scope for 2.1 and should not be introduced in it; for all purposes, 2.1 is feature locked and that no changes other than bug fixes will occur. But we need to get this stuff moving now; even with the best will in the world, we're still talking a year away to make the changes as outlined, possibly more, and that's from right now without any real feature creep or suchlike, or changes when truly great ideas get suggested.

How do people feel about all this? I am very wary of treading on anyone's toes, because I really don't want to undermine the work that has gone on thus far, but I'm just very concerned that the road doesn't seem to be going anywhere from 'here' (it's a road to 2.1 and nothing at all beyond it) and it needs to start looking forward - and I'm willing to start off and head up that particular journey if others are willing to come with me because I can't (nor would I try again to) do it alone.

I'd note, there was a time when SMF 3.0 / smCore and SMF 2.1 were developed in tandem by two separate groups. I don't actually see this as being any different on a practical level. The changes I'd be inclined to introduce in 3.0 would be substantial at the code level, meaning they would quickly become two separate code bases, tied together by all the things we know and love SMF for: elegance, effectiveness, power and freedom. That's what I'm offering with this. And you know we can do it, if you'll join me in the effort.

How about we get this party started?

[Kindred]

I'm good with that -- and, hey, for the next 3 months, I wear the red badge (which just demonstrates that I was stupid enough to let them vote me back into a leadership position)...  GDitall....  (how'd I get sucked back into this, myself?)


Anyway...   I like the idea. Some folks will squawk about SVN vs GitHub, but if you have some good way to accept submissions into SVN and roll it into GitHub eventually, I can't see any major issue.

If you are serious, I am even willing to give you a badge (gods help us all) and I don't see many (if any) of the current team disagreeing.
As the current dev team, Oldiesmann and emanuele would be the ones I'd have to hear from for sure - if they could work with you.

and yes... SMF3 was always intended to be radically different - code-wise - from the 1.1 and 2.0 streams.

[Burke ♞ Knight]

I'd like to see Arantor in the team, for the 3.0 project.

[LiroyvH]

Sounds cool

[ziycon]

5. I'd reorganise most of the current code into classes. I realise that going OOP is a big hurdle for modifications but for the core code it needn't be the headache that it sounds like it should be. Having the code organised by function, and more importantly organised in such a way that an autoloader will help you out is a big thing. Instead of loading a ton of code every page in case you might need it, load only what you need. You could save thousands of lines of code per page without any trouble doing that.

I do love when people talk about this One can hope it's not far off!

[AllanD]

I think this is a great Idea, let's get something going in a positive way.

[iamjanco]

As a newbie here who both understands what you guys have gone and are going through, and the nature of what I think most of you want to achieve, I'm glad to see this also. I say that because I conducted a fairly exhaustive review of what's out there with respect to forum platforms (free and premium), and found smf to suit my needs best out of the box.


Please keep up the great work.

[Burke ♞ Knight]

iamjanco,

I'm sure I can speak for all the team on this:

Thank you for the kind words.

[emanuele]

Good luck Arantor, you need it.
But maybe now the team is desperate enough to accept that 2.x is dead and let the devs work on what they wanted is the way to go.

[Arantor]

OK, to answer some of the concerns raised.

1. Yes, I'm serious. In the time since I stepped out of Wedge, I started off another fork and realised that while my ideas are grand for it, they're not achievable by myself using SMF 2.1 as a framework. Putting my energy into SMF itself is more worthwhile. And yes, I have great trepidations about contributing - but I'm willing to put that aside for the successful outcome of this project.

2. As I said, I'm thinking that 3.0 would run parallel, not on the end of, 2.1. They would quickly become two code bases that would be very different, and I'm essentially thinking there would be little overlap for the first few months while SMF 2.1 gets polished off and SMF 3.0 takes form, and if there's little to no overlap, there's less direct interaction. But that's just how I see it. This is why I'm interested in what everyone has to say.

3. I'm aware that people dislike my temper and public attitude; naturally under a team badge this would get toned down, additionally I'd be prioritising my time on the code not the public forum


@ziycon: Realistically we're talking about a restructure of the code over about a year.

@emanuele: Interesting comment, and I know I've been involved in that little debate before (and it is, of course, mildly relevant even to here, but careful observers will understand why I'm less bothered by that right now ) I take it then that you're not opposed to my insane plans above?

[Kindred]

so, just one thing in defense of 2.x and the "plans"

When SMCore was proposed, we looked and said - that is a greta idea, but it's at least 3 years out, more likely 5
As an experienced PM with knowledge of marketing and moving products to market, it was clear to me (and I tried to make it understood to the others) that another 5 years before a release would be unacceptable and I pushed for the parallel (but ultimately diverging) development tracks with "quick" releases using small updates and low-hanging fruit in 2.1, 2.2 etc . and the larger re-write track in 3.0 for the long term. Spuds and emanuele (and then Suki) stepped up to work on the 2.x track, discussing with the rest of the team what "features" could be considered for the .x releases (and I appreciate both the stepping up and the request for input!)

Now, of course, we're 2 years in and still don't have a full 2.1 release (it was intended to be a much faster release cycle since MOST of the updates were going to be tweaks and twitches, with a few more major items (like the revised WYSIWYG replacement). Unfortunately, the best laid plans of mice and men...

I don't think that 2.x is "dead". I'd love to see someone take on some additional point releases (after all, several folks have pointed out non-critical bugs or desired tweaks in 2.0 and 2.1 - come on folks - if you want to see it, BRING IT! The code is sitting there in GitHub.)
At the same time, I agree that, at this point, the majority of the Dev and other team focus should be on getting 3.0 under way along with the revised customization site.

[Spuds]

Just stop the work on 2.1, why have any debate at all?

1) its late
2) no one is working on it
3) no one wants it, (including the now new smf lead developer) plus its scope and position were positioned for a release a year ago when there was an SMCore as the follow on, where it made some sense.
4) fewer will even use it in beta or rc's or ga if those fall on top of some 3.0 milestones which you said a year to something?  No one wants to thrash their forum around like that.

Good luck Arantor, you need it.
But maybe now the team is desperate enough to accept that 2.x is dead and let the devs work on what they wanted is the way to go.

Clearly part of the dev's evil plan all along 

[Arantor]

I have never said 2.x is dead. That's the point of running a parallel track is so that 2.1 - and indeed a 2.2 etc if desired - can be implemented without affecting 3.0, and the improvements built in 2.1 (and 2.2 etc if desired) can be implemented in 3.0. If what I'm proposing occurs, the ability to reuse code between 2.x and 3.0 is severely limited at best anyway.

@Spuds: I personally disagree on the 'kill 2.1' line. Sure it's late, but that doesn't mean stillborn. It just means late, and it is a viable upgrade with new facility that 2.0 doesn't have.

I believe a year to a public release from right now is feasible, taking 2.1 and making the changes I propose, barring any unforeseen improvements/changes along the way. Yes, that would realistically tank 2.1 in itself, but the practical reality is that a year to public release doesn't mean a year to final release, it means a year to a public beta - so we're still talking probably 2 years to final/stable release, being all told. We all know what can happen in the polish phase when everything is examined and pulled apart and this can easily take longer than the original build takes.

[Kindred]

just to be clear - my denial that 2.1 is dead was directed to emanuele's comment.    

I like your ideas Arantor and they are in line with my own expectations at this point.

[Spuds]

No worries, just my thoughts.  Not saying it would be the popular choice with everyone, but perhaps the most effective long term one given the conditions / constraints of the situation ... history has a funny way of repeating, just like nature.