Maintained?
bendavies opened this issue · 28 comments
Hey,
It looks like noone really has time to maintain the bundle at the moment?
I'm going to be maintaining my own fork, since it looks that way at the moment.
Thanks
Hi @bendavies,
yes, we currently have no one left from the original extension creators and therefore no one who knows the core of the library well. So you might say that there is no maintenance right now.
There are a few people with commit access, that merge PRs from time to time. Bbut without deep knowledge of the internals, we mostly merge "easy picks". In addition to that, ressources are slim and delays are sadly quite common. Sorry for that!
Another issue is: this lib was created for a project of ours with quite simple auditing requirements and has worked in that project perfectly from the first production revision on. And since we do not have other, more complicated, projects using the lib, we do not have the need to develop it any further or to iron out edge cases that do not occur in production for us.
I have had this on my todo list for ages, but haven't gotten around to writing up an issue an linking it in the README prominently, describing the status of the project. We are more or less looking for someone taking over the project, but do not have any experience in how to make this happen in a way that we would be happy about it 😄
Generally speaking: any support is greatly appreciated, we are looking into possible ways to find and vet people who are willing to take over.
@bendavies would you consider taking up some responsibility when getting commit permissions? We already did this some time ago, but the developer contributed for about half a year, increased the code base significantly in that time, and vanished afterwards for a long time. Which was kind of counter productive. So, not the best of experiences with this, so far.
Again: if anyone has made positive oder negative experiences with procedures in transfering projects like these, any support is very welcome.
I'll link a few people, that have some library knowledge to start the discussion
@bendavies , can you show us you current fork? Maybe being part of the core team in the repo would be much more productive than forking.
https://github.com/Owsy/EntityAudit <--- fork
Another thing I would like to add, that is important to us: EntityAudit is heavily inspired by Hibernate Envers, which is a battle proven auditing library. So lots of architecture decisions might not be obvious in the first place, but were normally chosen for a reason 😄
Therefore fundamental changes to the core architecture should normally not be necessary and keeping the responsibilities of this lib to its core values should be important. As in most open source projects, an important job for a maintainer would be to deny certain feature requests that would bloat the project unnecessarily und unintentionally.
Hi @tolry, thanks for your detailed reply!
I'm obviously happy to contribute to the project, but given the state of some open PR's at the moment, I thought it easier to maintain a fork for the time being as it didn't look like any PR's i would open would be merged or even looked at. (not a problem, i know everyone is busy!)
As for being a maintainer, I definitely could not promise that I wouldn't do the same thing as your last maintainer and 'disappear' after a time. I must admit, at the moment my needs are selfish, I need bugs fixed.
I'm not opposed to be being added as a maintainer though, if you still want to do that. The project doesn't look massively active, so it doesn't seem like that much of a big job. As you say, I am not that familiar with the code base, so probably could not be the single active maintainer.
As for my fork, I've sured up the test suite and added support for mysql 5.7 and postgresql, and tested them on travis. (tests were only running on sqlite so pretty useless).
Let me know what you'd like to do.
That actually sound pretty good - I've become a maintainer for the same reasons ).
@bendavies , can you point particular PRs that are stuck here?
@andrewtch Don't want to get into individual PR's here, but if you look at the list it's pretty clear.
also if you look at the network, people are maintaining their own forks with a single bug fix as they have probably got the same idea as me about this library not being really maintained:
https://github.com/simplethings/EntityAudit/network
@tolry thoughts?
@bendavies what you've outlined above sounds good so far. Fixing bugs and maintaining a runnable test suite is really important in my opinion. The most important thing from our point of view, obviously, is not breaking BC or at least not breaking BC without bumping the major version of the lib (semver).
I would suggest giving you write permissions on the repo and from there on, we see how well it works out. Would you be ok with that? I would ask you to ping somebody, when you are not sure, if something might be problematic. Especially at the beginning.
@andrewtch is currently probably the one around who has the best knowledge of the codebase, so he might be best suited for technical questions. If he has some time left? I don't know, he has decide that 😄
@tolry there can be no BC breaks at this point as 1.0 has not been released.
I'm fine with write access.
@bendavies which is a problem by itself, wasn't aware of that tbh 😁 maybe pinning the current master to 1.0 and moving from there might be a good choice
write access should be granted soon
@tolry thanks. 1.0 sounds like a good idea once i've integrated by build improvements.
@tolry there can be no BC breaks at this point as 1.0 has not been released.
Sorry? 0.x series version numbers allow any BC breaks you want. http://semver.org/#spec-item-4
As for me, we're only using this library in a legacy context now - we moved to a well structured logging format instead since individual data change audits didnt serve our needs.
@merk I think, that's what @bendavies meant by that: not having a 1.0, there is no BC to uphold 😄
right! I phrased it badly.
Hey guys, any news on the new maintainers ?
@tseho for what I can judge @bendavies is doing a great job so far and a few other devs are also contributing more than before. So big improvement to what we had a few months ago.
Did you have a particular issue/PR in mind or were you just asking generally? 😄
@tolry I did two PR during the week so I have spent some time in the code of this bundle, I know there is room for improvement if we are targeting a 1.0 release.
I just wanted to know if the people maintaining the project would be interested in working on a roadmap ? It would be stupid to work on big pull requests without discussing it beforehand.
@tseho sounds like a good idea to me, having some kind of rough plan, what is needed to call it 1.0
Easiest way to discuss this in the open would probably be a new github issue? Alternative ideas anyone?
I think we can close it for now. I'm trying to support here.
I'm available to support this as far as my knowledge for this bundle goes.
Is this bundle compatible with Symfony 3 ?
Is this bundle compatible with Symfony 3 ?
Yes, it is.
Yes, it is.
And Symfony 4+ ?
Anyone knows a fork with support or fix to use composite keys? im having this error when updating a table: Warning: spl_object_hash() expects parameter 1 to be object, string given