1 repo to rule them all

[neo22s]

Based on this comment #660 (comment)

Do we need separated repos for each module? Only official modules of course.

Please list advantages and disadvantages.

Some already mentioned, please update this message.

Pros:

• Unique repo
• Easier to clone with all submodules
• Easier to start new issues
• Easier pack new releases
• Easier to handle milestones
• 1 unique place for PR

Cons:

• We'd need subtree splits like symfony for composer packages, and would need to set up (and probably host) to maintain them
• I find it much harder (eg with symfony) to contribute a fix as a package user - you only have that one package on disk, you have to go find the parent repo, clone it, work out where in it to find the code you already had, possibly pull in dependencies you don't need etc
• It's harder to test multiple combinations of versions of the different packages in the CI process.
• It's harder to quickly look at an issue or a particularly a PR and know which packages it affects and therefore the potential impact.
• It blurs the division between what should be logically separate packages by making it too easy to change all of them in a single commit
• It makes it hard to have different sets of contributors - eg if we drop official support for ORM but leave it around for people that still use it, it would be good if some of them had access to maintain it.

Let's just vote it, 1 week collecting votes.

Please just vote +1 if you agree with having all modules in 1 repo , -1 if you do want 1 repo per module.

thanks

[neo22s]

Regarding the cons, I am sorry but many are in the assumption that there's a huge active community with highly skilled developers working in the same project same time, which is not the case. Let's debate some of them:

@acoulton thanks for your feedback but I disagree in all the points :O hehe

• as far as I know the modules do not work without kohana so if they want to use a module they need to use entire KO framework.
• again the package does not work without KO therefore you need to download the entire framework which actually comes with all the modules once downloaded
• that should not happen, since they should be all in the same version
• I disagree, you can use labels and create a label for each module if needed, what's easier, opening 11 pages to check each issues or one place where you can filter?
• I do not understand the blur division concept I guess my english :s
• If we want to drop official support we just remove the module and create a repo, I know you lose changes but will be in the release history of the central repo... so no issue either.

We need to think that currently there's barely KO developers, we are putting to many issues for people to contribute and it's complex, I still get lost and no one knows whats the correct way....or the correct repo to put issues etc... not to mention that you want to collaborate and need to clone 11 repos :S

If we want KO to survive we need to have a easy to follow clean way to contribute. I think this is a really important step towards making all much easier understandable and simpler to maintain...

+1

[acoulton]

I'm not making assumptions about who/how competent active developers are...

as far as I know the modules do not work without kohana so if they want to use a module they need to use entire KO framework.

Incorrect. They usually need kohana/core but nothing else. None of my projects use the "entire KO framework"

again the package does not work without KO therefore you need to download the entire framework which actually comes with all the modules once downloaded

As above. Try it - composer require kohana/cache. You'll get kohana/cache and kohana/core, nothing else. Which is as it should be.

that should not happen, since they should be all in the same version

Here's the big disagreement. There is no reason the modules and core all need to be in the same version. It's the artificial constraint that releases have to happen for everything at once - even if they haven't changed - that's been the biggest complication and delaying factor in making releases in the past. 1 repo to rule them all goes in the direct opposite direction to what we need abd makes smaller faster releases with small numbers of devs virtually impossible.

I disagree, you can use labels and create a label for each module if needed, what's easier, opening 11 pages to check each issues or one place where you can filter?

Labels work for issues, but not PRs. If you look at a PR you need to check every single file it touches and know how the subtree splits are configured. Does that file go in just one module? All the modules? Does the PR label/commit description match what's actually being affected?

There are products for giving cross-repo overviews of github issues, if it's a problem to navigate we should look at them.

But if you're looking for a bug or current issues with the Cache module, what's hard about looking in the cache repo? When do you actually need to see all the issues for all the modules all at once?

I do not understand the blur division concept I guess my english :s

kohana/cache and kohana/database are very different packages. There should be very few times you need to change them both at once. If it's hard to change them both at once that reinforces that. It makes it easier to separately version and separately release by forcing people to keep changes properly isolated.

If we want to drop official support we just remove the module and create a repo, I know you lose changes but will be in the release history of the central repo... so no issue either.

Maybe that works if it's a straightforward split. What if it's not so clear cut?

Afraid it's a big, big 👎 from me, in a "reconsider-using-kohana-packages" kind of way.

[neo22s]

I have not said this: "I'm not making assumptions about who/how competent active developers are..." do not take things out of context since I have not nor I want to imply anything about that. I am sorry about the wording not the correct one. Just to make clear people is not contributing specially since everything is a NO by default theres no movement in this project, dont you see it? if we do not change our mindset and make things happen KO is still dead...

It's more a matter of time and efficiency. Lot more efficient 1 repo than 11.

All the points you have debated I can go over and explain to you again the same.... when I say ko framework I meant the core. Without the Core not any module works.

For the sake of understandability lets not call it packages but Modules since its how they are called at KO, no? if not let's agree to change the name to packages.

Modules do not work without the core. There's not activity or barely activity in any repo.

So I rather have 1 repo active than 11 non active. Lot cleaner and straightforward....

[rjd22]

I also rather nog have te modules in kohana core. I don't use any of them because I use better replacements for them:

auth - sentinel
database - doctrine
orm - doctrine
cache - predis
image - glide

So please don't include them in core. :)

[neo22s]

@rjd22 but you can activate them or not...

theres few I do not use and also using replacements, should not be an issue.

Thats the only motive for not including them?

[rjd22]

Sorry I closed it be accident. The reason why I don't want to include them is by the yagni rule.

I don't want code in my codebase I don't need or use. Even less I do want code in my codebase that I'm sure of I'm never going to use.

[enov]

https://mwop.net/blog/2015-05-15-splitting-components-with-git.html
https://github.com/zendframework/component-split

It seems that there was an enormous effort in Zend community to split their repo into separate components. Another thing worth to mention is that we had discussed previously to even split further the core.

[neo22s]

When I read the comments on #536 I get diarrhea :S the guy pointing perfectly a valid point and the answers....

I really understand all the points and I seem to be the only one suggesting to put them all together.

My thought was that If we are going to be 4 people maintaining it lets make it as simple as possible for us. At least was my impression. We can keep it as it is.

3 against 1 closing not wasting more time lets move forward in other important things.

[neo22s]

Lastly probably beacuse of things like #536 @lenton and others do not want to contribute. Really sad we get this attitude.

[acoulton]

@neo22s sorry I never got back to this over the weekend. Just to be clear, when I said "I'm not making assumptions about who/how competent active developers are..." I didn't mean to suggest you were saying negative things about people and I'm sorry if it read that way.

I'm confused about your comments about #536 though - when I read it, I see @lenton making a good suggestion (which is basically the opposite idea to this thread). Then there's 4 core contributors including @shadowhand in favour, and only one person (who's not a Kohana contributor) against....?

[neo22s]

O no I think is a great suggestion by @lenton and well explained.

Few things happened:

1. Issue got lost and no one did anything
2. He did an effort for nothing
3. Got a bad answer from my point of view which is something I saw before. "Dunning–Kruger effect" --> " unskilled persons suffer illusory superiority" what was the need of this? I do not understand it at all.

Well doesn't matter. I've come here to try to help and I got the doors shut many times with really ambiguous answers and not willing to help although accepted the project is dead.

You can check the forums to see what I mean. If we do not change the way we do things completely this is going nowhere.

[rjd22]

@neo22s Ofcourse it was a good idea but we're still just a big group of developers each having different needs for Kohana framework.

If someone has a need for it it will be implemented by the person itself. If one adds an issue, even when it's a good idea, you can't expect someone that does not need it directly to work on it.

It has nothing to do with attitude and everything with the resources everyone is able to give.