Partkeepr: process of new version developing

No commits have been made since July 20th 2018. So I think we are not discussing ETA to next release but ETA to a new main developer. Until we have one, we will not have any releases for sure. However I would be curious, what the current state is.

The latest project info is here: https://www.patreon.com/posts/its-end-for-me-22527966
And basically the project doesn't have maintainer anymore, but if anybody serious want to take it, it seems possible.

So @christianlupus is right, it's actually ETA until new maintainer.

.

Having 5 devs is probably more than useless without solid project management (and probably funding at this stage), the project can survive with one or two, and the only resulting issue may be the development time.

One issue she pointed is pretty clear : issue management, and handling people with bad behavior.

The project can happily live with two devs, even with health issue, as long as there is people to do issue triage and community management so the developers can focus on a task without having to worry about the other things.

.

PartKeepr would have used yet-another-framework the same argument would apply, Symphony isn't really some niche-framework.

Yes it needs someone who knows or is willing to learn it, like any other framework.

And yes it might be a niche application, but the context is to take into account, if you knew symphony, would you be motivated to join a looking-dead project ? probably not.

.

Does it really need a advanced off the shelf framework?

It is not more advanced than another, it is just a framework, yes you can use a very light one, but at the end of the day you will have added a tons of extensions or made them from scratch for the same result, and even worse since it won't be as documented and tested as the "advanced off the shelf framework".

But fixing those workarounds in a nice way would need a lot of redesigning, probably not doable with the Symphony framework, or any other off the shelf ones.

We are not talking about Win32 apps here, and unless you have a POC to prove that it's not doable with the current framework, then it's BS.
Reinventing the wheel might works sometimes but that's not a solution working everytime.

If you says that "symphony learning curve is too steep" how a custom-made-thingy is supposed to be better ?

Now ranting that "symphony is bad and the project is doomed unless we rewrite everything" isn't gonna make the project move further, working on the PRs and with the contributors is.

.

If for instance I would like to have categories with cascading specs, which also cascade to components within such category (with the possibility of overriding them). And than showing a nice formatted description of all combined specifications dependent on the type of component. Is something that I should expect to work in Symfony?

No. No framework will do that. I think you have a misunderstanding of what a framework is. The implementation of Categories is something application-specific, and no generic framework will ever handle that.

I don't think Symphony or other frameworks are bad. But in the case of how I would like a Inventory Management System to look like, they are very unlikely to make the cut. That's not talking BS, but a good understanding of the complexity involved.

What the heck has a framework to do with a specific application works? Any framework has no understanding on how an application works. It provides a scheme, philosophy and model to build upon.

Additional note: Yes, I still have to pass repository access rights to someone, I'm unfortunately pretty busy with the liquidation of the PartKeepr UG. I hope I get around to that soon

.

Hi Felicia,

My understanding of Symphony as a framework -as said- is limited. But for instance if it is creating UI views by reading directly from tables, queries, it is quite hard to show information that is linked in an advanced way to each other.

In that case it actually might be better on reading up what Symfony provides and what not, instead of making false assumptions. There are no UI views generated by Symfony, at least not in PartKeepr.

The proposed cascading and inherited information is hard to query and thus propably hard to process by a (table driven) framework, or am I misunderstanding things?

Yes, you are misunderstanding things. Symfony provides no such things, maybe via some 3rd party bundle, but again, PartKeepr does not use such a bundle. Symfony is mainly used for the controller architecture, the serialization features (which, in conjunction, use the API platform to generate JSON-LD which then can be read by the frontend) and Doctrine for all database related stuff.

See https://wiki.partkeepr.org/wiki/Developers/Architecture

.

Hi Felicia,

Thanks for responding. I’ve programmed a lot of stuff, even web technology in its early days. But that is quite lacking regards to understanding the architecture of PartKeepr. Also the different technologies used are hard to grasp as a Windows develloper. As said for me the learning curve is too steep. But the underlying question can still be valid. What are the devellopment goals, and can those be reached with the used technologies. Regardless how they are called.

Reasons to use a framework, especially a widely used, adopted and maintained framework like Symfony2:

• Avoid code duplication
• Increase reliability
• Don't reinvent the wheel
• Increase maintainability
• Reduce work

Up until PartKeepr 0.1.9, it didn't use a framework apart from Doctrine for persistence (Symfony2 didn't exist back then). Maintenance was a nightmare.

The reason that there are no SQL injections in PartKeepr is because of Doctrine. The reason why there were so many new features after 0.1.9 in a short amount of time was Symfony2 and the API platform because of extremely low development overhead. The reason why PartKeepr works behind a reverse proxy without me writing zero code to support it: Symfony2. The reason why PartKeepr works on nginx without any code modification: Symfony2.

If you have trouble understanding how Symfony2 works, no problem: There are plenty of resources on the web to help you out.

If PartKeepr did use its own framework, you'd be very much on your own, even for the most basic functionality. I recently had a look at The Bug Genie as an issue tracker, and it doesn't use a framework at all - everything is self written. I submitted no less than 8 pull requests to fix bugs I encountered during normal use. After encountering half a dozen more bugs (and I only did use the software for maybe 30 mins over a period of a month), I stopped using it.

I think you’re probably the best person to give the answer why this project has had so little development support. And if it is fixable.

I can only guess: Relatively small user base and I did fulfill too many feature requests. It did work out of the box for the majority of users, so why would these users start contributing code?

The questions I’m asking myself are: would I enjoy participating in a shared project? Would it benefit from my experience? Do more people share my goals? How would the interactions between developers look like.

Unless you are willing to learn how a software project and the underlying technologies work, not much. Stepping up and complaining about the choice of framework is a very bad first step.

I will not participate in any project or development coordination in this project.

i'm currently trying to update to symfony 3.4. if i make some progress i will give a update

Hi @JelleDijkhuizen
Do you have any news on the symfony 3.x migration? If you have done any work on this could you please let me know where can I find your fork? Thanks in advance!

@martonmiklos, it looks like @adlerweb is trying to upgrade PartKeepr to Symphony 4 in a dedicated branch of his fork... :-)

@ZupoLlask thanks for the heads up!

I think this discussion was lengthy and the main issue is cleared out. See #1059. So, I will close this for now.