Hi Sara,
can we talk more about the bugs.php?
had a look at the code and seems similar but its a smaller project and
possibly easier to deal with.
Is it hosted only by php or it has mirroring as well?
Is it possible to get a dump of the db?
Do you have anything specific in mind?
Cheers,
Mathias
Also willing to help with this, the interface alone is very outdated.
I think a re-vamp could really benefit the community.
On Thu, Jul 20, 2017 at 8:53 AM, Mathias Grimm mathiasgrimm@gmail.com
wrote:
Hi Sara,
can we talk more about the bugs.php?
had a look at the code and seems similar but its a smaller project and
possibly easier to deal with.
Is it hosted only by php or it has mirroring as well?
Is it possible to get a dump of the db?
Do you have anything specific in mind?Cheers,
Mathias
Hi,
Is it hosted only by php or it has mirroring as well?
It's only running on bugs.php.net our controlled server.
Is it possible to get a dump of the db?
The sql folder contains schema definitions. A complete dump can't be
shared freely since it contains security bugs, which shoul not be
shared publicly. (not sure if there are any open right now, but well
...)
Do you have anything specific in mind?
From my list of things there would be some cleanups to ease mangement
of canned answers and security bugs. I'd love a better API and better
GitHub integration (i.e. github http hook which creates a ticket for
each pull request and mirrors comments / state changes)
There are also minor things like that the version field is misleading
for PECL packages, there we need PHP vesion and package vesion.
Also we can need better UI especially for category selection - the list
is way to long and it's hard to find the right one.
Interesting might be integrating https://3v4l.org/ so code samples are
directly run (which of course won't work for code related to external
things like databases or such)
If one things more there's certainly a lot more ... so maybe
familiarizing, cleaning up and some smaller changes in those regions
might be good.
Key properties I'd like to keep is that the UI is "simple" and
reporting bugs is "easy" (i.e. no big user registration or such) as wel
as handling should be "fast" :-)
johannes
Hi,
Is it hosted only by php or it has mirroring as well?
It's only running on bugs.php.net our controlled server.
Is it possible to get a dump of the db?
The sql folder contains schema definitions. A complete dump can't be
shared freely since it contains security bugs, which shoul not be
shared publicly. (not sure if there are any open right now, but well
...)Do you have anything specific in mind?
From my list of things there would be some cleanups to ease mangement
of canned answers and security bugs. I'd love a better API and better
GitHub integration (i.e. github http hook which creates a ticket for
each pull request and mirrors comments / state changes)
There are also minor things like that the version field is misleading
for PECL packages, there we need PHP vesion and package vesion.Also we can need better UI especially for category selection - the list
is way to long and it's hard to find the right one.Interesting might be integrating https://3v4l.org/ so code samples are
directly run (which of course won't work for code related to external
things like databases or such)If one things more there's certainly a lot more ... so maybe
familiarizing, cleaning up and some smaller changes in those regions
might be good.Key properties I'd like to keep is that the UI is "simple" and
reporting bugs is "easy" (i.e. no big user registration or such) as wel
as handling should be "fast" :-)
I'm fine with no user registration required, but there should definitely be
a user login for people without php.net account. It's one of the main pain
points with the PHP bug tracker. I want a simple login where I can see all
bugs I have created or commented on or subscribed to.
Regards, Niklas
Interesting might be integrating https://3v4l.org/ so code samples are
directly run (which of course won't work for code related to external
things like databases or such)
+1 to this. Not a must-have, but it would help encourage useful
repro scripts, I think. :D
Key properties I'd like to keep is that the UI is "simple" and
reporting bugs is "easy" (i.e. no big user registration or such) as wel
as handling should be "fast" :-)I'm fine with no user registration required, but there should definitely be
a user login for people without php.net account. It's one of the main pain
points with the PHP bug tracker. I want a simple login where I can see all
bugs I have created or commented on or subscribed to.
I would say add single-sign-on options ("login with
github/facebook/twitter") would be nice-to-haves. Report anonymously
would even be fine provided it comes with the caveat "you won't be
able to edit this later, and if we have questions that aren't
answered, your bug may get closed, so check back often".
FWIW, I started toying with the idea to rewrite it earlier this year
and tossed https://github.com/sgolemon/platform-php-web-bugs together
as a starting point to get a personal version of the site up and
running. (Note: this doesn't include any changes, just a framework for
running the site on a hosting provider.) If nothing else, it should
describe the component pieces you'll need to set it up locally (there
aren't many, but it's effectively a HOWTO guide).
-Sara
Any objections about using an existing framework?
Interesting might be integrating https://3v4l.org/ so code samples are
directly run (which of course won't work for code related to external
things like databases or such)+1 to this. Not a must-have, but it would help encourage useful
repro scripts, I think. :DKey properties I'd like to keep is that the UI is "simple" and
reporting bugs is "easy" (i.e. no big user registration or such) as wel
as handling should be "fast" :-)I'm fine with no user registration required, but there should definitely
be
a user login for people without php.net account. It's one of the main
pain
points with the PHP bug tracker. I want a simple login where I can see
all
bugs I have created or commented on or subscribed to.I would say add single-sign-on options ("login with
github/facebook/twitter") would be nice-to-haves. Report anonymously
would even be fine provided it comes with the caveat "you won't be
able to edit this later, and if we have questions that aren't
answered, your bug may get closed, so check back often".FWIW, I started toying with the idea to rewrite it earlier this year
and tossed https://github.com/sgolemon/platform-php-web-bugs together
as a starting point to get a personal version of the site up and
running. (Note: this doesn't include any changes, just a framework for
running the site on a hosting provider.) If nothing else, it should
describe the component pieces you'll need to set it up locally (there
aren't many, but it's effectively a HOWTO guide).-Sara
Any objections about using an existing framework?
The same objections raised regarding web-php apply equally to web-bugs.
-Sara
So no composer, monolog etc?
On Thu, Jul 20, 2017 at 9:08 AM, Mathias Grimm mathiasgrimm@gmail.com
wrote:Any objections about using an existing framework?
The same objections raised regarding web-php apply equally to web-bugs.
-Sara
So no composer, monolog etc?
I believe using composer is good and there's already a pull request for
using it: https://github.com/php/web-bugs/pull/27
The "big" issue there is that applying it needs coordination with
systems@ or whoever maintains the deploy script to prevent breakage.
For other libraries a typical due diligence should happen. Some items
from top of my head:
- Is the license ok? (bugsweb is licensed under PHP License afaik, GPL
is not acceptable i.e.) - Is it needed? (left-pad isn't ;-) )
- Is it maintained?
- Does it work?
- Is it efficient (in usability etc.)
- What about the library's dependencies?
johannes
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?
Regarding the code:
- Is there any restrictions?
- Could it be a MVC? What is too complex?
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.
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 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.
So no composer, monolog etc?
I believe using composer is good and there's already a pull request for
using it: https://github.com/php/web-bugs/pull/27The "big" issue there is that applying it needs coordination with
systems@ or whoever maintains the deploy script to prevent breakage.For other libraries a typical due diligence should happen. Some items
from top of my head:
- Is the license ok? (bugsweb is licensed under PHP License afaik, GPL
is not acceptable i.e.)- Is it needed? (left-pad isn't ;-) )
- Is it maintained?
- Does it work?
- Is it efficient (in usability etc.)
- What about the library's dependencies?
johannes
Hi Mathias
2017-07-21 0:39 GMT+02:00 Mathias Grimm mathiasgrimm@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
kalle@php.net
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
It is also good for the PHP ecosystem at large to show we're using
libraries, where it makes sense. If we use a variety we're also not
favoring single ones :)
- 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
A reason for this is that these sites are not "actively developed" and
it should be possible to find the relevant code within a few minutes,
even when looking at it every second year or though. With the current
architecture I go to search.php's code and can see what's going on.
With a framework I have to see how the framework handles the routing
and where the relevant controller is and so on and so forth ... this
is contrary to other projects under constant development possibly by
larger teams and is also different from developing a generic bug
tracker (or whatever site you look at) where things need to be
configurable for different usage scenarios ...
johannes
Hi Johannes
2017-07-24 0:03 GMT+02:00 Johannes Schlüter johannes@schlueters.de
It is also good for the PHP ecosystem at large to show we're using
libraries, where it makes sense. If we use a variety we're also not
favoring single ones :)
As much as I agree with that, I do not see a big thing that using a
library makes it much easier to do for a bug tracker that fits our
needs. Okay maybe a captcha or SSO, but the rest can be done in a
simple encapsulation that we don't need thousands of lines of code
just to implement something so basic.
A reason for this is that these sites are not "actively developed" and
it should be possible to find the relevant code within a few minutes,
even when looking at it every second year or though. With the current
architecture I go to search.php's code and can see what's going on.
With a framework I have to see how the framework handles the routing
and where the relevant controller is and so on and so forth ... this
is contrary to other projects under constant development possibly by
larger teams and is also different from developing a generic bug
tracker (or whatever site you look at) where things need to be
configurable for different usage scenarios ...
I think the main reason for these sites not being actively developed
is that they do their job, I did some minor cosmetics to the bug
tracker, but besides maybe better integration with github PR's, I
can't see that many more features our tracker needs.
I get that with a framework it makes the debugging route easier or if
you are just curious to study the code, and we can still achieve that
with simplistic encapsulation where it makes sense. If we keep your
example with search, what we can do is to implement functionality that
returns records based on criteria, we need that functionality in
multiple places anyway.
I always saw the PHP project as an example to how powerful the
language is by its own, out of the box and I will continue to advocate
for us to continue that way
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Thanks all for the comments.
While I understand the motivations & reasons I think I would prefer not to
help in this specific case.
Nothing wrong with the approach but different then what I was expecting to
spend my free time on.
I hope everything goes ok.
Count on me for further improvements if the idea changes.
Cheers,
Mathias
Hi Johannes
2017-07-24 0:03 GMT+02:00 Johannes Schlüter johannes@schlueters.de
It is also good for the PHP ecosystem at large to show we're using
libraries, where it makes sense. If we use a variety we're also not
favoring single ones :)As much as I agree with that, I do not see a big thing that using a
library makes it much easier to do for a bug tracker that fits our
needs. Okay maybe a captcha or SSO, but the rest can be done in a
simple encapsulation that we don't need thousands of lines of code
just to implement something so basic.A reason for this is that these sites are not "actively developed" and
it should be possible to find the relevant code within a few minutes,
even when looking at it every second year or though. With the current
architecture I go to search.php's code and can see what's going on.
With a framework I have to see how the framework handles the routing
and where the relevant controller is and so on and so forth ... this
is contrary to other projects under constant development possibly by
larger teams and is also different from developing a generic bug
tracker (or whatever site you look at) where things need to be
configurable for different usage scenarios ...I think the main reason for these sites not being actively developed
is that they do their job, I did some minor cosmetics to the bug
tracker, but besides maybe better integration with github PR's, I
can't see that many more features our tracker needs.I get that with a framework it makes the debugging route easier or if
you are just curious to study the code, and we can still achieve that
with simplistic encapsulation where it makes sense. If we keep your
example with search, what we can do is to implement functionality that
returns records based on criteria, we need that functionality in
multiple places anyway.I always saw the PHP project as an example to how powerful the
language is by its own, out of the box and I will continue to advocate
for us to continue that way--
regards,Kalle Sommer Nielsen
kalle@php.net
2017-07-24 10:15 GMT+02:00 Kalle Sommer Nielsen kalle@php.net:
Hi Johannes
2017-07-24 0:03 GMT+02:00 Johannes Schlüter johannes@schlueters.de
It is also good for the PHP ecosystem at large to show we're using
libraries, where it makes sense. If we use a variety we're also not
favoring single ones :)As much as I agree with that, I do not see a big thing that using a
library makes it much easier to do for a bug tracker that fits our
needs. Okay maybe a captcha or SSO, but the rest can be done in a
simple encapsulation that we don't need thousands of lines of code
just to implement something so basic.A reason for this is that these sites are not "actively developed" and
it should be possible to find the relevant code within a few minutes,
even when looking at it every second year or though. With the current
architecture I go to search.php's code and can see what's going on.
With a framework I have to see how the framework handles the routing
and where the relevant controller is and so on and so forth ... this
is contrary to other projects under constant development possibly by
larger teams and is also different from developing a generic bug
tracker (or whatever site you look at) where things need to be
configurable for different usage scenarios ...I think the main reason for these sites not being actively developed
is that they do their job, I did some minor cosmetics to the bug
tracker, but besides maybe better integration with github PR's, I
can't see that many more features our tracker needs.I get that with a framework it makes the debugging route easier or if
you are just curious to study the code, and we can still achieve that
with simplistic encapsulation where it makes sense. If we keep your
example with search, what we can do is to implement functionality that
returns records based on criteria, we need that functionality in
multiple places anyway.I always saw the PHP project as an example to how powerful the
language is by its own, out of the box and I will continue to advocate
for us to continue that way
It's unmaintained code, nobody wants to touch it. Any attempt to improve
anything doesn't go anywhere, because there are too many people saying the
current state is fine.
See https://github.com/php/web-bugs/pull/26 for an example.
There's no need for a framework, libraries are just fine. But saying that
the PHP project is a good example for how powerful the language is, is ...
really strange.
The attitude of "don't change anything, it's fine" makes it really hard to
find motivation to contribute anything.
Regards, Niklas
Hi Niklas
2017-07-24 11:51 GMT+02:00 Niklas Keller me@kelunik.com:
It's unmaintained code, nobody wants to touch it. Any attempt to improve
anything doesn't go anywhere, because there are too many people saying the
current state is fine.
I doubt the fact that because its written this way is making no one
wants to touch the code, sure it plays a factor but not that big one.
I don't mind improving it at all, what I do mind is that we should
include tons of additional code for no real gain other than syntax
looking better for the reader.
See https://github.com/php/web-bugs/pull/26 for an example.
Maciej got web karma and can commit this, I don't really mind this one
as an example, tho since we use mysqli, we should simply just use the
native mysqli class, and then we don't run into the issue as described
with PDO having no numRows method. I even would go as far as saying we
should get rid of the PEAR dependency in bugsweb, we even had issues
with pear releases that php-src depends on when 7.0.0 was about to be
released.
There's no need for a framework, libraries are just fine. But saying that
the PHP project is a good example for how powerful the language is, is ...
really strange.
I don't think it is that strange, again a subjective statement. I can
agree that in the current state its not that much an example, but I
think that should be the goal for all php.net web projects.
The attitude of "don't change anything, it's fine" makes it really hard to
find motivation to contribute anything.
I'm not saying don't change its fine, what I'm saying is that we
shouldn't change the overall arching of the website to be bloated.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
It's unmaintained code, nobody wants to touch it. Any attempt to
improve anything doesn't go anywhere, because there are too many
people saying the current state is fine.See https://github.com/php/web-bugs/pull/26 for an example.
For such pull requests the issue is that nobody is actively looking
after those. "Old" folks with karma change the bgtacker from time to
time if they need something and then move on, again.
With this very specific item we need to make sure the server actually
has pdo_mysql enabled. I currently have no access and assume it does.
johannes
Hi Johannes
2017-07-24 20:10 GMT+02:00 Johannes Schlüter johannes@schlueters.de:
With this very specific item we need to make sure the server actually
has pdo_mysql enabled. I currently have no access and assume it does.
The bug tracker provides an "admin" interface which have a phpinfo()
page[1], and yes bugs.php.net does have pdo_mysql
[1] https://bugs.php.net/admin/?action=phpinfo
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Interesting might be integrating https://3v4l.org/ so code samples are
directly run (which of course won't work for code related to external
things like databases or such)
Scary website.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
FWIW, I started toying with the idea to rewrite it earlier this year
I realise a total rewrite isn't for the most part what people are
gunning for on this thread, but some may be thinking it, so I thought
I'd repeat my response on Twitter at the time:
Does PHP / the world really need Yet Another Bug Tracker? Are there unique requirements, or is it just NIH Syndrome?
If it's just a case of "all the current ones suck", that's a slightly
different project: "new open source bug tracker that doesn't suck"?
That's not to say other bug trackers don't suck, and maybe "mutate the
codebase into something awesome" could also be a cool project, but it's
worth weighing that effort against hacking on bugzilla (to pick a
semi-random example) in a sustainable way, and getting two-way flow from
other projects using the same codebase.
Regards,
--
Rowan Collins
[IMSoP]
I'm fine with no user registration required, but there should
definitely be a user login for people without php.net account. It's
one of the main pain points with the PHP bug tracker. I want a simple
login where I can see all bugs I have created or commented on or
subscribed to.
For the ones you have registered you can already use the "author" field
in the advanced search: https://bugs.php.net/search.php
This could be extended with search for comments or such.
I also don't mind optional openid/oauth integration, but barrier for
reporting bugs should be low.
johannes