Menu
▾
▴
phpbt-dev
|
From: Ulf E. <ulf...@fa...> - 2005-08-29 19:42:44
Attachments:
patch-releases-1_0.uen.perm.1.txt
|
Benjamin, Could you please look at the attached patch for inclusion in the 1.0 branch? It fixes various permission related issues: * Bugs item #782962 - How to restrain task assignment only to users at admin group * Bugs item #1017788 - Managers Cannot Change Bug Details * Bugs item #1034495 - New user can set another reporter for bug * Bugs item #1060247 - Project Admin cannot change assignments In v1.0 there are three user groups: Admin, User and Developer. There are also three permissions: Admin, EditBug and EditAssignment. But the code checks for the permissions 'Administrator' and 'Manager' as well as the group 'Users'. The patch changes this to check for the 'Admin' permission, whether the developer is a project admin, and whether the user is logged on. Other code changes include giving project admins a link to the admin pages and to only allow (project) admins to alter the reporter. /Ulf |
|
From: Ulf E. <ulf...@fa...> - 2005-08-29 19:50:48
Attachments:
patch-releases-1_0.uen.oci.1.txt
|
* Ulf Erikson [2005-08-29 21:42]: > Could you please look at the attached patch for inclusion in the 1.0 > branch? Almost forgot.. when updating the various schemas I also found two faults in the old Oracle support. 1) There are two syntax errors in inc/db/oci8.php 2) There is no EditAssignment permission in schemas/oci8.in /Ulf |
|
From: Benjamin C. <php...@be...> - 2005-08-29 22:26:40
|
With all the patches flying in to HEAD (thanks!) should we go for a
1.1 release (which would include all the patches) rather than a 1.0.1
(which would just include bug fixes)?
On Aug 29, 2005, at 12:50 PM, Ulf Erikson wrote:
> * Ulf Erikson [2005-08-29 21:42]:
>
>> Could you please look at the attached patch for inclusion in the
>> 1.0 branch?
>>
>
> Almost forgot.. when updating the various schemas I also found two
> faults in the old Oracle support.
>
> 1) There are two syntax errors in inc/db/oci8.php
> 2) There is no EditAssignment permission in schemas/oci8.in
>
> /Ulf
> Index: schemas/oci8.in
> ===================================================================
> RCS file: /cvsroot/phpbt/phpbt/schemas/oci8.in,v
> retrieving revision 1.28
> diff -u -w -r1.28 oci8.in
> --- schemas/oci8.in 20 Jun 2005 01:05:29 -0000 1.28
> +++ schemas/oci8.in 29 Aug 2005 19:49:27 -0000
> @@ -297,6 +297,7 @@
> -- ... and only two permissions
> INSERT INTO TBL_AUTH_PERM (perm_id, perm_name) VALUES (1, 'Admin');
> INSERT INTO TBL_AUTH_PERM (perm_id, perm_name) VALUES (2, 'Editbug');
> +INSERT INTO TBL_AUTH_PERM (perm_id, perm_name) VALUES (3,
> 'EditAssignment');
>
> -- Admins can do all the admin stuff and users can edit bugs
> INSERT INTO TBL_GROUP_PERM (group_id, perm_id) VALUES (1, 1);
> Index: inc/db/oci8.php
> ===================================================================
> RCS file: /cvsroot/phpbt/phpbt/inc/db/oci8.php,v
> retrieving revision 1.18
> diff -u -w -r1.18 oci8.php
> --- inc/db/oci8.php 30 May 2005 19:59:35 -0000 1.18
> +++ inc/db/oci8.php 29 Aug 2005 19:49:27 -0000
> @@ -115,11 +115,11 @@
> 'where p.project_id = pg.project_id(+) and active = 1 '.
> 'and (pg.project_id is null or pg.group_id in (%s)) '.
> 'group by p.project_id, p.project_name order by
> project_name',
> - 'include-template-owner' => SELECT sum(decode( s.status_id in
> (".OPEN_BUG_STATUSES.") , 1, 1, 0 )), ".
> + 'include-template-owner' => "SELECT sum(decode( s.status_id in
> (".OPEN_BUG_STATUSES.") , 1, 1, 0 )), ".
> "sum(decode( s.status_id not in (".OPEN_BUG_STATUSES.") ,
> 1, 1, 0 )), ".
> 'from '.TBL_BUG.' b, '.TBL_STATUS.' s '.
> 'where b.status_id = s.status_id (+) and b.assigned_to = %
> s',
> - 'include-template-reporter' => SELECT sum(decode( s.status_id
> in (".OPEN_BUG_STATUSES.") , 1, 1, 0 )) , ".
> + 'include-template-reporter' => "SELECT sum(decode( s.status_id
> in (".OPEN_BUG_STATUSES.") , 1, 1, 0 )) , ".
> "sum(decode( s.status_id not in (".OPEN_BUG_STATUSES.") ,
> 1, 1, 0 )) ".
> 'from '.TBL_BUG.' b, ' . TBL_STATUS.' s '.
> 'where b.status_id = s.status_id (+) and b.created_by = %s',
>
|
|
From: Ulf E. <ulf...@fa...> - 2005-08-30 07:25:56
|
> With all the patches flying in to HEAD (thanks!) should we go for a > 1.1 release (which would include all the patches) rather than a 1.0.1 > (which would just include bug fixes)? I would vote for the 1.0.1 update. You spent over a year to make sure that the 1.0 release was stable. There have hardly been any complaints on the release. Breaking that by adding half-tested features doesn't sound wise. What do you think of announcing the update/release a bit wider next time? :) Why not asking at the localization mailing list and the web forum for help with some more translations? Maybe ask earlier translators directly whether they wish to help again. I have also thought of "converting" translations from the old translation template to the new one and include such as stubs. How does that sound? I will try to come up with a TODO list for how I would like to bring phpBT-devel into v1.1. Hope we can discuss it then: add or remove some points, move them around and plan where to have releases of development snapshots. -- Ulf |
|
From: Ulf E. <ulf...@fa...> - 2005-09-08 14:38:07
|
[Cross-posting to both phpbt-dev and phpbt-users in order to reach you all] Ulf Erikson [2005-08-30 09:25 +0200]: > > With all the patches flying in to HEAD (thanks!) should we go for a > > 1.1 release (which would include all the patches) rather than a 1.0.1 > > (which would just include bug fixes)? > > I would vote for the 1.0.1 update. You spent over a year to make sure > that the 1.0 release was stable. There have hardly been any complaints > on the release. Breaking that by adding half-tested features doesn't > sound wise. Doesn't anyone else have some thoughts on this? * Should we fix bugs in the 1.0 release and offer regular updates, or should we spend all energy on developing a new version? * 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? * Is the current development version safe and stable (and feature rich and bug free) enough for a new release? * What new features would you expect in a new release? * What old bugs would you expect to be fixed in a new release? If you have *any* interest in either bug-fix updates, development snapshots, or a new release Please let me know. I'm slowly starting to feel that I am talking to myself here... ;-( -- Ulf |
|
From: miah <mi...@ch...> - 2005-09-08 14:49:26
|
Hi Long time User, Long time Lurker. 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. Thanks -miah On Thu, Sep 08, 2005 at 04:37:58PM +0200, Ulf Erikson wrote: > [Cross-posting to both phpbt-dev and phpbt-users in order to reach you > all] > > Ulf Erikson [2005-08-30 09:25 +0200]: > > > With all the patches flying in to HEAD (thanks!) should we go for a > > > 1.1 release (which would include all the patches) rather than a 1.0.1 > > > (which would just include bug fixes)? > > > > I would vote for the 1.0.1 update. You spent over a year to make sure > > that the 1.0 release was stable. There have hardly been any complaints > > on the release. Breaking that by adding half-tested features doesn't > > sound wise. > > Doesn't anyone else have some thoughts on this? > > * Should we fix bugs in the 1.0 release and offer regular updates, or > should we spend all energy on developing a new version? > * 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? > * Is the current development version safe and stable (and feature rich > and bug free) enough for a new release? > * What new features would you expect in a new release? > * What old bugs would you expect to be fixed in a new release? > > If you have *any* interest in either bug-fix updates, development > snapshots, or a new release Please let me know. I'm slowly starting to > feel that I am talking to myself here... ;-( > > -- > Ulf > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Phpbt-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpbt-users |
|
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: 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-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: 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...@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-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-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: 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 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-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: Ulf E. <ulf...@fa...> - 2005-09-23 13:21:47
|
* Benjamin Curtis [2005-09-23, 04:42 -0700]: > Actually, I meant the changes to the Italian translation and the bug > history fix. I can look at the others, too, though. :) Hmm.. The bug history fix will probably not work. It requires the TBL_PRIORITY patch. BTW. I never changed the name of the priority field in TBL_BUG when I moved the priorities into a table. Should it be named 'priority_id' instead of 'priority' now? I skipped it because it would require a more involved update script, but I now think that that would make history work without this bug history fix.. What do you think? /Ulf |
|
From: Ulf E. <ulf...@fa...> - 2005-09-28 19:53:09
|
Hoi, > Actually, I meant the changes to the Italian translation and the bug > history fix. I can look at the others, too, though. :) There is also a Portuguese language update in the patches section now: http://sourceforge.net/tracker/index.php?func=detail&aid=1304084&group_id=14939&atid=314939 I had to correct a few syntax errors.. so you might want to reuse the one from HEAD instead of the submitted patch. And.. I've got even more work for you ;) >> * 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 While going through my old commits in order to update the ChangeLog I found one more patch that might be interesting: * Permission fixes for project admins http://sourceforge.net/mailarchive/forum.php?thread_id=8106482&forum_id=4570 http://sourceforge.net/mailarchive/forum.php?thread_id=8106481&forum_id=4570 Will you please review this one too before 1.0.2? /Ulf |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X