Hi Mathias 2017-07-21 0:39 GMT+02:00 Mathias Grimm <mathiasgr...@gmail.com>: > Do we have a pre-approved list of libs that we could use? > For example phpunit. I can't imagine doing it without using that. > What licenses are approved? > MIT, BSD?
Most functionality that a bug tracker should do, can and imho should be implemented in native PHP fairly flawlessly. The only place I can see that could benefit from a library, if even is github integration, and even that is done by webhooks which is fairly easy to implement on its own. Bugsweb already depend on some PEAR packages, and I for one think those dependencies should be eliminated, a standard PHP build should be all thats needed to implement a bug tracker that fit the needs with that of PHP. I don't think personally the usage of phpunit is worth it, bugsweb is so specific to the PHP project, and it should continue to be so and that is such a minority that would ever run the test suite so the time spend implementing is better spend in other places, but that is my personal opinion. > Regarding the code: > - Is there any restrictions? > - Could it be a MVC? What is too complex? I don't think any of PHP.net's infrastructure should run on an MVC and we should follow what Rasmus has been advocating at many conferences over the last years. The front controller is the browser, it does all the routing we need, instead of adding another layer of complexity when we already know that we wish to display "bug.php", if we want some pretty links, then we can simply just put in some RewriteRule[s], but thats about it. > I am just trying to understand the mindset a bit as I come from a different > background and try to come up with something that might be good for > everybody. The mindset at php.net, or the PHP project in general is very simple and basic and it should continue to be so. The language itself is extremely powerful out of the box as is. Even though the codebase is from the early PHP4 days, there is nothing wrong with using objects or anything at all. A class to handle comments would be much more beneficial as the bug tracker, even more with github integration, would benefit highly from that as there are many of the same operations that can be encapsulated in an object vs using procedural functions. What should be disencouraged in the current code base is the mess with global variables and states, which objects to a good extend solves. > My background is pretty much into object oriented style, SOLID principles > (to some extend), however, in the end I want to build something stable, > testable, simple for a child to understand, and, that can be extended and > last for the long time. Thats what everybody always want :) > > I've been thinking about this thing since yesterday (initially was php.net) > and If I am to approach the bugs.php.net I think I would write an API > first, leaving the frontend to be done by somebody else as the frontend is > not what I like to do on my free time. > > I am not assuming I would do the whole API alone as other people might be > interested in joining, although I wouldn't mind doing it by myself, but > then time is a factor I can't overcome that easy. I think the bugsweb, if updated, should be a website as it is now, however it should implement some webhooks to allow integration with things like git commit hooks that we already have now, people.php.net, and github. What we need is a website that fits our own needs and infrastructure, as we are not making a general purpose bug reporting system. The code is open and freely available and can be adapted to other projects own needs (like MySQL: http://bugs.mysql.com/ is running a fork of bugsweb), but that should be about it, extremely simple and straight forward. > I would like to come up with a basic MVP that we could iterate until at > least someone is happy :) > For the MVP my idea is to keep functionality exactly the same as > introducing new features will make us not ship it ever. > First create a rock-solid base and then add features. > > So, for that I need to know the hard limits, the DOs and DON'Ts to set some > boundaries. As for DON'T's, the main ones would be as I wrote about: - No global variables mess, a global variable for database access shared across procedural functions are perfectly fine tho, and same for others on a case by case basis - No need to implement third party libraries for things essentially possible in native PHP. We should be neutral, if we use some library, it can be interpreted as PHP.net favors this or that PHP based project - No need to overcomplex code by using practices such as MVCs, we got the browser as our front controller. We can create abstractions for commonly used operations, such as comments, bug reports and authentication objects Yes I realize that we, the PHP project on many points still can be considered this odd and special gentlemans club, but most of these points and procedures has been what we always have done, it is not that I don't see a reason to change things around now, but that is another and larger discussion that the project as a whole should decide if needs changing or not. I hope you aren't disencouraged but all of this, and even though it is very different from the background you come from and in the end you just want to contribute, you will still continue to push a new bug tracker though. I wouldn't mind joining in on this as a now senior contributor for PHP. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
