Menu
▾
▴
phpbt-dev — Developer's mailing list and cvs commits
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(34) |
Aug
(215) |
Sep
(180) |
Oct
(135) |
Nov
(105) |
Dec
(81) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(76) |
Feb
(22) |
Mar
(154) |
Apr
(149) |
May
(128) |
Jun
(94) |
Jul
(14) |
Aug
(24) |
Sep
(77) |
Oct
(52) |
Nov
(22) |
Dec
(6) |
| 2003 |
Jan
(4) |
Feb
(10) |
Mar
(6) |
Apr
(29) |
May
(10) |
Jun
(37) |
Jul
(39) |
Aug
(13) |
Sep
(23) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
| 2004 |
Jan
|
Feb
(10) |
Mar
(4) |
Apr
|
May
(35) |
Jun
(4) |
Jul
(17) |
Aug
(6) |
Sep
(14) |
Oct
(18) |
Nov
(2) |
Dec
(14) |
| 2005 |
Jan
(9) |
Feb
(30) |
Mar
(6) |
Apr
|
May
(38) |
Jun
(23) |
Jul
(21) |
Aug
(76) |
Sep
(50) |
Oct
(51) |
Nov
(13) |
Dec
|
|
From: Benjamin C. <php...@be...> - 2005-09-23 11:42:25
|
Actually, I meant the changes to the Italian translation and the bug history fix. I can look at the others, too, though. :) Creating a branch for a new release means the beginning of alpha or beta testing, with no features added to the branch (all new features always go to HEAD). On Sep 22, 2005, at 11:16 AM, Ulf Erikson wrote: > * Benjamin Curtis [2005-09-22 15:37]: > >> Ulf, I still owe you a response to your roadmap email from a few >> days ago, so I'll just do it here. :) I'm planning on adding >> your two latest commits to the 1.0 branch and making a 1.0.2 >> release. >> > > Do you mean these two? > > * Permissions fixes: > http://sourceforge.net/mailarchive/message.php?msg_id=12794116 > > * Obvious faults in the Oracle specific code: > http://sourceforge.net/mailarchive/message.php?msg_id=12794118 > > > Please don't forget > * Updated Italian translation: > http://sourceforge.net/tracker/index.php? > func=detail&aid=1292068&group_id=14939&atid=314939 > > > I've also got this old patch that might "fix" Bug #1277490 -- assign > http://sourceforge.net/tracker/index.php? > func=detail&aid=1277490&group_id=14939&atid=114939 > * Group permissions "editor" > http://sourceforge.net/mailarchive/message.php?msg_id=10827345 > > > >> As far as 1.1 and beyond is concerned, I don't think we need to do >> an odd-even release numbering scheme. I think we should just add >> a few features, branch for testing, make another 1.x release, and >> repeat. >> > > Sounds like a plan. When are we entering the 1.1 test phase? And > what will that mean? alpha/beta/rc? How will the testing be done? > Would you like restrictions on commits? reviews? > > /Ulf > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or > your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/ > geronimo.php > _______________________________________________ > phpbt-dev mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpbt-dev > |
|
From: Benjamin C. <php...@be...> - 2005-09-23 11:37:58
|
Heh, this was exactly my intent with Tesly - http://www.tesly.com/. :) On Sep 22, 2005, at 8:43 AM, Sharif Khan wrote: > Just some input on a feature I feel would be beneficial. That is, > linking TestLink with phpBugTracker. They are both open source and > would work wonderfully. > > Features: > 1) Cross-linking of bugs to Test Case > 2) Cross-linking of Test Cases to bugs > 3) Ability to fail a Test Case and auto-insert into > phpBugTracker. > 4) Use TestLink to do queries, status, metrics, etc. > 5) More... (I'm sure there's a lot more) > > Check out TestLink. I use these two tools and they work great > together. > Creating a solution instead of just a product will be a great strength > leveraging products that are already good independently. For your > consideration, > > Sincerely, > > Sharif Khan > > > > -----Original Message----- > From: php...@li... > [mailto:php...@li...] On Behalf Of Ulf > Erikson > Sent: Thursday, September 22, 2005 8:27 AM > To: php...@li... > Cc: php...@li... > Subject: RE: [phpBT-dev] RE: [Phpbt-users] Bug fixes or features? > > >>> I'm thinking of "stability" in areas such as the database >>> schemas and the translatable strings.. >>> > > Considering that v1.0.1 has been released with a small fix it might be > possible to talk Benjamin into accepting more fixes for a stable 1.0.x > series. I've got a few patches in the pipeline waiting for comments.. > > >>> I have only used phpBT for about half a year, but looking at >>> the mail archives it is clear that it took over a year to go >>> from rc1 to final release of v1.0. Still, half the >>> translations from 0.9 had falled out together with support >>> for Oracle. >>> >> >> (Just thinking out loud): A database abstraction layer might be nice. >> > > > Currently Pear:DB is used, but it doesn't abstract much more than the > API calls. You must handle all differencies in SQL dialects yourself. > phpBugTracker isolates them in a set of inc/db/*.php files. One for > each > dialect. > > I think SQL-Fairy should be able to translate an SQL-query from one > dialect to another. Maybe that would be a way to help translate our > queries? > > >>> Yes, downloadable bundles would have to be offered at >>> strategic points. >>> Testing could then be focused on the newly added/repaired >>> parts. Any chance you can help with a test plan? Something >>> simple with a bit of a guideline for new testers. >>> >> >> I am keen to see this project gather some momentum again. Count >> me in >> > :) > > Great:) What support would you need to help out the best? I guess you > would have no problems gaining web or cvs access from Benjamin. Maybe > information over what goes on in the codebase today, future plans, > etc. > are as important? Would the phpbt-dev mailing list be a good > channel for > such? > > >>>> * What new features would you expect in a new release? >>>> >>>> Should we set up an opinion poll for all users to contribute their >>>> > > >>>> thoughts to? >>>> >>> >>> Sounds good. Ideas on how to handle it? >>> >> >> Well, I don't mind coding a PHP-driven questionnaire, but the real >> question >> is how to structure the questions. >> > > I tried to start with an open question :) Is there anything seriously > missing? > > There is also a list of already requested features at > sourceforge.net. A > voting session could help to determine what is most wanted. > > >> I don't really think there is a golden rule here. One way the testing >> could >> be approached is risk-based: Use a forum, where developers express >> concerns >> over the areas that they perceive currently have the greatest risk - >> consequently, more testing effort can focus in that area. >> > > Do you have any experience in automated testing tools for web > applications? I would guess that much of the basic functionality could > be tested that way to quickly detect changes that seriously break > something else. > > >> It really depends how much creative freedom developers are allowed - >> > the > >> more they want, the more fluid testing must be (And the harder it is >> > to > >> manage). The more structured/controlled the dev process, good >> testing >> becomes more manageable. >> > > Benjamin once mentioned that he would like to use test driven > development if he had to start all over. I'm pretty sure that you can > get support for a more controlled development process if you in return > help managing the tests. > > -- > Ulf > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your > very > own Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > _______________________________________________ > Phpbt-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpbt-users > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or > your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/ > geronimo.php > _______________________________________________ > Phpbt-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpbt-users > |
|
From: Steve D. - C. <ste...@cu...> - 2005-09-23 08:17:07
|
Hi, I'm away for 9 days starting today, so don't think I'm ignoring the list! Will respond properly on my return, from 3 Oct. Kr, Steve Ps. Nice suggestion Sharif. |
|
From: Ulf E. <ulf...@us...> - 2005-09-22 20:52:03
|
Update of /cvsroot/phpbt/phpbt/templates/default In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30438/templates/default Modified Files: bugdisplay.html bughistory.html bugvotes.html Log Message: Fix to recall posinfo after visiting bughistory and bugvotes Index: bugdisplay.html =================================================================== RCS file: /cvsroot/phpbt/phpbt/templates/default/bugdisplay.html,v retrieving revision 1.52 retrieving revision 1.53 diff -u -r1.52 -r1.53 --- bugdisplay.html 9 Sep 2005 20:20:10 -0000 1.52 +++ bugdisplay.html 22 Sep 2005 20:51:50 -0000 1.53 @@ -237,17 +237,17 @@ <div align="center" class="bugdisplaylinks"> <?php if (isset($_SESSION['uid']) && !empty($_SESSION['uid'])) { ?> <?php if (!$already_bookmarked) { ?> - <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=addbookmark&bugid=<?php echo $bug_id; ?>"><?php echo translate("Bookmark this bug"); ?></a></b> | + <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=addbookmark&bugid=<?php echo $bug_id.$posinfo; ?>"><?php echo translate("Bookmark this bug"); ?></a></b> | <?php } else { ?> - <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=delbookmark&bugid=<?php echo $bug_id; ?>"><?php echo translate("Remove bookmark for this bug"); ?></a></b> | + <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=delbookmark&bugid=<?php echo $bug_id.$posinfo; ?>"><?php echo translate("Remove bookmark for this bug"); ?></a></b> | <?php } ?> <?php if (!empty($error['vote'])) echo "<div class=\"error\">{$error['vote']}</div>" ?> - <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=vote&bugid=<?php echo $bug_id; ?>" onClick="if (<?php echo $already_voted; ?>) { alert ('<?php echo translate("You have already voted for this bug"); ?>'); return false; }"><?php echo translate("Vote for this bug"); ?></a></b> | + <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=vote&bugid=<?php echo $bug_id.$posinfo; ?>" onClick="if (<?php echo $already_voted; ?>) { alert ('<?php echo translate("You have already voted for this bug"); ?>'); return false; }"><?php echo translate("Vote for this bug"); ?></a></b> | <?php } ?> - <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=viewvotes&bugid=<?php echo $bug_id; ?>"><?php echo translate("View votes"); ?> (<?php echo $num_votes; ?>)</a></b> | - <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=history&bugid=<?php echo $bug_id; ?>"><?php echo translate("View bug history"); ?></a></b> + <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=viewvotes&bugid=<?php echo $bug_id.$posinfo; ?>"><?php echo translate("View votes"); ?> (<?php echo $num_votes; ?>)</a></b> | + <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=history&bugid=<?php echo $bug_id.$posinfo; ?>"><?php echo translate("View bug history"); ?></a></b> <!-- - | <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=print&bugid=<?php echo $bug_id; ?>"><?php echo translate("Printable View"); ?></a></b> + | <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=print&bugid=<?php echo $bug_id.$posinfo; ?>"><?php echo translate("Printable View"); ?></a></b> --> </div> <br><br> Index: bughistory.html =================================================================== RCS file: /cvsroot/phpbt/phpbt/templates/default/bughistory.html,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- bughistory.html 9 Sep 2005 20:22:25 -0000 1.7 +++ bughistory.html 22 Sep 2005 20:51:50 -0000 1.8 @@ -32,6 +32,6 @@ <?php } ?> </table> <br> -<a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=show&bugid=<?php echo $_GET['bugid']; ?>"><?php echo translate("Back to bug"); ?></a> +<a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=show&bugid=<?php echo $_GET['bugid'].$posinfo; ?>"><?php echo translate("Back to bug"); ?></a> <br> <br> Index: bugvotes.html =================================================================== RCS file: /cvsroot/phpbt/phpbt/templates/default/bugvotes.html,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- bugvotes.html 25 Oct 2004 12:07:04 -0000 1.5 +++ bugvotes.html 22 Sep 2005 20:51:50 -0000 1.6 @@ -17,6 +17,6 @@ <?php } ?> </table> <br> -<a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=show&bugid=<?php echo $_GET['bugid']; ?>"><?php echo translate("Back to bug"); ?></a> +<a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=show&bugid=<?php echo $_GET['bugid'].$posinfo; ?>"><?php echo translate("Back to bug"); ?></a> <br> <br> |
|
From: Ulf E. <ulf...@us...> - 2005-09-22 20:51:59
|
Update of /cvsroot/phpbt/phpbt In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30438 Modified Files: bug.php Log Message: Fix to recall posinfo after visiting bughistory and bugvotes Index: bug.php =================================================================== RCS file: /cvsroot/phpbt/phpbt/bug.php,v retrieving revision 1.147 retrieving revision 1.148 diff -u -r1.147 -r1.148 --- bug.php 20 Sep 2005 18:49:39 -0000 1.147 +++ bug.php 22 Sep 2005 20:51:49 -0000 1.148 @@ -29,6 +29,13 @@ function vote_view($bug_id) { global $u, $db, $t; + if (isset($_REQUEST['pos']) && is_numeric($_REQUEST['pos'])) { + $posinfo = "&pos={$_REQUEST['pos']}"; + } else { + $posinfo = ''; + } + $t->assign(array('posinfo' => $posinfo)); + $t->assign('votes', $db->getAll('select login, v.created_date '.'from '.TBL_AUTH_USER.' u, '.TBL_BUG_VOTE." v where u.user_id = v.user_id and bug_id = $bug_id order by v.created_date")); $t->render('bugvotes.html', translate("Bug Votes")); } @@ -66,8 +73,8 @@ do_changedfields($u, $buginfo, $changedfields); } } - if (isset($_POST['pos'])) { - $posinfo = "&pos={$_POST['pos']}"; + if (isset($_REQUEST['pos']) && is_numeric($_REQUEST['pos'])) { + $posinfo = "&pos={$_REQUEST['pos']}"; } else { $posinfo = ''; } @@ -133,6 +140,13 @@ return; } + if (isset($_REQUEST['pos']) && is_numeric($_REQUEST['pos'])) { + $posinfo = "&pos={$_REQUEST['pos']}"; + } else { + $posinfo = ''; + } + $t->assign(array('posinfo' => $posinfo)); + $t->assign('history', $db->getAll(sprintf($QUERY['bug-history'], $db->quote($bugid)))); $t->render('bughistory.html', translate("Bug History")); } @@ -724,6 +738,13 @@ 'comments' => $db->getAll('select comment_text, c.created_date, login'.' from '.TBL_COMMENT.' c, '.TBL_AUTH_USER." where bug_id = $bugid and c.created_by = user_id order by c.created_date") )); + if (isset($_REQUEST['pos']) && is_numeric($_REQUEST['pos'])) { + $posinfo = "&pos={$_REQUEST['pos']}"; + } else { + $posinfo = ''; + } + $t->assign(array('posinfo' => $posinfo)); + $t->render('bugdisplay.html', translate("View Bug")); } |
|
From: Ulf E. <ulf...@fa...> - 2005-09-22 18:16:22
|
* Benjamin Curtis [2005-09-22 15:37]: > Ulf, I still owe you a response to your roadmap email from a few days > ago, so I'll just do it here. :) I'm planning on adding your two > latest commits to the 1.0 branch and making a 1.0.2 release. Do you mean these two? * Permissions fixes: http://sourceforge.net/mailarchive/message.php?msg_id=12794116 * Obvious faults in the Oracle specific code: http://sourceforge.net/mailarchive/message.php?msg_id=12794118 Please don't forget * Updated Italian translation: http://sourceforge.net/tracker/index.php?func=detail&aid=1292068&group_id=14939&atid=314939 I've also got this old patch that might "fix" Bug #1277490 -- assign http://sourceforge.net/tracker/index.php?func=detail&aid=1277490&group_id=14939&atid=114939 * Group permissions "editor" http://sourceforge.net/mailarchive/message.php?msg_id=10827345 > As far as 1.1 and beyond is concerned, I don't think we need to do an > odd-even release numbering scheme. I think we should just add a few > features, branch for testing, make another 1.x release, and repeat. Sounds like a plan. When are we entering the 1.1 test phase? And what will that mean? alpha/beta/rc? How will the testing be done? Would you like restrictions on commits? reviews? /Ulf |
|
From: Benjamin C. <php...@be...> - 2005-09-22 13:37:58
|
Ulf, I still owe you a response to your roadmap email from a few days ago, so I'll just do it here. :) I'm planning on adding your two latest commits to the 1.0 branch and making a 1.0.2 release. As far as 1.1 and beyond is concerned, I don't think we need to do an odd-even release numbering scheme. I think we should just add a few features, branch for testing, make another 1.x release, and repeat. On Sep 22, 2005, at 6:27 AM, Ulf Erikson wrote: >>> I'm thinking of "stability" in areas such as the database >>> schemas and the translatable strings.. >>> > > Considering that v1.0.1 has been released with a small fix it might be > possible to talk Benjamin into accepting more fixes for a stable 1.0.x > series. I've got a few patches in the pipeline waiting for comments.. |
|
From: Ulf E. <ulf...@fa...> - 2005-09-22 13:27:36
|
> > I'm thinking of "stability" in areas such as the database > > schemas and the translatable strings.. Considering that v1.0.1 has been released with a small fix it might be possible to talk Benjamin into accepting more fixes for a stable 1.0.x series. I've got a few patches in the pipeline waiting for comments.. > > I have only used phpBT for about half a year, but looking at > > the mail archives it is clear that it took over a year to go > > from rc1 to final release of v1.0. Still, half the > > translations from 0.9 had falled out together with support > > for Oracle. > > (Just thinking out loud): A database abstraction layer might be nice. Currently Pear:DB is used, but it doesn't abstract much more than the API calls. You must handle all differencies in SQL dialects yourself. phpBugTracker isolates them in a set of inc/db/*.php files. One for each dialect. I think SQL-Fairy should be able to translate an SQL-query from one dialect to another. Maybe that would be a way to help translate our queries? > > Yes, downloadable bundles would have to be offered at > > strategic points. > > Testing could then be focused on the newly added/repaired > > parts. Any chance you can help with a test plan? Something > > simple with a bit of a guideline for new testers. > > I am keen to see this project gather some momentum again. Count me in :) Great:) What support would you need to help out the best? I guess you would have no problems gaining web or cvs access from Benjamin. Maybe information over what goes on in the codebase today, future plans, etc. are as important? Would the phpbt-dev mailing list be a good channel for such? > > > * What new features would you expect in a new release? > > > > > > Should we set up an opinion poll for all users to contribute their > > > thoughts to? > > > > Sounds good. Ideas on how to handle it? > > Well, I don't mind coding a PHP-driven questionnaire, but the real > question > is how to structure the questions. I tried to start with an open question :) Is there anything seriously missing? There is also a list of already requested features at sourceforge.net. A voting session could help to determine what is most wanted. > I don't really think there is a golden rule here. One way the testing > could > be approached is risk-based: Use a forum, where developers express > concerns > over the areas that they perceive currently have the greatest risk - > consequently, more testing effort can focus in that area. Do you have any experience in automated testing tools for web applications? I would guess that much of the basic functionality could be tested that way to quickly detect changes that seriously break something else. > It really depends how much creative freedom developers are allowed - the > more they want, the more fluid testing must be (And the harder it is to > manage). The more structured/controlled the dev process, good testing > becomes more manageable. Benjamin once mentioned that he would like to use test driven development if he had to start all over. I'm pretty sure that you can get support for a more controlled development process if you in return help managing the tests. -- Ulf |
|
From: Ulf E. <ulf...@us...> - 2005-09-20 18:49:51
|
Update of /cvsroot/phpbt/phpbt In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26573 Modified Files: bug.php Log Message: Bug #924226 -- Some changes to bugs not captured in history. Added "priority" and "dependency" to the bug history Index: bug.php =================================================================== RCS file: /cvsroot/phpbt/phpbt/bug.php,v retrieving revision 1.146 retrieving revision 1.147 diff -u -r1.146 -r1.147 --- bug.php 9 Sep 2005 20:22:25 -0000 1.146 +++ bug.php 20 Sep 2005 18:49:39 -0000 1.147 @@ -149,7 +149,7 @@ $template = $newbug ? "bugemail-newbug.$template_ext" : "bugemail.$template_ext"; foreach(array('title','url') as $field) { if (isset($cf[$field])) { - $db->query('insert into '.TBL_BUG_HISTORY.' (bug_id, changed_field, old_value, new_value, created_by, created_date) values ('. join(', ', array($buginfo['bug_id'], $db->quote($field), $db->quote(stripslashes($buginfo[$field])), $db->quote(stripslashes($cf[$field])), $u, $now)).")"); + $db->query('insert into '.TBL_BUG_HISTORY.' (bug_id, changed_field, old_value, new_value, created_by, created_date) values ('. join(', ', array($buginfo['bug_id'], $db->quote(translate($field)), $db->quote(stripslashes($buginfo[$field])), $db->quote(stripslashes($cf[$field])), $u, $now)).")"); $t->assign(array( $field => stripslashes($cf[$field]), $field.'_stat' => '!' @@ -178,6 +178,12 @@ ); foreach($cfgDatabase as $field => $table) { + if (isset($buginfo[$field]) && !isset($buginfo[$field.'_id'])) { + $buginfo[$field.'_id'] = $buginfo[$field]; + } + if (isset($cf[$field]) && !isset($cf[$field.'_id'])) { + $cf[$field.'_id'] = $cf[$field]; + } if (isset($buginfo[$field.'_id'])) { $oldvalue = $db->getOne("select ${field}_name from $table"." where ${field}_id = {$buginfo[$field.'_id']}"); } @@ -418,15 +424,26 @@ return; } + $old_dependencies = delimit_list(', ', $db->getCol("select depends_on from ".TBL_BUG_DEPENDENCY." where bug_id = $bugid")); // Add it $db->query("insert into ".TBL_BUG_DEPENDENCY." (bug_id, depends_on) values($bugid, $add_dependency)"); + $new_dependencies = delimit_list(', ', $db->getCol("select depends_on from ".TBL_BUG_DEPENDENCY." where bug_id = $bugid")); + + $db->query('insert into '.TBL_BUG_HISTORY.' (bug_id, changed_field, old_value, new_value, created_by, created_date) values('. join(', ', array($bugid, $db->quote(translate("dependency")), $db->quote($old_dependencies), $db->quote($new_dependencies), $u, $now)).")"); } // Remove dependency if requested if (!empty($del_dependency)) { $del_dependency = preg_replace('/\D/', '', $del_dependency); if (is_numeric($del_dependency)) { - $db->query("delete from ".TBL_BUG_DEPENDENCY." where bug_id = $bugid and depends_on = $del_dependency"); + // Check if the dependency has already been added + if ($db->getOne('select count(*) from '.TBL_BUG_DEPENDENCY." where bug_id = $bugid and depends_on = $del_dependency")) { + $old_dependencies = delimit_list(', ', $db->getCol("select depends_on from ".TBL_BUG_DEPENDENCY." where bug_id = $bugid")); + $db->query("delete from ".TBL_BUG_DEPENDENCY." where bug_id = $bugid and depends_on = $del_dependency"); + $new_dependencies = delimit_list(', ', $db->getCol("select depends_on from ".TBL_BUG_DEPENDENCY." where bug_id = $bugid")); + + $db->query('insert into '.TBL_BUG_HISTORY.' (bug_id, changed_field, old_value, new_value, created_by, created_date) values('. join(', ', array($bugid, $db->quote(translate("dependency")), $db->quote($old_dependencies), $db->quote($new_dependencies), $u, $now)).")"); + } } } |
|
From: Ulf E. <ulf...@us...> - 2005-09-20 18:42:35
|
Update of /cvsroot/phpbt/phpbt/languages In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25056/languages Modified Files: it.php Log Message: Italian Language update by Alessandro Staltari Index: it.php =================================================================== RCS file: /cvsroot/phpbt/phpbt/languages/it.php,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- it.php 27 Aug 2005 13:17:34 -0000 1.4 +++ it.php 20 Sep 2005 18:42:20 -0000 1.5 @@ -1,5 +1,6 @@ <?php -// it.php - Italian strings and titles à éì +// it.php - Italian strings and titles +// Translation by Alessandro Staltari <staltari(a)geocities.com> // ------------------------------------------------------------------------ // Copyright (c) 2001 - 2004 The phpBugTracker Group // ------------------------------------------------------------------------ @@ -90,7 +91,7 @@ "Please enter a name" => "Prego inserire un nome", "Edit Database" => "Modifica Database", "Database List" => "Lista Database", - "Edit Group" => "Modifica Grouppo", + "Edit Group" => "Modifica Gruppo", "Group List" => "Lista Gruppi", "Edit Operating System" => "Modifica Sistema Operativo", "Operating System List" => "Lista Sistemi Operativi", @@ -139,7 +140,7 @@ "Assignable" => "Assegnabile", "Find Bug" => "Cerca Bug", "Projects" => "Progetti", - "Groups" => "Grouppi", + "Groups" => "Gruppi", "Documentation" => "Documentazione", "User Tools" => "Strumenti Utente", "Statuses" => "Stati", @@ -152,7 +153,7 @@ "Add new operating system" => "Aggiungi nuovo Sistema Operativo", "Are you sure you want to delete this OS" => "Sei sicuro di voler elimare questo SO", "Items with a Sort Order = 0 will not be selectable by users." => "Gli elementi con Ordinamento = 0 non saranno selezionabili dagli utenti.", - "Only those items that have no bugs referencing them can be deleted." => "Solo gli elementi con non hanno bug collegati possono essere eliminati.", + "Only those items that have no bugs referencing them can be deleted." => "Solo gli elementi che non hanno bug collegati possono essere eliminati.", "Project Information" => "Informazioni sul Progetto", "Version Information" => "Informazioni sulla Versione", "Initial Version" => "Versione iniziale", @@ -203,7 +204,7 @@ "Posted by" => "Inviato da", "Back to bug" => "Ritorna al bug", "You must login to modify this bug" => "Devi accedere per modificare questo bug", - "Return to bug list" => "Returna alla lista dei bug", + "Return to bug list" => "Ritorna alla lista dei bug", "Previous bug" => "Bug precedente", "Next bug" => "Bug successivo", "To be closed in version" => "Da chiudere nella versione", @@ -351,4 +352,3 @@ ); ?> - |
|
From: Steve D. - C. <ste...@cu...> - 2005-09-19 21:46:22
|
> I'm thinking of "stability" in areas such as the database > schemas and the translatable strings.. Ok, I see. > I have only used phpBT for about half a year, but looking at > the mail archives it is clear that it took over a year to go > from rc1 to final release of v1.0. Still, half the > translations from 0.9 had falled out together with support > for Oracle. (Just thinking out loud): A database abstraction layer might be nice. <snip> > Yes, downloadable bundles would have to be offered at > strategic points. > Testing could then be focused on the newly added/repaired > parts. Any chance you can help with a test plan? Something > simple with a bit of a guideline for new testers. I am keen to see this project gather some momentum again. Count me in :) > I'm not too sure about forcing testers to register.. Wouldn't > that cut their number down from few to very few? To be honest I have no idea on the numbers here, but given the paucity of responses to this message, I'd argue that this is a moot point. If we did encourage a core group of testers to make themselves known, collaborate, recognise "ownership" in certain areas, etc, that could really help the development process. > > * Is the current development version safe and stable (and feature > > rich and bug free) enough for a new release? > > > > Yes, it is here. > > I meant CVS head. Whoops. I must remember to read all the words in the sentence :) > > * What new features would you expect in a new release? > > > > Should we set up an opinion poll for all users to contribute their > > thoughts to? > > Sounds good. Ideas on how to handle it? Well, I don't mind coding a PHP-driven questionnaire, but the real question is how to structure the questions. I'm not really an expert on that - designing objective questionnaires is (apparently) a bit of an art. Anyone know anyone...? > > * What old bugs would you expect to be fixed in a new release? > > > > I would expect all *known* old bugs to appear fixed in any new > > release, in addition to functional improvememts. :) > > Of course. But the bugs that I know, the ones I can reproduce > and confirm, are not the same as the ones you know. There are > too many different Os:s, web servers, database servers, mail > servers, and web browsers (each one of those applications in > different versions and > configurations) together with the php versions and > configurations, pear versions, and maybe more.. I don't really think there is a golden rule here. One way the testing could be approached is risk-based: Use a forum, where developers express concerns over the areas that they perceive currently have the greatest risk - consequently, more testing effort can focus in that area. It really depends how much creative freedom developers are allowed - the more they want, the more fluid testing must be (And the harder it is to manage). The more structured/controlled the dev process, good testing becomes more manageable. Can we have any more votes on this subject by other list recipients please? :) Thanks, Steve |
|
From: Ulf E. <ulf...@fa...> - 2005-09-16 21:40:38
|
I'm planning to introduce a set of new permissions. There are currently only four permissions in phpBugTracker: Admin, Editbug, EditAssignment, Assignable. I wish to extend this such that it is possible to decide what fields users of the different groups may enter/change/delete as either the report, owner or neither. The discussion half a year ago http://sourceforge.net/mailarchive/message.php?msg_id=10850283 quikly grow into something real big and ambitious. I'll try to keep it a bit simpler this time. It will be configurable, but as extreme as suggested earlier.. I need your help to find a good balance. If you have ideas for a new permission system please let me know. Any editable fields that you wish to control who may edit? Reporter, Owner, Priority, Description, Target version, Status, Closing the bug, or anything else that you need to control? -- Ulf |
|
From: Benjamin C. <php...@be...> - 2005-09-14 12:51:19
|
The fix for the mysqli bug has been released as version 1.0.1. Onward to 1.1. :) |
|
From: Benjamin C. <bc...@us...> - 2005-09-14 12:38:38
|
Update of /cvsroot/phpbt/phpbt In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4274 Modified Files: Tag: releases-1_0 CHANGELOG UPGRADING include.php Log Message: Slight tweaks for release Index: CHANGELOG =================================================================== RCS file: /cvsroot/phpbt/phpbt/CHANGELOG,v retrieving revision 1.70 retrieving revision 1.70.2.1 diff -u -r1.70 -r1.70.2.1 --- CHANGELOG 3 Aug 2005 12:32:31 -0000 1.70 +++ CHANGELOG 14 Sep 2005 12:38:30 -0000 1.70.2.1 @@ -1,3 +1,6 @@ +-- 1.0.1 -- 14 Sep 2005 +: Fixed a bug with the mysqli database layer + -- 1.0 -- 3 Aug 2005 : Added links from project summary on home page (Phil Davis). : Added display of the bug ids a bug blocks. Index: UPGRADING =================================================================== RCS file: /cvsroot/phpbt/phpbt/UPGRADING,v retrieving revision 1.15 retrieving revision 1.15.2.1 diff -u -r1.15 -r1.15.2.1 --- UPGRADING 13 Jul 2005 18:12:00 -0000 1.15 +++ UPGRADING 14 Sep 2005 12:38:30 -0000 1.15.2.1 @@ -2,6 +2,32 @@ if it doesn't, it's better to be safe than sorry. +Upgrading from 1.0 to 1.0.x +--------------------------------- +There are no database changes in this series. Either copy these files +over your current 1.0 installation or copy config.php from that location +to here and point your users to the new location. + + +Upgrading from 1.0 RCx to 1.0 +--------------------------------- + +PEAR and PEAR DB have been removed from the phpBT distribution. If you +have a system-wide install of PEAR that is available in the include +path you should set the new PEAR_PATH constant in config.php to an +empty string (''). To reuse the old pear files from RCx, copy the +inc/pear/ directory and set PEAR_PATH to 'inc/pear/'. + +Using the directory where you unpacked the new set of files... +1. Edit config-dist.php, changing the database settings to match those + from your old config.php (DB_*, TBL_PREFIX and PEAR_PATH constants). + Save config-dist.php as config.php. +2. Either copy the files from the new installation over the old one, or + point your users to the new location. + +There is no need to run the upgrade script. The upgrade is complete. + + Upgrading from 0.9.1 to 1.0 --------------------------- @@ -29,22 +55,3 @@ admin pages. Default settings should be modified so that "resolved", "closed", and "verified" are shown as being closed, and all other statuses are set to open. - - -Upgrading from 1.0 RCx to 1.0 RC6 ---------------------------------- - -PEAR and PEAR DB have been removed from the phpBT distribution. If you -have a system-wide install of PEAR that is available in the include -path you should set the new PEAR_PATH constant in config.php to an -empty string (''). To reuse the old pear files from RCx, copy the -inc/pear/ directory and set PEAR_PATH to 'inc/pear/'. - -Using the directory where you unpacked the new set of files... -1. Edit config-dist.php, changing the database settings to match those - from your old config.php (DB_*, TBL_PREFIX and PEAR_PATH constants). - Save config-dist.php as config.php. -2. Either copy the files from the new installation over the old one, or - point your users to the new location. - -There is no need to run the upgrade script. The upgrade is complete. Index: include.php =================================================================== RCS file: /cvsroot/phpbt/phpbt/include.php,v retrieving revision 1.135 retrieving revision 1.135.2.1 diff -u -r1.135 -r1.135.2.1 --- include.php 20 Jul 2005 18:19:54 -0000 1.135 +++ include.php 14 Sep 2005 12:38:30 -0000 1.135.2.1 @@ -22,7 +22,7 @@ // ------------------------------------------------------------------------ // $Id$ -define('PHPBT_VERSION', '1.0rc6'); +define('PHPBT_VERSION', '1.0.1'); @ini_set("magic_quotes_runtime", 0); @ini_set("magic_quotes_sybase", 0); @ini_set("session.save_handler", "files"); |
|
From: Ulf E. <ulf...@fa...> - 2005-09-14 07:16:53
|
* "Steve Dowe - Cubus" [2005-09-12 15:45 +0100]: > > (snip) Playing nice and maintain a > > stable branch will most likely pay off in the end. > > I think it's important to aim for stability, but in my experience, > there has been little to suggest it is particularly "unstable". I'm thinking of "stability" in areas such as the database schemas and the translatable strings.. I have only used phpBT for about half a year, but looking at the mail archives it is clear that it took over a year to go from rc1 to final release of v1.0. Still, half the translations from 0.9 had falled out together with support for Oracle. A stable branch would allow "low-risk" upgrades. If it used to work it should still work; only better. > Going back to the original points, here are my opinions (and please note, > they apply to a pre-1.0 release as that's what I use): If it is older than rc5 you might want to upgrade to avoid some SQL injection issues.. I hope to improve on the input validation and permission enforcements one day -- phpBT still relies too much on the html template to handle such. > * Should we fix bugs in the 1.0 release and offer regular updates, or > should we spend all energy on developing a new version? > > Are there specific requirements for a new version? Have users registered > their wishes? If there are many feature requests (in terms of time > required > to implement), than I'd suggest fixing only "showstopper" bugs in 1.0 > then > moving on. If there has not been "significant" interest in new features, > better to fix the older one - again, only if there's an outcry for fixes. I have made some changes since the 1.0 release and plan to do some more. It is mainly things that i feel that I need. Some of the ideas I have found in the list of feature requests: http://sourceforge.net/tracker/?atid=364939&group_id=14939&func=browse My interest lies in a more functional phpBT 1.x, but I don't mind contributing towards a less buggy 1.0.x. I do mind however spending a year with a locked-down CVS waiting for others to finalize the last translation or database schema. Especially if that doesn't happen, as in the v1.0 case. If that's the phpBT tradition I rather maintain my own in-house fork.. > * Should the development version be offered as a downloadable snapshot > as > soon as possible, or should we wait until it is safe and stable enough > for > a release? > > As a software tester, I prefer the idea of releasing at key milestones. > This > could be to registered beta testers who have expressed an interest in > fault-finding. Yes, downloadable bundles would have to be offered at strategic points. Testing could then be focused on the newly added/repaired parts. Any chance you can help with a test plan? Something simple with a bit of a guideline for new testers. I'm not too sure about forcing testers to register.. Wouldn't that cut their number down from few to very few? > * Is the current development version safe and stable (and feature rich > and > bug free) enough for a new release? > > Yes, it is here. I meant CVS head. > * What new features would you expect in a new release? > > Should we set up an opinion poll for all users to contribute their > thoughts > to? Sounds good. Ideas on how to handle it? > * What old bugs would you expect to be fixed in a new release? > > I would expect all *known* old bugs to appear fixed in any new release, > in > addition to functional improvememts. :) Of course. But the bugs that I know, the ones I can reproduce and confirm, are not the same as the ones you know. There are too many different Os:s, web servers, database servers, mail servers, and web browsers (each one of those applications in different versions and configurations) together with the php versions and configurations, pear versions, and maybe more.. If you know some bug you must say so, it might not be known to everyone. The list of old bugs are surely not all "known" by me: http://sourceforge.net/tracker/?atid=114939&group_id=14939&func=browse -- Ulf |
|
From: Steve D. - C. <ste...@cu...> - 2005-09-12 14:45:36
|
> -----Original Message----- > From: php...@li... > [mailto:php...@li...] On Behalf Of > Ulf Erikson > Sent: 09 September 2005 15:54 > To: php...@li... > Cc: php...@li... > Subject: Re: [Phpbt-users] Bug fixes or features? > * Peter Parnes [2005-09-09 09:28 +0200]: > > We have learned to live with the bugs that exist and I would be so > > bold/boring to promote a mix of bugfixing and new releases :) > (snip) Playing nice and maintain a > stable branch will most likely pay off in the end. I think it's important to aim for stability, but in my experience, there has been little to suggest it is particularly "unstable". > Now, the one who asked whether a 1.1 feature realease would (snip) > happen. But it looks like it will need some extra hands.. This is a chicken and egg situation. More features might attract more users, who might then want to contribute more features... Going back to the original points, here are my opinions (and please note, they apply to a pre-1.0 release as that's what I use): * Should we fix bugs in the 1.0 release and offer regular updates, or should we spend all energy on developing a new version? Are there specific requirements for a new version? Have users registered their wishes? If there are many feature requests (in terms of time required to implement), than I'd suggest fixing only "showstopper" bugs in 1.0 then moving on. If there has not been "significant" interest in new features, better to fix the older one - again, only if there's an outcry for fixes. If there are neither requests for features nor for fixes, I'd go with developing features (after all, everyone knows the chicken came first ;) ). * Should the development version be offered as a downloadable snapshot as soon as possible, or should we wait until it is safe and stable enough for a release? As a software tester, I prefer the idea of releasing at key milestones. This could be to registered beta testers who have expressed an interest in fault-finding. * Is the current development version safe and stable (and feature rich and bug free) enough for a new release? Yes, it is here. * What new features would you expect in a new release? Should we set up an opinion poll for all users to contribute their thoughts to? * What old bugs would you expect to be fixed in a new release? I would expect all *known* old bugs to appear fixed in any new release, in addition to functional improvememts. :) Just my tuppence-worth... :) Steve |
|
From: Ulf E. <ulf...@us...> - 2005-09-09 20:22:34
|
Update of /cvsroot/phpbt/phpbt/templates/default In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21233/templates/default Modified Files: bughistory.html Log Message: Fix: Bughistory used to show unmasked email for the "assigned_to" field Index: bughistory.html =================================================================== RCS file: /cvsroot/phpbt/phpbt/templates/default/bughistory.html,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- bughistory.html 25 Oct 2004 12:07:04 -0000 1.6 +++ bughistory.html 9 Sep 2005 20:22:25 -0000 1.7 @@ -11,8 +11,17 @@ <tr<?php if ($i % 2) echo ' class="alt" bgcolor="#dddddd"' ?>> <td><?php echo maskemail($history[$i]['login']); ?></td> <td><?php echo $history[$i]['changed_field']; ?></td> - <td> <?php echo $history[$i]['old_value']; ?></td> - <td> <?php echo $history[$i]['new_value']; ?></td> + <td> <?php if ($history[$i]['changed_field'] == translate("Assigned To")) { + echo maskemail($history[$i]['old_value']); + } else { + echo $history[$i]['old_value']; + } ?></td> + <td> <?php if ($history[$i]['changed_field'] == translate("Assigned To")) { + echo maskemail($history[$i]['new_value']); + } else { + echo $history[$i]['new_value']; + } ?></td> + <td align="center"><?php echo date(TIME_FORMAT.' '.DATE_FORMAT, $history[$i]['created_date']); ?></td> </tr> <?php } ?> |
|
From: Ulf E. <ulf...@us...> - 2005-09-09 20:22:34
|
Update of /cvsroot/phpbt/phpbt In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21233 Modified Files: bug.php Log Message: Fix: Bughistory used to show unmasked email for the "assigned_to" field Index: bug.php =================================================================== RCS file: /cvsroot/phpbt/phpbt/bug.php,v retrieving revision 1.145 retrieving revision 1.146 diff -u -r1.145 -r1.146 --- bug.php 8 Sep 2005 20:05:41 -0000 1.145 +++ bug.php 9 Sep 2005 20:22:25 -0000 1.146 @@ -238,7 +238,21 @@ if (is_null($oldassignedto)) { $oldassignedto = ''; } - $db->query('insert into '.TBL_BUG_HISTORY.' (bug_id, changed_field, old_value, new_value, created_by, created_date) values ('. join(', ', array($buginfo['bug_id'], $db->quote(translate("Assigned To")), $db->quote($oldassignedto), $db->quote($assignedto), $u, $now)).")"); + + $oldassignedto_login = $db->getOne('select login from '.TBL_AUTH_USER.' u where u.user_id = '.$buginfo['assigned_to']); + if (is_null($oldassignedto_login)) { + $oldassignedto_login = ''; + } + + $assignedto_login = ''; + if (!empty($cf['assigned_to'])) { + $assignedto_login = $db->getOne('select login from '.TBL_AUTH_USER.' u where u.user_id = '.(!empty($cf['assigned_to']))); + } + if (is_null($assignedto_login)) { + $assignedto_login = ''; + } + + $db->query('insert into '.TBL_BUG_HISTORY.' (bug_id, changed_field, old_value, new_value, created_by, created_date) values ('. join(', ', array($buginfo['bug_id'], $db->quote(translate("Assigned To")), $db->quote($oldassignedto_login), $db->quote($assignedto_login), $u, $now)).")"); } else { $assignedtostat = ' '; } |
|
From: Ulf E. <ulf...@us...> - 2005-09-09 20:20:17
|
Update of /cvsroot/phpbt/phpbt/templates/default In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20457/templates/default Modified Files: bugdisplay.html Log Message: Remove the options to vote or bookmark bugs unless the user is logged on Index: bugdisplay.html =================================================================== RCS file: /cvsroot/phpbt/phpbt/templates/default/bugdisplay.html,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- bugdisplay.html 27 Aug 2005 13:14:28 -0000 1.51 +++ bugdisplay.html 9 Sep 2005 20:20:10 -0000 1.52 @@ -235,6 +235,7 @@ </table> </form> <div align="center" class="bugdisplaylinks"> +<?php if (isset($_SESSION['uid']) && !empty($_SESSION['uid'])) { ?> <?php if (!$already_bookmarked) { ?> <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=addbookmark&bugid=<?php echo $bug_id; ?>"><?php echo translate("Bookmark this bug"); ?></a></b> | <?php } else { ?> @@ -242,6 +243,7 @@ <?php } ?> <?php if (!empty($error['vote'])) echo "<div class=\"error\">{$error['vote']}</div>" ?> <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=vote&bugid=<?php echo $bug_id; ?>" onClick="if (<?php echo $already_voted; ?>) { alert ('<?php echo translate("You have already voted for this bug"); ?>'); return false; }"><?php echo translate("Vote for this bug"); ?></a></b> | +<?php } ?> <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=viewvotes&bugid=<?php echo $bug_id; ?>"><?php echo translate("View votes"); ?> (<?php echo $num_votes; ?>)</a></b> | <b><a href="<?php echo $_SERVER['PHP_SELF']; ?>?op=history&bugid=<?php echo $bug_id; ?>"><?php echo translate("View bug history"); ?></a></b> <!-- |
|
From: Ulf E. <ulf...@us...> - 2005-09-09 20:16:39
|
Update of /cvsroot/phpbt/phpbt/templates/default/admin In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20079/templates/default/admin Modified Files: pagination.html Log Message: Avoid "page 1-0 of 0" as pagination text Index: pagination.html =================================================================== RCS file: /cvsroot/phpbt/phpbt/templates/default/admin/pagination.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- pagination.html 25 Oct 2004 12:07:03 -0000 1.2 +++ pagination.html 9 Sep 2005 20:16:29 -0000 1.3 @@ -1,4 +1,6 @@ -<div align="center" class="pagination"> - <?php echo $first.' - '. $last.' of '. $total; ?> - <?php if ($pages != "1") echo "<br>[ $pages ]"; ?> -</div> +<div align="center" class="pagination"> +<?php if ($total > 0) { ?> + <?php echo $first.' - '. $last.' of '. $total; ?> + <?php if ($pages != "1") echo "<br>[ $pages ]"; ?> +<?php } ?> +</div> |
|
From: Ulf E. <ulf...@fa...> - 2005-09-09 14:54:16
|
* Peter Parnes [2005-09-09 09:28 +0200]: > We have learned to live with the bugs that exist and I would be so > bold/boring to promote a mix of bugfixing and new releases :) I have not used phpBugTracker long enough to have learned to live with its bugs. That's why I started fixing things that annoyed me. My wish too would be to have both bugfixes and new releases. But who should care for that? If I may choose (and i think i may in a free time oss project) I rather fix one bug that annoys me than three that annoys you. But I don't think that's the way to go. Playing nice and maintain a stable branch will most likely pay off in the end. Now, the one who asked whether a 1.1 feature realease would be enough was Benjamin Curtis, the author of phpBugTracker. He doesn't have a lot of time to spend on this project right now. Naturally he tries to cut it to a minimum. If some users find a stable branch worth some efforts we might see it happen. But it looks like it will need some extra hands.. /Ulf |
|
From: Peter P. <Pet...@lt...> - 2005-09-09 07:27:45
|
We have learned to live with the bugs that exist and I would be so=20 bold/boring to promote a mix of bugfixing and new releases :) -Peter Parnes, PhD Associate Professor Media Technology Lule=E5 University of Technology |
|
From: Ulf E. <ulf...@fa...> - 2005-09-08 21:20:58
|
* miah [2005-09-08 16:48]: > I realize manpower on this project is limited. Personally, I'd like to > see Devel Snapshots, and bugs fixed in whatever is currently marked as > stable, unless its such a huge bug that it would take a tremendous > amount of manpower to fix or its already fixed in the dev branch. Its > its something easily mergable to stable then push it back.. Some people > do use this software for production and wont run the devel versions, but > its good to have devel available for testing etc. It shouldn't be all that much development work to merge fixes from cvs head to a stable branch, but we would need more testing to see whether the fixes work as well there (maybe a little fix relies on something bigger that also needs to be merged before it works alright). Is anyone tracking the 1.0 branch? If not, would a 1.0.1 release candidate be needed to get any testing at all before it is declared as better than 1.0? Now you have something that requires time and efforts.. There is also such small things such as saying "Hey, I would like to see this fix on the stable branch as well. Any chance it can be back-ported?" when you see something interesting entering the cvs head. Silence is too easily seen as lack of interest.. and if no one shows interest in a stable branch it is much easier to not have one I too wish to see bug fix updates, but are we big enough to pull that through? What about the old list of bugs. Where can I find people to help sort out what is relevant today and what is not? http://sourceforge.net/tracker/?group_id=14939&atid=114939 /Ulf |
|
From: Ulf E. <ulf...@fa...> - 2005-09-08 21:20:42
|
Hoi, Mail problems are among the most commonly reported problems with pbpBugTracker today. I've written a sort of test page to simplify finding out what switches and options to use in htmlMimeMail to get the mails out on your system. (I've not had any problems with the mail functions myself and maybe not too many of you neither, but I still thought that this could make things simpler for some) To try the new page: Drop mailtest.php in the phpbt/admin/ directory and mailtest.html in phpbt/templates/default/admin/ directory. Log in as an administrator and go to mailtest.php. Fill in any options you like and generate the code. If you like what you see you can run it, and hopefully send a test mail. Not everything testable on the page have configure options in phpBT yet, but I plan to make defines (or database entries) for the names in all capitals. Actually, some part cannot be done with htmlMimeMail either. You can, for instance, not send non-Mime mail with htmlMimeMail ;-) Let me know what you think about the idea. Whether it should be offered by the installer or as an administration page. Should it be extended to also test 'mail', PHPMailer, and the Pear Mail package? It would probably be easy enough to make phpBugTracker use which ever you like, but would anyone care to change mail package if what was offered at first "just worked"? /Ulf |
|
From: Ulf E. <ulf...@us...> - 2005-09-08 20:14:06
|
Update of /cvsroot/phpbt/phpbt/inc/htmlMimeMail In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30678 Modified Files: htmlMimeMail.php smtp.php Log Message: Don't try to send mail over SMTP when the connection failed Index: htmlMimeMail.php =================================================================== RCS file: /cvsroot/phpbt/phpbt/inc/htmlMimeMail/htmlMimeMail.php,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- htmlMimeMail.php 8 Sep 2005 20:05:42 -0000 1.5 +++ htmlMimeMail.php 8 Sep 2005 20:13:58 -0000 1.6 @@ -684,7 +684,11 @@ require_once(dirname(__FILE__) . '/smtp.php'); require_once(dirname(__FILE__) . '/RFC822.php'); $smtp = &smtp::connect($this->smtp_params); - + if ($smtp->status != SMTP_STATUS_CONNECTED) { + $this->errors = $smtp->errors; + return false; + } + // Parse recipients argument for internet addresses foreach ($recipients as $recipient) { $addresses = Mail_RFC822::parseAddressList($recipient, $this->smtp_params['helo'], null, false); Index: smtp.php =================================================================== RCS file: /cvsroot/phpbt/phpbt/inc/htmlMimeMail/smtp.php,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- smtp.php 8 Sep 2005 20:05:42 -0000 1.4 +++ smtp.php 8 Sep 2005 20:13:58 -0000 1.5 @@ -84,7 +84,11 @@ return $obj; }else{ - $this->connection = fsockopen($this->host, $this->port, $errno, $errstr, $this->timeout); + $this->connection = @fsockopen($this->host, $this->port, $errno, $errstr, $this->timeout); + if (!is_resource($this->connection)) { + $this->errors[] = 'Failed to connect to server: '.$errstr; + return FALSE; + } if(function_exists('socket_set_timeout')){ @socket_set_timeout($this->connection, 5, 0); } |
2 messages has been excluded from this view by a project administrator.
