# GSoC 2009

- Thread: https://externals.io/message/42759
- Original archive: https://news-web.php.net/php.internals/42759
- Started by Scott MacVicar on 2009-01-21T22:19:56+00:00
- Messages: 27
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/42759.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #42759 — Scott MacVicar — 2009-01-21T22:19:56+00:00

URL: https://externals.io/message/42759#42759

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"?

---

## #42761 — Elizabeth M Smith — 2009-01-21T23:03:06+00:00

URL: https://externals.io/message/42759#42761 · In reply to: #42759

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

---

## #42767 — Hannes Magnusson — 2009-01-22T08:04:48+00:00

URL: https://externals.io/message/42759#42767 · In reply to: #42761

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

---

## #42768 — david.zuelke@bitextender.com — 2009-01-22T08:34:41+00:00

URL: https://externals.io/message/42759#42768 · In reply to: #42767

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:
> > […]
>
> 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

---

## #42769 — Pierre Joye — 2009-01-22T09:38:30+00:00

URL: https://externals.io/message/42759#42769 · In reply to: #42767

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:
> > […]
>
> 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

http://blog.thepimp.net | http://www.libgd.org

---

## #42782 — Graham Kelly — 2009-01-22T15:53:28+00:00

URL: https://externals.io/message/42759#42782 · In reply to: #42769

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:
> > […]
>
> 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
>
> http://blog.thepimp.net | http://www.libgd.org

---

## #42799 — Andrei Zmievski — 2009-01-23T21:37:18+00:00

URL: https://externals.io/message/42759#42799 · In reply to: #42759

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

---

## #42800 — barry@barrycarlyon.co.uk — 2009-01-23T22:09:23+00:00

URL: https://externals.io/message/42759#42800 · In reply to: #42799

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:
> > […]
> 
> I can try being a mentor again. :)
> 
> -Andrei

---

## #42803 — Hannes Magnusson — 2009-01-23T23:35:26+00:00

URL: https://externals.io/message/42759#42803 · In reply to: #42800

> 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

---

## #42809 — Sebastian Bergmann — 2009-01-24T06:19:51+00:00

URL: https://externals.io/message/42759#42809 · In reply to: #42803

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

---

## #42810 — barry@barrycarlyon.co.uk — 2009-01-24T06:40:35+00:00

URL: https://externals.io/message/42759#42810 · In reply to: #42803

> 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

---

## #42811 — David Coallier — 2009-01-24T12:27:03+00:00

URL: https://externals.io/message/42759#42811 · In reply to: #42810

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.

1. 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.

2. Having a blog where each student has to post about (This could
maybe be used instead of the weekly mailing list email?)

3. A public repository for all the projects within PHP GSoC. Easily
findable and browsable.

4. If a private list incurs then a CC to the public development
mailing should be done.

5. 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

---

## #42814 — Ilia Alshanetsky — 2009-01-24T16:40:08+00:00

URL: https://externals.io/message/42759#42814 · In reply to: #42809

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:
> > […]
>
> 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

---

## #42818 — Lukas Kahwe Smith — 2009-01-25T13:29:54+00:00

URL: https://externals.io/message/42759#42818 · In reply to: #42814

> 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

---

## #42819 — sean finney — 2009-01-25T14:05:37+00:00

URL: https://externals.io/message/42759#42819 · In reply to: #42814

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

---

## #42820 — barry@barrycarlyon.co.uk — 2009-01-25T14:17:31+00:00

URL: https://externals.io/message/42759#42820 · In reply to: #42819

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,
> 
> 
> > […]
> 
> > […]
> 
> 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

---

## #42821 — Hannes Magnusson — 2009-01-25T14:35:20+00:00

URL: https://externals.io/message/42759#42821 · In reply to: #42820

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......

I did: http://php.markmail.org/message/qfdvnpspq2tqpdqu?q=gsoc+list:net.php.lists.internals+from:%22Hannes+Magnusson%22

-Hannes

---

## #42822 — Graham Kelly — 2009-01-25T15:17:11+00:00

URL: https://externals.io/message/42759#42822 · In reply to: #42821

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.
>
> 
> > […]
>
> I did:
> http://php.markmail.org/message/qfdvnpspq2tqpdqu?q=gsoc+list:net.php.lists.internals+from:%22Hannes+Magnusson%22
>
> -Hannes

---

## #42823 — Lukas Kahwe Smith — 2009-01-25T15:22:06+00:00

URL: https://externals.io/message/42759#42823 · In reply to: #42822

> 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

---

## #42827 — sean finney — 2009-01-25T16:02:58+00:00

URL: https://externals.io/message/42759#42827 · In reply to: #42820

> 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

---

## #42828 — david.zuelke@bitextender.com — 2009-01-25T16:12:53+00:00

URL: https://externals.io/message/42759#42828 · In reply to: #42818

Am 25.01.2009 um 14:29 schrieb Lukas Kahwe Smith:

>
> 
>
> > […]
>
> 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

---

## #42830 — Scott MacVicar — 2009-01-25T16:22:33+00:00

URL: https://externals.io/message/42759#42830 · In reply to: #42823

>
> 
>
> > […]
>
>
> 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

---

## #42831 — Pierre Joye — 2009-01-25T16:38:59+00:00

URL: https://externals.io/message/42759#42831 · In reply to: #42830

> 
>
> > […]
>
> 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:

1. the project is completely new and cannot be developed in an
existing module (be svn or cvs):
  - use php.net's svn for it

2. 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

http://blog.thepimp.net | http://www.libgd.org

---

## #42832 — Ilia Alshanetsky — 2009-01-25T18:59:00+00:00

URL: https://externals.io/message/42759#42832 · In reply to: #42819

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,
>
> 
> > […]
>
> 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

---

## #42844 — Jani Taskinen — 2009-01-26T10:45:03+00:00

URL: https://externals.io/message/42759#42844 · In reply to: #42832

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 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
> 
> 
> 
> 
> > […]
> 
> Ilia Alshanetsky

---

Next page: https://externals.io/message/42759.md?page=2