FluxBB direction - incremental vs major

Franz · 2010-08-25 23:07:09

Jérémie wrote:

Since the basic tools and management suggested months back weren't implemented (as usual here), it takes more work and time to maintain a current translation up to date than to rewrite it fully once a year.

You can always contribute
No, really, I'd like to hear what you prefer: us putting more work into the site and all kinds of tools or the actual software? You're being a little unfair here...

Jérémie · 2010-08-26 00:11:49

Sorry, but you are.

The main tool I asked for just after the fork, was a simple translators mailing list. From a translator point of view, it's simple: you subscribe, and then when you have work to do (new version with updated lang files, maybe an important beta where the dev team ask for i18n feedback, whatever) you get a mail with the bullet point infos, links, and such.

It takes what... 1mn30sec to implement? And writing a mail (or copy/paste a forum post) a few times a year? Yup, very much hard work indeed. I can see that furious debate about this breathtaking, ground shaking idea has put the core work to halt by itself for several years

It can be refined... with an added ML per language, opened to the public. Well, not a mailing list per se, but more like an alias. You write to i18n-french@fluxbb.org and every person registered to that ML (meaning people able and willing to localize from English to French) get that mail. Can be used by the dev team for specific inquiry (what's the typographic romanization rule for southern Farsi and whatnot), by plugin author asking for a translation, by forum admin asking for a plugin translation again, and whatever.

It takes a few seconds to setup a new ML for a language when asked, everything else can be handled by the community inside those, on the wiki, etc.

For the newcomers, why mail instead of forum? Two reason: one, it's easy to forget to check a forum or not seeing one post on a busy forum; basically it's easier for the translators. Two, segmentation: doing it with forums and automatic mail warning might like some granularity. But it's doable I guess, if moderated appropriately.

Either way, I don't care now. Given what's happened, how things were handled, I don't publish a translation and I don't publicly manage anything Flux related. But I won't be called unfair and let it slide, when it's quite the other way around. In my not so humble opinion, when someone has a decent idea (which could be a wrong idea, but the strict minimum should be to demonstrate it if that's the case) that require a few minute's work for him and other to be able to works hours and hours for free (more or less same as you, granted) for _your_ project, to improve _your_ project, the minimal urbanity would be not to insult him after wise.

Auto Edited out the last part, no reason to troll.

Last edited by Jérémie (2010-08-26 00:41:08)

Franz · 2010-08-26 00:19:11

I must apologize, I thought you were talking about our "translation center". So we were talking about two totally different things.
The mailing list would indeed be a good idea. I just think I never heard of it before (which obviously doesn't deny the possibility that you once suggested it).

Just to make that clear: I was not insulting anybody. If you think so, please point out where in those three lines I was supposedly insulting you.

And fluxbb.de, that wasn't me.

Ledo · 2010-08-26 22:02:18

You should stick with 1.4 for a while. And make timeline that is doable. Then implement one feature a time. And with every new release optimise everything a bit. So its better then it was before.

I think for now small things are those that will make a big difference. You have a product. Work with it for a while. And after 1.5, 1.6, 1.7, 1.8, 1.9 you will have 2.0. That will be much better than you can imagine it right now!

taylorchu · 2010-08-29 06:35:25

Totally agree with Ledo. fluxbb 2.0 should not be a huge jump. fluxbb dev team could gradually make changes. a rewrite is most likely to be buggy.

François · 2010-08-29 08:17:31

cyberman wrote:

Another point is the broken backward compatibility - there are hundreds of useful (over years grown) mods for fluxbb, which based on punbb. If you change the code base completely you have ... nothing. FluxBB is a very slim forum with not so much (unused) features like other BB. But so extensions are really important for it.

We will had to modify all our mods when the 2.0 will be released, whatever choice they made : FluxBB 2.0 will use an extension system, who isn't compatible at all with modifications .

artoodetoo · 2010-08-29 09:42:57

So, let's do it It can be experimental fork or dozen forks of main stream. Franz (?) have a great idea about smart patching on marked blocks.

Dev team can define the "Trend" and we all together can try to implement it.

Franz · 2010-08-29 09:44:12

That was Frank (FSX).

@Francois: The question is whether there is another step in between (1.5?) where mods might have to be adapted, too.

Ledo · 2010-08-30 22:33:59

If the developers believe FluxBB has reached a peak in version 1.4. And it just can't go in the direction you want it to go from here on. Leave FluxBB 1.4 and only maintain it until the day FluxBB 2.0 will be stable for production environment. And start with 2.0 today!

No point in braking 1.4 backwards compatibility every single new release. Because developers won't be happy with it and users wont be happy with it.

Strong 1.4 community until 2.0. And then clean slate.

Users are happy developers are happy?

If FluxBB 1.4 in developers opinion haven't reached it's peak. Then this is my opinion:

http://fluxbb.org/forums/viewtopic.php?pid=34922#p34922

Last edited by Ledo (2010-08-30 22:38:11)

pedigree · 2010-09-03 18:53:07

From my position, of having a forum thats a pain to patch due to the extras that Ive coded into it, and having coded mods for vbulletin before, a hook system is invaluable. If you dont like hooks, just dont use them but if youre coding extra, you cant beat them. Patching just works

Last edited by pedigree (2010-09-03 18:53:55)

kg · 2010-09-11 13:01:13

It's been a while since the topic was opened, and unless I've missed it in some other topic, there haven't really been any comments from the developers on the progress. What's the status, is any additional information available, has any decision been made?

Mpok · 2010-09-12 11:45:56

Agree with kg...
I think the poll is over now, and most of us are awaiting for news.

Reines · 2010-10-04 13:19:59

Don't take this as an official decision as I haven't discussed it with all the devs, but my interpretation of the comments as a whole, is, people would like the existing codebase to be tidied up but don't like the idea of a huge wait for it to happen.

My feeling is maybe the best approach is to build on-top of the existing codebase, but aim straight for 2.0 as the next release (unless we decide progress is too slow, in which case we could do a 1.5 step in between...).

Really, as a couple people pointed out, a total rewrite would be more interesting for us - but isn't needed, FluxBB already has most of the features it needs.

By building on-top of existing code, and refactoring, we don't need to start from scratch again, and hence save some time. This will also hopefully encourage us not to go overly complex with the architecture.

Regarding going straight to 2.0, or having steps in between, I would imagine if we make a rough roadmap - not necessarily setting dates, but at least the order in which features will be added. That way, if it turns out progress is slower than we wanted, we could do a 1.5 release without all of the planned features, and then continue on towards 2.0 afterwards. I think aiming to go straight to 2.0 is a better plan than actually aiming to have steps though, since releases require quite a lot of extra time, planning, organisation, and maintenance.

Gary · 2010-10-05 08:02:11

Sounds great Reines and I really can't wait for things to get rolling. The idea and overall method that things will take place sounds good to me and I'm sure many members will be happy with this decision, whether it is official or not.

Franz · 2010-10-05 12:02:36

Gary wrote:

I'm sure many members will be happy with this decision, whether it is official or not.

It's not even a decision yet - that's what he meant.

Gary · 2010-10-06 08:33:28

Worded wrongly... My mistake.

Ledo · 2010-10-06 21:32:18

Incremental + timeline that is doable.

Last edited by Ledo (2010-10-06 21:38:12)

davidlougheed · 2010-10-08 00:37:33

Isn't the point of a rewrite originally just to start afresh? :S It might be just me as a relatively inexperienced coder but I think that if you're just going to build on top of the old code just do incremental.

kg · 2010-10-08 07:51:19

davidlougheed wrote:

Isn't the point of a rewrite originally just to start afresh? :S It might be just me as a relatively inexperienced coder but I think that if you're just going to build on top of the old code just do incremental.

Have a look at refactoring

By the way: if the team is interested I would like to help out. Perhaps you will have some easier tasks (maybe certain types of refactoring, like separating some of the logic from layout) that I can help out with.

xiaoks · 2010-10-15 11:43:51

thanks

taylorchu · 2010-10-17 03:55:14

I can also help refactoring.

nickos · 2010-11-10 06:19:29

Well, a re write would be huge, so this is what I think we should do:

1. Continue with Development of 1.4 to keep things updated. Depending on how long the rewrite takes, maybe release a 1.5 or something.

2. The rewrite would be done in a years time, and then be released for a long beta stage so we can work out any major bugs we may come across.

3. While the beta is going on, finish the wiki and the how to guides etc. so when the final 2.0 comes out, we have our stuff together

4. Have developers start developing mods before the official 2.0 release so we can have some right out of the gate

5. Release it and heavily publicize it. Also, a new site layout would be good as we are trying to keep things fresh and up to date

That's my two cents

Oscon · 2010-12-23 14:10:57

FSX wrote:

Mods makes updating very hard when you installed lots of them. That's why there's need for a good extension system.

Considering the (bad) experience on this kind of things I totally agree. When you are the developer of your own things you can keep your hands on every update you want to do, but when you're using someonelse's stuff the update procedure start to be harder and harder without a strong but dinamic structure.

Core on the first side, database on the second, extension system on the third.

Forums

#76 2010-08-25 23:07:09

Re: FluxBB direction - incremental vs major

#77 2010-08-26 00:11:49

Re: FluxBB direction - incremental vs major

#78 2010-08-26 00:19:11

Re: FluxBB direction - incremental vs major

#79 2010-08-26 22:02:18

Re: FluxBB direction - incremental vs major

#80 2010-08-29 06:35:25

Re: FluxBB direction - incremental vs major

#81 2010-08-29 08:17:31

Re: FluxBB direction - incremental vs major

#82 2010-08-29 09:42:57

Re: FluxBB direction - incremental vs major

#83 2010-08-29 09:44:12

Re: FluxBB direction - incremental vs major

#84 2010-08-30 22:33:59

Re: FluxBB direction - incremental vs major

#85 2010-09-03 18:53:07

Re: FluxBB direction - incremental vs major

#86 2010-09-11 13:01:13

Re: FluxBB direction - incremental vs major

#87 2010-09-12 11:45:56

Re: FluxBB direction - incremental vs major

#88 2010-10-04 13:19:59

Re: FluxBB direction - incremental vs major

#89 2010-10-05 08:02:11

Re: FluxBB direction - incremental vs major

#90 2010-10-05 12:02:36

Re: FluxBB direction - incremental vs major

#91 2010-10-06 08:33:28

Re: FluxBB direction - incremental vs major

#92 2010-10-06 21:32:18

Re: FluxBB direction - incremental vs major

#93 2010-10-08 00:37:33

Re: FluxBB direction - incremental vs major

#94 2010-10-08 07:51:19

Re: FluxBB direction - incremental vs major

#95 2010-10-15 11:43:51

Re: FluxBB direction - incremental vs major

#96 2010-10-17 03:55:14

Re: FluxBB direction - incremental vs major

#97 2010-11-10 06:19:29

Re: FluxBB direction - incremental vs major

#98 2010-12-23 14:10:57

Re: FluxBB direction - incremental vs major

Board footer