Hi Everybody,
It's almost that time again where we rush at the last minute to
organise something for the Google Summer of Code, so in the interest
of being prepared I'm thinking it's time to start collecting ideas for
potential students. I've updated a few of the Wiki pages with some
things relevant from the Mentor Summit I attended last year about the
idea and applying process.
One of them is collecting ideas sooner rather than later and trying to
make sure there as detailed as possible, including what the
deliverables are of the project and any ideas of how it should be
implemented. If you don't have a Wiki account feel free to email me
with your ideas and I'll add it to the page on your behalf.
If we're accepted to the program this year, we can discuss the student
selection process a bit more. But first lets get the ideas going.
Scott
ps.
How many people went "Hi Dr Nick"?
Scott MacVicar wrote:
Hi Everybody,
It's almost that time again where we rush at the last minute to organise
something for the Google Summer of Code, so in the interest of being
prepared I'm thinking it's time to start collecting ideas for potential
students. I've updated a few of the Wiki pages with some things relevant
from the Mentor Summit I attended last year about the idea and applying
process.One of them is collecting ideas sooner rather than later and trying to
make sure there as detailed as possible, including what the deliverables
are of the project and any ideas of how it should be implemented. If you
don't have a Wiki account feel free to email me with your ideas and I'll
add it to the page on your behalf.If we're accepted to the program this year, we can discuss the student
selection process a bit more. But first lets get the ideas going.Scott
ps.
How many people went "Hi Dr Nick"?
Just my $0.02
I think we really should encourage at least two active mentors for each
project this year. I think it helps both the students (always someone
to annoy) and the mentors (less stress and time out of their lives) and
provides a safety net if a mentor has real life issues come up. But for
that we need more people willing to mentor ;)
Thanks,
Elizabeth Smith
On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith
auroraeosrose@gmail.com wrote:
I think we really should encourage at least two active mentors for each
project this year. I think it helps both the students (always someone
to annoy) and the mentors (less stress and time out of their lives) and
provides a safety net if a mentor has real life issues come up. But for
that we need more people willing to mentor ;)
If we create a "php-gsoc@" mailinglist where all the students and
mentors, and everyone else who wants to follow the student work, and
require students to post weekly/by-weekly status updates then there is
no need. The community can then help the mentor out and we get more
information about the projects.
I still don't know what happened to many of the gsoc projects last
year, despite my multiple inquires to the mentors of the projects, and
haven't heard a beep from most of the students :(
Lets keep it in the OSS style. Communicate in the open.
-Hannes
I think that's a great idea. The normal weekly/bi-weekly reports could
be CCed to internals@, with all discussion happening on gsoc@
- David
Am 22.01.2009 um 09:04 schrieb Hannes Magnusson:
On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith
auroraeosrose@gmail.com wrote:I think we really should encourage at least two active mentors for
each
project this year. I think it helps both the students (always
someone
to annoy) and the mentors (less stress and time out of their lives)
and
provides a safety net if a mentor has real life issues come up.
But for
that we need more people willing to mentor ;)If we create a "php-gsoc@" mailinglist where all the students and
mentors, and everyone else who wants to follow the student work, and
require students to post weekly/by-weekly status updates then there is
no need. The community can then help the mentor out and we get more
information about the projects.I still don't know what happened to many of the gsoc projects last
year, despite my multiple inquires to the mentors of the projects, and
haven't heard a beep from most of the students :(Lets keep it in the OSS style. Communicate in the open.
-Hannes
On Thu, Jan 22, 2009 at 9:04 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith
auroraeosrose@gmail.com wrote:I think we really should encourage at least two active mentors for each
project this year. I think it helps both the students (always someone
to annoy) and the mentors (less stress and time out of their lives) and
provides a safety net if a mentor has real life issues come up. But for
that we need more people willing to mentor ;)If we create a "php-gsoc@" mailinglist where all the students and
mentors, and everyone else who wants to follow the student work, and
require students to post weekly/by-weekly status updates then there is
no need. The community can then help the mentor out and we get more
information about the projects.I still don't know what happened to many of the gsoc projects last
year, despite my multiple inquires to the mentors of the projects, and
haven't heard a beep from most of the students :(Lets keep it in the OSS style. Communicate in the open.
Agreed.
As a sidenote, the wiki has an account request system, simply request
an account if you do not have yet one and likes to propose ideas.
Cheers,
Pierre
Hi,
As a former GSoCer I think the php-gsoc@ mailing list would be a great idea.
One thing I noticed was that I really had no idea how most other studen't
projects were going besides the few that poped into IRC from time to time.
Another advantage of the php-gsoc list is that the internals list can be a
bit much when just starting out. I remember all of a sudden getting tons of
emails, most of which didn't havy any impact on my project. A GSoC specific
list would probably help that and make things easier for the students
(though, reading internals can be quite interesting at times and worth it
for GSoC students doing internals work :D). This list could also be used as
a place for potential students to ask questions, propose GSoC ideas and get
to know the GSoC oriented portion of the PHP community.
As mentioned by others, I think the weekly or bi-weekly report is a great
idea. It would really help keep everyone informd as to whats going on.
Also, more detailed project descriptions would be nice. It was kind of hard
to know what to write a proposal on for just a two sentance description of
the project.
~ Graham Kelly
On Thu, Jan 22, 2009 at 9:04 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith
auroraeosrose@gmail.com wrote:I think we really should encourage at least two active mentors for each
project this year. I think it helps both the students (always someone
to annoy) and the mentors (less stress and time out of their lives) and
provides a safety net if a mentor has real life issues come up. But for
that we need more people willing to mentor ;)If we create a "php-gsoc@" mailinglist where all the students and
mentors, and everyone else who wants to follow the student work, and
require students to post weekly/by-weekly status updates then there is
no need. The community can then help the mentor out and we get more
information about the projects.I still don't know what happened to many of the gsoc projects last
year, despite my multiple inquires to the mentors of the projects, and
haven't heard a beep from most of the students :(Lets keep it in the OSS style. Communicate in the open.
Agreed.
As a sidenote, the wiki has an account request system, simply request
an account if you do not have yet one and likes to propose ideas.Cheers,
Pierre
Scott MacVicar wrote:
Hi Everybody,
It's almost that time again where we rush at the last minute to organise
something for the Google Summer of Code, so in the interest of being
prepared I'm thinking it's time to start collecting ideas for potential
students. I've updated a few of the Wiki pages with some things relevant
from the Mentor Summit I attended last year about the idea and applying
process.One of them is collecting ideas sooner rather than later and trying to
make sure there as detailed as possible, including what the deliverables
are of the project and any ideas of how it should be implemented. If you
don't have a Wiki account feel free to email me with your ideas and I'll
add it to the page on your behalf.If we're accepted to the program this year, we can discuss the student
selection process a bit more. But first lets get the ideas going.
I can try being a mentor again. :)
-Andrei
Add the bugtracker, and I can get round to finishing, unis been far too
busy this year so far :-(
On Fri, 23 Jan 2009 13:37:18 -0800, Andrei Zmievski andrei@gravitonic.com
wrote:
Scott MacVicar wrote:
Hi Everybody,
It's almost that time again where we rush at the last minute to organise
something for the Google Summer of Code, so in the interest of being
prepared I'm thinking it's time to start collecting ideas for potential
students. I've updated a few of the Wiki pages with some things relevant
from the Mentor Summit I attended last year about the idea and applying
process.One of them is collecting ideas sooner rather than later and trying to
make sure there as detailed as possible, including what the deliverables
are of the project and any ideas of how it should be implemented. If you
don't have a Wiki account feel free to email me with your ideas and I'll
add it to the page on your behalf.If we're accepted to the program this year, we can discuss the student
selection process a bit more. But first lets get the ideas going.I can try being a mentor again. :)
-Andrei
Add the bugtracker, and I can get round to finishing, unis been far too
busy this year so far :-(
Finishing what exactly?
I'd like to add the bugtracker idea again.. but the last year
bugtracker gsoc turned into something completely different and not at
all usable for php.net.
-Hannes
Hannes Magnusson schrieb:
I'd like to add the bugtracker idea again.. but the last year
bugtracker gsoc turned into something completely different and not at
all usable for php.net.
What is bugging me is the question whether we really need our own
bugtracker software.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make them
overly complex to use and people just get frustrated with them and
don't report bugs as the result.
Hannes Magnusson schrieb:
I'd like to add the bugtracker idea again.. but the last year
bugtracker gsoc turned into something completely different and not at
all usable for php.net.What is bugging me is the question whether we really need our own
bugtracker software.--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B
5D69--
Ilia Alshanetsky
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make
them overly complex to use and people just get frustrated with them
and don't report bugs as the result.
Personally I think it would be nice to have some sort of milestone
support. I think we already had that for a brief moment. I think it
would make the bug tracker a very useful tool to see when something
will be fixed and more importantly also for historical reasons. Then
again we often shuffle around fixes from one branch to another .. so
the trick is to make it possible prevent things to get out of whack.
Maybe the bug tracker should be our interface to the NEWS file .. then
again in order to be that, the solution would need to be super duper
rock solid. But it could make the life of the RM's a lot easier.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Am 25.01.2009 um 14:29 schrieb Lukas Kahwe Smith:
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make
them overly complex to use and people just get frustrated with them
and don't report bugs as the result.Personally I think it would be nice to have some sort of milestone
support. I think we already had that for a brief moment. I think it
would make the bug tracker a very useful tool to see when something
will be fixed and more importantly also for historical reasons. Then
again we often shuffle around fixes from one branch to another .. so
the trick is to make it possible prevent things to get out of whack.
Maybe the bug tracker should be our interface to the NEWS file ..
then again in order to be that, the solution would need to be super
duper rock solid. But it could make the life of the RM's a lot easier.
Absolutely. Also, a "fix version" would be really good, so people can
know when a bug was fixed.
Also, CVS/SVN post-commit hooks would be nice, so the tickets are
annotated with links to the changesets. Right now, if I see someone's
comment "Fixed in CVS HEAD and PHP_5_3", I need to look at the date,
then go to the cvs mailing list or logs and find the respective
commit. Cumbersome.
- David
hi everyone,
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make them
overly complex to use and people just get frustrated with them and don't
report bugs as the result.
aplogies if what comes is just a little verbose...
for those who don't have the luxury of "building from the latest CVS
snapshot", the current tracker is sorely missing some kind of better
integration with your version control system.
by a couple orders of magnitude the largest amount of time i spend on
maintaining the debian php packages is the result of going on treasure
hunts through your cvs logs and commit lists trying to find just which
commits map to a particular (usually security vulnerability) bug, and
then making sure that there were no regressions in the fix addressed by
later commits. take the last issue with the Zip::extractTo()...
while you might not consider my request important enough to address
(i.e. "we don't support 3rd-party distros so we won't go out of our way
on this"), this has implications for intra-project issues as well.
for example, when a bug affects multiple branches, those doing RM work
would probably be interested in knowing that the fix was applied to each
of the relevant branches.
while i'm sure there are more technical ways of integrating support
for this, one very easy way is to just map CVS/svn/etc commits to bug
reports transparently. if a commit contains something like '#nnnn' in
the commit message, you could have it post the commit info to the tracker.
then a quick read of the bug report should be the only thing necessary
to know if each of the branches have recieved a fix. and as a side
effect it would also solve the problem for those of us who
package/distribute php externally...
anyway, sorry if this is hijacking the thread just a bit, but having
just spent a large part of my "free time" doing some of this stuff,
i felt compelled to throw this in.
sean
In that case why wasn't this pointed out last year, and I could of done
something more useful with my GSoC time last year......
hi everyone,
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make them
overly complex to use and people just get frustrated with them and don'treport bugs as the result.
aplogies if what comes is just a little verbose...
for those who don't have the luxury of "building from the latest CVS
snapshot", the current tracker is sorely missing some kind of better
integration with your version control system.by a couple orders of magnitude the largest amount of time i spend on
maintaining the debian php packages is the result of going on treasure
hunts through your cvs logs and commit lists trying to find just which
commits map to a particular (usually security vulnerability) bug, and
then making sure that there were no regressions in the fix addressed by
later commits. take the last issue with the Zip::extractTo()...while you might not consider my request important enough to address
(i.e. "we don't support 3rd-party distros so we won't go out of our way
on this"), this has implications for intra-project issues as well.for example, when a bug affects multiple branches, those doing RM work
would probably be interested in knowing that the fix was applied to each
of the relevant branches.while i'm sure there are more technical ways of integrating support
for this, one very easy way is to just map CVS/svn/etc commits to bug
reports transparently. if a commit contains something like '#nnnn' in
the commit message, you could have it post the commit info to the
tracker.then a quick read of the bug report should be the only thing necessary
to know if each of the branches have recieved a fix. and as a side
effect it would also solve the problem for those of us who
package/distribute php externally...anyway, sorry if this is hijacking the thread just a bit, but having
just spent a large part of my "free time" doing some of this stuff,
i felt compelled to throw this in.sean
Stop top-posting.
In that case why wasn't this pointed out last year, and I could of done
something more useful with my GSoC time last year......
-Hannes
Hi,
I think that there needs to be more feedback from the community on how
projects are going and the way they should go. This might help to curb some
of the problems being discussed where there was a gap between the project
and what the community wants. Feedback would also help the student know how
he/she is performing on their project and gain confidence in their work or
see where they need to improve. Weekly or biweekly feedback and
communication between the student and the community would also help the
student get a better feel for open source development (as GSoC is kind of a
lighter version of the real thing). This in turn might make the student feel
more involved in the PHP community and want to stay around afterwords or at
the very least might make them better prepared/more intereested in future
open source devlopment. I know that when I was doing it, I really never had
much feedack on the project, I mainly just went off what my mentor said.
However, the downside with community feedback is that too much of it could
be overwhealming for students and harsh feedback could just turn students
off from the project. This is why internals@ might not be a good list
(either too much or feedback not student oriented) and a gsoc@ list might be
more appropriate.
I also think that the project proposals submitted for GSoC aplications arent
quite enough of an outline of the project. (For instance, I really had no
clue how the project would go or what excatly i would need to do until I saw
the code I was working with for the first time.) As a result of this I think
that maybe a week or two into it the student should send (maybe in their
first report) a tentative schedule/list of goals they wish to accomplish for
the project. At which point, the community could give feedback on that set
of goals. Likewise in addition to weekly/biweekly reports some sort of mid
point report and a final report should be done.
Lastly, I really think all the PHP GSoC projects should be hosted in PHP's
CVS under a central location (maybe something like
/repository/gsoc/2009/projectname/). It was very hard at times to find the
work done for other projects.
~ Graham
On Sun, Jan 25, 2009 at 9:35 AM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:
Stop top-posting.
In that case why wasn't this pointed out last year, and I could of done
something more useful with my GSoC time last year......-Hannes
Lastly, I really think all the PHP GSoC projects should be hosted in
PHP's
CVS under a central location (maybe something like
/repository/gsoc/2009/projectname/). It was very hard at times to
find the
work done for other projects.
Actually if we havent made the migration to SVN at that point, we
should at least use SVN for the GSoC projects.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lastly, I really think all the PHP GSoC projects should be hosted
in PHP's
CVS under a central location (maybe something like
/repository/gsoc/2009/projectname/). It was very hard at times to
find the
work done for other projects.Actually if we havent made the migration to SVN at that point, we
should at least use SVN for the GSoC projects.
Already the intention, I want all of the projects either in a
dedicated GSoC SVN repository or the project wide one if we've got it
sorted by then.
Scott
Lastly, I really think all the PHP GSoC projects should be hosted in
PHP's
CVS under a central location (maybe something like
/repository/gsoc/2009/projectname/). It was very hard at times to find
the
work done for other projects.Actually if we havent made the migration to SVN at that point, we should
at least use SVN for the GSoC projects.Already the intention, I want all of the projects either in a dedicated GSoC
SVN repository or the project wide one if we've got it sorted by then.
There is two cases:
- the project is completely new and cannot be developed in an
existing module (be svn or cvs):
- use php.net's svn for it
- the project is about improving an existing php.net project:
- has to use the target project module
- use a special branch if necessary
The problem we had was the lack of svn support, but I'm confident that
it will be up and running before this edition will begin, hopefully :)
Or do I miss something obvious?
Cheers,
Pierre
--
Pierre
In that case why wasn't this pointed out last year, and I could of done
something more useful with my GSoC time last year......
http://markmail.org/message/daf4zi5dfktv7jjt
sean
Sean,
You make some very good points and I'll be the first to agree there is
definitely a room to improve the existing bug-tracker, in particular
its integration with the repository commits, but I do not think it
needs a fundamental rewrite. From what I can see most (I think its
all, but being careful with generalization here) developers already
put "Fixed bug #..." in their bug fixing commits. I would be fairly
trivial to add a regex to grab those and automatically close the bug
report and even add a link to the diff. As far as branch fix tracking,
it could be as simple as adding another SQL table to the bug tracker
along the lines of:
CREATE TABLE bug_fix_revisions (
bug_id integer not null,
branch varchar(25),
date timestamp
);
We could then add another search page to bug tracker that will give a
you a matrix of all the fixes performed between date X and Y looking
something like this
BUG # | Branch X | Branch Y | Branch Z | ...
1223 | (date) | (date) | | ..
It would solve your problem, I think and would make RM life easier in
terms of tracking fix syncronization
hi everyone,
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make them
overly complex to use and people just get frustrated with them and
don't
report bugs as the result.aplogies if what comes is just a little verbose...
for those who don't have the luxury of "building from the latest CVS
snapshot", the current tracker is sorely missing some kind of better
integration with your version control system.by a couple orders of magnitude the largest amount of time i spend on
maintaining the debian php packages is the result of going on treasure
hunts through your cvs logs and commit lists trying to find just which
commits map to a particular (usually security vulnerability) bug, and
then making sure that there were no regressions in the fix addressed
by
later commits. take the last issue with the Zip::extractTo()...while you might not consider my request important enough to address
(i.e. "we don't support 3rd-party distros so we won't go out of our
way
on this"), this has implications for intra-project issues as well.for example, when a bug affects multiple branches, those doing RM work
would probably be interested in knowing that the fix was applied to
each
of the relevant branches.while i'm sure there are more technical ways of integrating support
for this, one very easy way is to just map CVS/svn/etc commits to bug
reports transparently. if a commit contains something like '#nnnn' in
the commit message, you could have it post the commit info to the
tracker.
then a quick read of the bug report should be the only thing necessary
to know if each of the branches have recieved a fix. and as a side
effect it would also solve the problem for those of us who
package/distribute php externally...anyway, sorry if this is hijacking the thread just a bit, but having
just spent a large part of my "free time" doing some of this stuff,
i felt compelled to throw this in.sean
Ilia Alshanetsky
See: http://cvs.php.net/viewvc.cgi/pear/Bugtracker/
That's the pear bug tracker modified for all pear/pecl/php bugs I worked
on about 1.5years ago. :) It has that roadmap thing..
--Jani
Ilia Alshanetsky wrote:
Sean,
You make some very good points and I'll be the first to agree there is
definitely a room to improve the existing bug-tracker, in particular its
integration with the repository commits, but I do not think it needs a
fundamental rewrite. From what I can see most (I think its all, but
being careful with generalization here) developers already put "Fixed
bug #..." in their bug fixing commits. I would be fairly trivial to add
a regex to grab those and automatically close the bug report and even
add a link to the diff. As far as branch fix tracking, it could be as
simple as adding another SQL table to the bug tracker along the lines of:CREATE TABLE bug_fix_revisions (
bug_id integer not null,
branch varchar(25),
date timestamp
);We could then add another search page to bug tracker that will give a
you a matrix of all the fixes performed between date X and Y looking
something like thisBUG # | Branch X | Branch Y | Branch Z | ...
1223 | (date) | (date) | | ..It would solve your problem, I think and would make RM life easier in
terms of tracking fix syncronizationhi everyone,
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make them
overly complex to use and people just get frustrated with them and don't
report bugs as the result.aplogies if what comes is just a little verbose...
for those who don't have the luxury of "building from the latest CVS
snapshot", the current tracker is sorely missing some kind of better
integration with your version control system.by a couple orders of magnitude the largest amount of time i spend on
maintaining the debian php packages is the result of going on treasure
hunts through your cvs logs and commit lists trying to find just which
commits map to a particular (usually security vulnerability) bug, and
then making sure that there were no regressions in the fix addressed by
later commits. take the last issue with the Zip::extractTo()...while you might not consider my request important enough to address
(i.e. "we don't support 3rd-party distros so we won't go out of our way
on this"), this has implications for intra-project issues as well.for example, when a bug affects multiple branches, those doing RM work
would probably be interested in knowing that the fix was applied to each
of the relevant branches.while i'm sure there are more technical ways of integrating support
for this, one very easy way is to just map CVS/svn/etc commits to bug
reports transparently. if a commit contains something like '#nnnn' in
the commit message, you could have it post the commit info to the
tracker.
then a quick read of the bug report should be the only thing necessary
to know if each of the branches have recieved a fix. and as a side
effect it would also solve the problem for those of us who
package/distribute php externally...anyway, sorry if this is hijacking the thread just a bit, but having
just spent a large part of my "free time" doing some of this stuff,
i felt compelled to throw this in.seanIlia Alshanetsky
Jani Taskinen wrote:
See: http://cvs.php.net/viewvc.cgi/pear/Bugtracker/
That's the pear bug tracker modified for all pear/pecl/php bugs I worked
on about 1.5years ago. :) It has that roadmap thing..
The one Barry worked on for GSoC 2008 is at
http://cvs.php.net/viewvc.cgi/bugtracker
I've only just realised that this isn't a fork of the current tracker, I
assumed it was and had been extending the current one.
Scott
Ilia Alshanetsky wrote:
Sean,
You make some very good points and I'll be the first to agree there is
definitely a room to improve the existing bug-tracker, in particular
its integration with the repository commits, but I do not think it
needs a fundamental rewrite. From what I can see most (I think its
all, but being careful with generalization here) developers already
put "Fixed bug #..." in their bug fixing commits. I would be fairly
trivial to add a regex to grab those and automatically close the bug
report and even add a link to the diff. As far as branch fix tracking,
it could be as simple as adding another SQL table to the bug tracker
along the lines of:CREATE TABLE bug_fix_revisions (
bug_id integer not null,
branch varchar(25),
date timestamp
);We could then add another search page to bug tracker that will give a
you a matrix of all the fixes performed between date X and Y looking
something like thisBUG # | Branch X | Branch Y | Branch Z | ...
1223 | (date) | (date) | | ..It would solve your problem, I think and would make RM life easier in
terms of tracking fix syncronizationhi everyone,
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make them
overly complex to use and people just get frustrated with them and
don't
report bugs as the result.aplogies if what comes is just a little verbose...
for those who don't have the luxury of "building from the latest CVS
snapshot", the current tracker is sorely missing some kind of better
integration with your version control system.by a couple orders of magnitude the largest amount of time i spend on
maintaining the debian php packages is the result of going on treasure
hunts through your cvs logs and commit lists trying to find just which
commits map to a particular (usually security vulnerability) bug, and
then making sure that there were no regressions in the fix addressed by
later commits. take the last issue with the Zip::extractTo()...while you might not consider my request important enough to address
(i.e. "we don't support 3rd-party distros so we won't go out of our way
on this"), this has implications for intra-project issues as well.for example, when a bug affects multiple branches, those doing RM work
would probably be interested in knowing that the fix was applied to each
of the relevant branches.while i'm sure there are more technical ways of integrating support
for this, one very easy way is to just map CVS/svn/etc commits to bug
reports transparently. if a commit contains something like '#nnnn' in
the commit message, you could have it post the commit info to the
tracker.
then a quick read of the bug report should be the only thing necessary
to know if each of the branches have recieved a fix. and as a side
effect it would also solve the problem for those of us who
package/distribute php externally...anyway, sorry if this is hijacking the thread just a bit, but having
just spent a large part of my "free time" doing some of this stuff,
i felt compelled to throw this in.seanIlia Alshanetsky
Decided to start from scratch....
Even tho I didnt finish it, the code I wrote has built into something
bigger which is also open source
I just didnt have time to come back to work on the bug tracker during Uni,
has and still is very busy
On Mon, 26 Jan 2009 10:52:22 +0000, Scott MacVicar scott@macvicar.net
wrote:
Jani Taskinen wrote:
See: http://cvs.php.net/viewvc.cgi/pear/Bugtracker/
That's the pear bug tracker modified for all pear/pecl/php bugs I worked
on about 1.5years ago. :) It has that roadmap thing..The one Barry worked on for GSoC 2008 is at
http://cvs.php.net/viewvc.cgi/bugtrackerI've only just realised that this isn't a fork of the current tracker, I
assumed it was and had been extending the current one.Scott
Ilia Alshanetsky wrote:
Sean,
You make some very good points and I'll be the first to agree there is
definitely a room to improve the existing bug-tracker, in particular
its integration with the repository commits, but I do not think it
needs a fundamental rewrite. From what I can see most (I think its
all, but being careful with generalization here) developers already
put "Fixed bug #..." in their bug fixing commits. I would be fairly
trivial to add a regex to grab those and automatically close the bug
report and even add a link to the diff. As far as branch fix tracking,
it could be as simple as adding another SQL table to the bug tracker
along the lines of:CREATE TABLE bug_fix_revisions (
bug_id integer not null,
branch varchar(25),
date timestamp
);We could then add another search page to bug tracker that will give a
you a matrix of all the fixes performed between date X and Y looking
something like thisBUG # | Branch X | Branch Y | Branch Z | ...
1223 | (date) | (date) | | ..It would solve your problem, I think and would make RM life easier in
terms of tracking fix syncronizationhi everyone,
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug trackers make them
overly complex to use and people just get frustrated with them and
don't
report bugs as the result.aplogies if what comes is just a little verbose...
for those who don't have the luxury of "building from the latest CVS
snapshot", the current tracker is sorely missing some kind of better
integration with your version control system.by a couple orders of magnitude the largest amount of time i spend on
maintaining the debian php packages is the result of going on treasure
hunts through your cvs logs and commit lists trying to find just which
commits map to a particular (usually security vulnerability) bug, and
then making sure that there were no regressions in the fix addressed
by
later commits. take the last issue with the Zip::extractTo()...while you might not consider my request important enough to address
(i.e. "we don't support 3rd-party distros so we won't go out of our
way
on this"), this has implications for intra-project issues as well.for example, when a bug affects multiple branches, those doing RM work
would probably be interested in knowing that the fix was applied to
each
of the relevant branches.while i'm sure there are more technical ways of integrating support
for this, one very easy way is to just map CVS/svn/etc commits to bug
reports transparently. if a commit contains something like '#nnnn' in
the commit message, you could have it post the commit info to the
tracker.
then a quick read of the bug report should be the only thing necessary
to know if each of the branches have recieved a fix. and as a side
effect it would also solve the problem for those of us who
package/distribute php externally...anyway, sorry if this is hijacking the thread just a bit, but having
just spent a large part of my "free time" doing some of this stuff,
i felt compelled to throw this in.seanIlia Alshanetsky
Finishing what exactly?
I ran out of time within the GSoC time period to finish it fully...
Its not fully working and functional..
Uni got in the way of me finishing it in my own time.
I'd like to add the bugtracker idea again.. but the last year
bugtracker gsoc turned into something completely different and not at
all usable for php.net.-Hannes
What do you mean it turned in to something completely different.
Its worth noting that I didnt apply to do the bug tracker, but "pecl
website improvements and other things" but ended up bugtracking....
Barry
Of course being mentor for the past 2 years I want to be a mentor
again this year. But there are a few things we need to fix. I sent an
email to the other mentors about 3 months ago about things that went
"not-so-well" last year.
Here are a few things that were suggested and came out of this
"discussion" that we should do in order to improve this year's GSoC.
-
Students to send weekly or bi-weekly emails to public lists to
inform of progress and ask for help if needed (After all it's open
source not only the mentor can help :P) - we should make sure we
strictly follow this rule as last year it was somewhat forgotton. -
Having a blog where each student has to post about (This could
maybe be used instead of the weekly mailing list email?) -
A public repository for all the projects within PHP GSoC. Easily
findable and browsable. -
If a private list incurs then a CC to the public development
mailing should be done. -
2 mentors per project (this was mentioned above)
EOF;
Basically what has to be remembered from last year is that even though
some projects did very well and our organizational activities got
better than the year before, we still lacked communication within the
PHP GSoC projects in general. For instance I left on honeymoon for a
tad longer than expected and no one knew what was happening with my
student, it was hosted on another CVS server and only one person from
that other server was available but without me telling the admins of
the project, it was quite complex for them to retrieve and get CVS
access to which repository. Luckily enough Derick was the admin of the
other CVS repo so he got us fixed but the problem still remained that
with the lack of communication, my student, the admins and me were all
in the dark about the student's progress.
After the midterms started a weekly email, with a lot more
communication and the project developed a whole lot faster, the
student obviously gained confidence and commited a whole lot more to
the project.
I'm know some other mentors have some other stories they could share
but what I'm trying to outline here is that communication is the key,
and the more people ready and able to help can make the project go
much faster, make the student feel much more in control and make a
solid final product.
Should we start a "regulations and procedures to follow" page on the
wiki and simply go from there?
--
Slan,
David