Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

process of new version developing #1021

Closed
mctomaszek opened this issue Jan 25, 2019 · 20 comments
Closed

process of new version developing #1021

mctomaszek opened this issue Jan 25, 2019 · 20 comments

Comments

@mctomaszek
Copy link

"ETA" for new version of partkeepr :) ? someone knows something about it or project is already closed . I'm just curious

@mctomaszek mctomaszek changed the title process of developing of new version process of new version developing Jan 25, 2019
@christianlupus
Copy link
Collaborator

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.

@rhaamo
Copy link

rhaamo commented Jan 28, 2019

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.

@HendriXML
Copy link

HendriXML commented Jan 28, 2019

.

@rhaamo
Copy link

rhaamo commented Jan 28, 2019

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.

@HendriXML
Copy link

HendriXML commented Jan 28, 2019

.

@rhaamo
Copy link

rhaamo commented Jan 28, 2019

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.

@HendriXML
Copy link

HendriXML commented Jan 28, 2019

.

@rhaamo
Copy link

rhaamo commented Jan 28, 2019

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.

@HendriXML
Copy link

HendriXML commented Jan 28, 2019

.

@Drachenkaetzchen
Copy link
Member

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.

@Drachenkaetzchen
Copy link
Member

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

@HendriXML
Copy link

HendriXML commented Jan 28, 2019

.

@Drachenkaetzchen
Copy link
Member

Drachenkaetzchen commented Jan 28, 2019

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

@HendriXML
Copy link

HendriXML commented Jan 29, 2019

.

@Drachenkaetzchen
Copy link
Member

Drachenkaetzchen commented Jan 29, 2019

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.

@JelleDijkhuizen
Copy link

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

@martonmiklos
Copy link

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!

@ZupoLlask
Copy link

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

@martonmiklos
Copy link

@ZupoLlask thanks for the heads up!

@christianlupus
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants