Kohana Maintainers

[shadowhand]

Continuing the discussion from this issue.

What would you like to see done about the additional assets that Kohana has? For the most part, these assets are held by the SFC but management of them is basically in my control, since no one else bothers to do anything with it.

Currently, the following things have high bus factor, with only myself and @zombor having administration abilities:

• Kohana Github Organization
• Gandi Domains (SFC has admin)
• Rackspace Cloud Servers (discourse, forums, redmine (not working))
• PagodaBox (main website, v2 docs (not working))
• Discourse
• Old Forums

I would very much like to add more people to each of these areas, except for domains since SFC has full control. In addition, the following things should be fixed:

• restore v2 docs site (data is in Pagodabox but not accessible?)
• recover the core parts of redmine (issues and files and ???) for historical purposes
• possibly covert the old forums site to static HTML (tried and failed multiple times)

[shadowhand]

Also, please note that I have just simplified the Github teams so that we have:

• @kohana/maintainers
• @kohana/founders
• @kohana/alumni

I believe that @kohana/maintainers have access to all the repositories that exist. If you see something that you need access to, feel free to create an issue on the repo or email me.

[neo22s]

Hello,

Thanks @shadowhand love the transparency.

Of course many of us see things differently. But I think many of us have a common issue.

We use Kohana on daily basis and we depend on the Framework to keep our business running.

At this stage in our case migration to another platform will be a business suicide.

That's why me/we are so interested on keeping it updated. I am aware I can update whatever I want in "my copy" repo etc, but I will love to contribute to maintain it alive.

I think there's many things we can do but if by default "project is dead" then gets really complicated ;)

I am open to any discussion and to put some resources in the project, as said we are really interested to maintain it.

[satara]

I also use Kohana on a daily basis and would love to see it alive.

[samwilson]

+1 I'm not actively working on Kohana projects at the moment, but we're still running a few applications that are definitely not going away nor being redeveloped on another framework. So I'd love to help if I can. I'm a maintainer of Adldap2-Kohana.

[rjd22]

@shadowhand I would think it would be better for the organization to drop some excess weight like the old forums and move the v2 docs to github wiki. This would make it easier to manage the kohana project.

[shadowhand]

@rjd22 I don't like dumping the old forums because there is still a lot of historical data there that may be useful to people. Moving the v2 docs to github would be great, but they have to ported over somehow. Right now the data is stuck in PagodaBox with no way to access it.

[jslegers]

I totally fell in love with Kohana when I tried it a few years ago. I loved (1) its elegant, readable code, (2) its innovative HMVC architecture, its (3) cascade / waterfall class design, etc. Kohana really changed my way of looking at frameworks and had a huge influence on how I've been looking at PHP code ever since.

I nevertheless stopped using Kohana and haven't used it in quite a while, for mostly these reasons :

• Even though much of the code IS self-explanatory, the little documentation I found was a bit of a turn-off
• The Kohana community was a rather tight-knit & small community, with a reputation of scaring newcomers by being too "arrogant" and "elitist" (sorry, guys)
• Kohana 3.3 broke backwards compatibility with Kohana 3.2 (which IMO is a major no-no for minor version changes)
• The number of third party contributions was very small and often compatible with only one version of Kohana
• Kohana devs completely refused (even to this day) to use namespaces. While I do shiver when I see eg. crap like use Symfony\Component\HttpKernel\EventListener\SessionListener as BaseSessionListener; above a class name, I really don't see what's wrong with putting namespace Kohana; there (especially today, with PHP <=5.4 being end-of-life). It has literally zero impact on the rest of your code, other than having to put \ before PHP core classes.

---

Having said that, the love is still there and I'd really love to give Kohana another try.

So what are you guys up to? Any plans to for a new version of the framework? Anything exciting coming up? What does the future of Kohana look like?

Also, what do you expect from any new maintainers joining the team? If I'd like to invest some of my time working on Kohana, how do I get started? What workflows / procedures need to be followed? Which planned features are already assigned and which haven't?

[zombor]

Kohana didn't follow sem-ver, so 3.2 to 3.3 was a major version. It was clearly documented and communicated this way (if I recall, it was very long ago) too.

[jslegers]

Kohana didn't follow sem-ver, so 3.2 to 3.3 was a major version. It was clearly documented and communicated this way (if I recall, it was very long ago) too.

In that case, you can replace

• Kohana 3.3 broke backwards compatibility with Kohana 3.2 (which IMO is a major no-no for minor version changes)

with this :

• Kohana doesn't use semantic versioning

[jslegers]

By the way, I just made my first contribution @ #87

[jslegers]

Just got this response @ #87 :

@jslegers thank you for your contribution.

Politely closing this as we can not merge pull requests directly into
master as per our contribution guidelines.

Also note that this is just an example .htaccess and it's not meant to
be used without tweaking. We should remove this file from future versions.

Thanks :)

• So you prefer to outright delete an .htaccess example that needs a little tweaking instead of replacing it with one that works out of the box?
• So you tell people not to merge pull requests directly into master, but you leave them clueless about what IS the proper way to contibute? (I'm sorry, but the docs aren't clear on where to submit the .htaccess file)

I think I'm starting to realize why Kohana doesn't have that many contributors.

[zombor]

There is a CONTRIBUTING.md file which should pop up a big yellow thing when you are submitting pull requests. It's very comprehensive.

[sentry360]

I can try and cache/convert the old forums if no-one is working on that task. Seems like a fun little task, and likely the most I can contribute here considering my limited skill-set.

[neo22s]

Hello,

Today I wrote small blog post explaining how to migrate http://garridodiaz.com/upgrading-kohana-3-3-x-to-php-7/ maybe theres other issues that may arise but for now all seems to work properly.

I will not move any time soon out of KO 3.3.x so I will try my best to keep it updated while we use it.

So what do you guys think if we create a new branch based on 3.3.x that is php7 compatible? and that we can keep updated. I know it breaks backwards compatibility that's why I am proposing a different branch/naming. Maybe KO 7.x? or 3.7.x? (for me this one makes more sense) or just use it as base for 3.4 ?

[sentry360]

@shadowhand per "possibly covert the old forums site to static HTML (tried and failed multiple times)"

This was kinda fun to hack, minus UTF-8 parts.

The code / files (ziped).
https://github.com/3rdcupofjava/scraping_old_kohana_forum

For some reason it would almost consistently fail after about 22 pages. Wonder if it's the host or my end. But I finished running it 20 pages at a time so as to not have to do DB clean up every time.

Think I got em all, if you guys notice issues or want me to modify it or anything, just let me know.

Live copy of the static files.
http://3rdcupofjava.com/scraping_old_kohana_forum/out

[neo22s]

@sentry360 wow!!! thats really nice! can you explain how do we install the repo and how can we launch it? thanks!

[sentry360]

@neo22s If you're looking to just use the static files, simply extract out.zip and you're good to go.

If you're looking to use the scraper, it's a simple kohana app, everything is in the Main controller. https://github.com/3rdcupofjava/scraping_old_kohana_forum/blob/master/application/classes/Controller/Main.php

/main will scrape the forum. The whole DB is in kohana_forum_db.zip, should you want to avoid scraping and simply want to generate files or do something else with the data in the DB.
/main/out will generate the .html files out of the database

That's about it I think.

[neo22s]

thanks! looks good :D

[shadowhand]

@sentry360 this is really impressive but doesn't completely mirror. In particular:

• the index pages don't exist, the only entry is index.html which is weird
• all of the cross-post links like http://forum.kohanaphp.com/comments.php?DiscussionID=952 are not corrected
• the output files have hard links with scraping_old_kohana_forum/ in them, which requires a global replace to fix

[sentry360]

@shadowhand Hi, I kind of like the index.html page, it's as static as one can get.

I'm sure I missed some corrections, I corrected for pagination, but that's about it, I'll take a look at that sometime thanks.

Per hard links, that's just line 85:

$index .= '<a href="'.URL::base().'out/'.$filename.'">'.$result['title'].'</a>'.'<br />';

If you run the app as /, it should remove those issues, at least I think (this was a quick hack [probably has bugs]).