From: Victor B. <vb...@gm...> - 2009-05-21 08:27:59
|
Hi all, In the last couple of days I did some triaging of the issues that are targeted for 1.2.x in an attempt to know the issues that would block branching and stabilization (i.e. an RC). If you are aware of something that needs to be done before then, please raise here and target the issue to 1.2.x in the bug tracker. There will always be something coming soon, so the goal here is to really identify blocking issues that we are actively working on and sort of have a check-in ETA for. If something comes in later that we think should be added to the RC, we can use git to update the branch the same way we do now for 1.1.x. As per our process, creating the RC will hopefully relief us sooner from supporting 1.1.x. Regards, Victor. |
From: Gianluca S. <gi...@gm...> - 2009-05-22 07:03:03
|
On Thu, May 21, 2009 at 10:27 AM, Victor Boctor <vb...@gm...> wrote: > Hi all, > > In the last couple of days I did some triaging of the issues that are > targeted for 1.2.x in an attempt to know the issues that would block > branching and stabilization (i.e. an RC). If you are aware of > something that needs to be done before then, please raise here and > target the issue to 1.2.x in the bug tracker. Right now, I'm not aware of any blocker bugs for 1.2 (despite I'm not looking so closely to the tracker these days); instead I've got reports it's working better than 1.1 for many people on MSSQL and pgsql. The only feature I'm working on which is (IMHO) in a good state for inclusion is voting, AKA bug 668, but I'd surely not block a 1.2 release because of it... Thank for looking into this G. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Victor B. <vb...@gm...> - 2009-05-29 02:56:23
|
Ping for the other devs. On Fri, May 22, 2009 at 12:02 AM, Gianluca Sforna <gi...@gm...> wrote: > On Thu, May 21, 2009 at 10:27 AM, Victor Boctor <vb...@gm...> wrote: >> Hi all, >> >> In the last couple of days I did some triaging of the issues that are >> targeted for 1.2.x in an attempt to know the issues that would block >> branching and stabilization (i.e. an RC). If you are aware of >> something that needs to be done before then, please raise here and >> target the issue to 1.2.x in the bug tracker. > > Right now, I'm not aware of any blocker bugs for 1.2 (despite I'm not > looking so closely to the tracker these days); instead I've got > reports it's working better than 1.1 for many people on MSSQL and > pgsql. > > The only feature I'm working on which is (IMHO) in a good state for > inclusion is voting, AKA bug 668, but I'd surely not block a 1.2 > release because of it... > > Thank for looking into this > > G. > > > > -- > Gianluca Sforna > > http://morefedora.blogspot.com > http://www.linkedin.com/in/gianlucasforna > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: John R. <jr...@le...> - 2009-05-29 13:02:17
|
Victor Boctor wrote: > Ping for the other devs. There are some plugin fixes/tweaks that I'm currently working on and testing, which need to make it in for 1.2 for stability and reliability reasons. Part of this involves caching headers on plugin pages. Also, as useful/good ideas not yet targeted for 1.2.x, I'd like to propose the following "trivial" features to make it in before we release and/or feature freeze the 1.2 tree: - Issue #10217: Optionally show the bug action buttons at the top of the bug view page. This has been requested by my employer, but while the patch defaults to showing buttons at both top and bottom, I think defaulting to the current behavior (bottom only) is preferred. - Issue #10542: Problem with database access; Paul, could you please look into this? - Issue #10226: Simply assigning an issue to a user doesn't generate a notification email. I've noticed this myself recently, and it's rather annoying and I would like it to be fixed for an RC. - Issue #10544: Notification bugnote order does not follow user prefs. Can I get the other devs to approve / reject things from this list? Once I get my changes in for the plugins, and can take core of the above issues, I'll start work on rolling a 1.2 release, branching development, etc. Trust me, I want to see a 1.2 RC release just as much as you. :P Cheers -- John Reese LeetCode.net |
From: Gianluca S. <gi...@gm...> - 2009-05-30 17:41:29
|
On Fri, May 29, 2009 at 3:02 PM, John Reese <jr...@le...> wrote: > > - Issue #10544: Notification bugnote order does not follow user prefs. > I'm not sure how trivial this is, I've briefly looked at the issue previously (this new report is a duplicate) and a "proper" fix wasn't that easy, though I forgot details. anyway, if you feel like fixing this the related/duplicate bugs are 9779, 9630, 5449 -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: John R. <jr...@le...> - 2009-06-02 19:47:34
|
Gianluca Sforna wrote: > On Fri, May 29, 2009 at 3:02 PM, John Reese <jr...@le...> wrote: >> - Issue #10544: Notification bugnote order does not follow user prefs. >> > > I'm not sure how trivial this is, I've briefly looked at the issue > previously (this new report is a duplicate) and a "proper" fix wasn't > that easy, though I forgot details. > > anyway, if you feel like fixing this the related/duplicate bugs are > 9779, 9630, 5449 > > OK, I'm pretty sure I've got a working solution. It required reworking bugnote_api to a) make bugnote_get_all_bugnotes cache all bugnotes for a bug id, without caring about display order or limits, and b) make bugnote_get_visible_bugnotes expect this behavior and handle both the display limit and ordering itself. I think this new behavior makes more sense anyways, since "_get_all_bugnotes" with a limit parameter doesn't make sense, and the way it was caching didn't handle situations where it cached (twice no less) say 5 notes, and then got a request for some other limit. Granted, the new behavior does potentially cache a much larger number of bugnotes for the issue, but it only caches the set once, and it all behaves correctly now. Anyways, I'd appreciate if someone could look at my code and double check it to make sure I'm not going insane. I did some preliminary testing on my on local installation, and it seems to be working correctly, but for something this sensitive, I don't want to just dump it on master without agreement from others. To look at it, you'll need to fetch and checkout from my public repository. From your existing git repository: $ git remote add jreese git://git.mantisforge.org/mantisbt/jreese.git $ git fetch jreese $ git checkout jreese/email-bugnotes Cheers -- John Reese LeetCode.net |
From: Gianluca S. <gi...@gm...> - 2009-06-03 22:28:59
|
On Tue, Jun 2, 2009 at 9:47 PM, John Reese <jr...@le...> wrote: > > Anyways, I'd appreciate if someone could look at my code and double > check it to make sure I'm not going insane. I did some preliminary > testing on my on local installation, and it seems to be working > correctly, but for something this sensitive, I don't want to just dump > it on master without agreement from others. > Ok, I had a look at the patch and it looks sane. Some local tests succeeded, but (as usual) caching is evil on memory consumption and I fail to run the code on larger issues (like #4286) Longer term, I think we need to plan a different approach to data retrieval Thanks for looking into this G. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Victor B. <vb...@gm...> - 2009-06-03 22:59:15
|
I think the following issue is worth considering for 1.2.0rc1. 10558: Wrong sorting on changelog/roadmap http://www.mantisbt.org/bugs/view.php?id=10558 Did we change the sorting order or is this a bug? Regards, Victor. |
From: John R. <jr...@le...> - 2009-06-04 15:09:54
|
Victor Boctor wrote: > I think the following issue is worth considering for 1.2.0rc1. > > 10558: Wrong sorting on changelog/roadmap > http://www.mantisbt.org/bugs/view.php?id=10558 > > Did we change the sorting order or is this a bug? > > Regards, > Victor. I pulled a local copy of the live database (minus all user information), and ran `git-bisect` between 1.2.0a2 and the current live revision, using the roadmap page as my method of verification. After drilling down, Git reported: 0ac196a4639d01c627aa6b2886a84f5ee9eeb4b4 is first bad commit commit 0ac196a4639d01c627aa6b2886a84f5ee9eeb4b4 Author: Paul Richards <pa...@ma...> Date: Sun Apr 5 16:54:24 2009 +0100 Sync my working checkout of misc performance changes/mssql fixes: 1) add some caching around version/categories/projects to speed up projects with a large number of categories/versions etc 2) database_api: improve db_fetch_array when running under pgsql 3) tag_api: fix for mssql+mysql by implementing different query logic :( 4) manage_proj_page: add improvement noted in bug #8850 :100644 100644 becfa198e7178ccfba4542d1f4b08c03e25b00f5 cfd53781de6aef0d15afab4b1b7044236142a191 M changelog_page.php :040000 040000 3ec3f5e1dcf43a5ec62086f9e91c22f07127e7a7 b4e12e9519887f2ac4435fbb423a100d52f056c0 M core :100644 100644 343c03fd25f91dd02f1b6ac0cec7cf1de8c6232b 07f7700a47a5e2bf15477d75d701657dfcb22fdb M manage_proj_page.php :100644 100644 0b7b2e1ca9f585e73a5a258e5ca5d2ad1a219f78 0d23e47ae43425d83f3aada9eb6b6051210d17f1 M roadmap_page.php :100644 100644 0ac65217e98095bd58a7f123096212e0a441469c 7dbd490f141f204f6cb71a459b040a65fde52cb7 M summary_page.php The problem was that the data caching introduced in this commit did not utilize an "order by" clause like the standard query, which roadmap_page and changelog_page both rely on for sorting versions by date. This resulted in both pages containing an arbitrary sorting order. I've committed the fix to Git master. I'm also considering pushing a branch to the official repo named "live" which represents the current live installation's history. I think it would be useful to use this branch to cherry-pick changes for the live install, until the issues with the date changes are resolved. Cheers -- John Reese LeetCode.net |
From: Paul R. <pa...@ma...> - 2009-05-30 13:28:14
|
I like the way we vary between top+bottom posting :) One thing we need to look at/document is steps to convert db to utf8. At the moment, we have checks to show tables/columns in mysql that aren't converted to utf8 but haven't documented the process to convert them - I'm personally trying to work out whether it's just a case of doing ALTER TABLE -> charset(utf8), or whether we need to look at individual data / dump/restore. The information on the internet i've read personally seems to be a bit contradictory on this. Paul ----- "Victor Boctor" <vb...@gm...> wrote: > Ping for the other devs. > > On Fri, May 22, 2009 at 12:02 AM, Gianluca Sforna <gi...@gm...> > wrote: > > On Thu, May 21, 2009 at 10:27 AM, Victor Boctor <vb...@gm...> > wrote: > >> Hi all, > >> > >> In the last couple of days I did some triaging of the issues that > are > >> targeted for 1.2.x in an attempt to know the issues that would > block > >> branching and stabilization (i.e. an RC). If you are aware of > >> something that needs to be done before then, please raise here and > >> target the issue to 1.2.x in the bug tracker. > > > > Right now, I'm not aware of any blocker bugs for 1.2 (despite I'm > not > > looking so closely to the tracker these days); instead I've got > > reports it's working better than 1.1 for many people on MSSQL and > > pgsql. > > > > The only feature I'm working on which is (IMHO) in a good state for > > inclusion is voting, AKA bug 668, but I'd surely not block a 1.2 > > release because of it... > > > > Thank for looking into this > > > > G. > > > > > > |
From: Gianluca S. <gi...@gm...> - 2009-05-30 17:14:01
|
On Sat, May 30, 2009 at 3:27 PM, Paul Richards <pa...@ma...> wrote: > I like the way we vary between top+bottom posting :) If you like it better, I can start pestering who don't properly quote... > > One thing we need to look at/document is steps to convert db to utf8. At the moment, we have checks to show tables/columns in mysql that aren't converted to utf8 but haven't documented the process to convert them - I'm personally trying to work out whether it's just a case of doing ALTER TABLE -> charset(utf8), or whether we need to look at individual data / dump/restore. I consider this hardly a blocker. 1.1 is already on utf8, so we eventually needed this stuff more than two years ago... However, talking about upgrades, I noticed the timestamp updates takes a fairly large amount of time with the mantisbt DB. Can we do something to give the user some feedback on the upgrade operation so it does not seem stuck? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: John R. <jr...@le...> - 2009-06-04 15:45:56
|
Gianluca Sforna wrote: > Ok, I had a look at the patch and it looks sane. Some local tests > succeeded, but (as usual) caching is evil on memory consumption and I > fail to run the code on larger issues (like #4286) I think that's a combined problem of caching a lot of data, plus the fact that we're building emails that contain the entire issue history in them. This is a rather naive (insane?) way to build an email, and I think we could make drastic improvements just by cutting way down on how much data we put into these messages. They're extremely overwhelming for a lot of people both outside and inside of our engineering department, and most of that data is quite frankly unnecessary. > Longer term, I think we need to plan a different approach to data retrieval +1 > Thanks for looking into this No problem; I'm glad it was easier than you were expecting. :) -- John Reese LeetCode.net |
From: Victor B. <vb...@gm...> - 2009-06-04 15:56:09
|
On Thu, Jun 4, 2009 at 8:45 AM, John Reese <jr...@le...> wrote: > Gianluca Sforna wrote: >> Ok, I had a look at the patch and it looks sane. Some local tests >> succeeded, but (as usual) caching is evil on memory consumption and I >> fail to run the code on larger issues (like #4286) > > I think that's a combined problem of caching a lot of data, plus the > fact that we're building emails that contain the entire issue history in > them. This is a rather naive (insane?) way to build an email, and I > think we could make drastic improvements just by cutting way down on how > much data we put into these messages. They're extremely overwhelming > for a lot of people both outside and inside of our engineering > department, and most of that data is quite frankly unnecessary. I'm thinking that we should move towards a model where email notifications only has the change. For example, if the issue is updated, then only include issue information, if a note is added, then only add the issue basic info and the new note, etc. I find a couple of interesting outcomes from this: 1. Less work to prepare such emails. 2. Easier for readers to find / read the change. 3. Easier to read on mobile phones, rather than having to keep scrolling down a very long email. This would be a good compromise between including the full information and only including a notification that something has changed. Regards, Victor |
From: Manilal K M <ma...@ej...> - 2009-06-05 11:24:16
|
Quoting Victor Boctor <vb...@gm...>: > On Thu, Jun 4, 2009 at 8:45 AM, John Reese <jr...@le...> wrote: >> Gianluca Sforna wrote: >>> Ok, I had a look at the patch and it looks sane. Some local tests >>> succeeded, but (as usual) caching is evil on memory consumption and I >>> fail to run the code on larger issues (like #4286) >> >> I think that's a combined problem of caching a lot of data, plus the >> fact that we're building emails that contain the entire issue history in >> them. This is a rather naive (insane?) way to build an email, and I >> think we could make drastic improvements just by cutting way down on how >> much data we put into these messages. They're extremely overwhelming >> for a lot of people both outside and inside of our engineering >> department, and most of that data is quite frankly unnecessary. > > I'm thinking that we should move towards a model where email > notifications only has the change. For example, if the issue is > updated, then only include issue information, if a note is added, then > only add the issue basic info and the new note, etc. I find a couple > of interesting outcomes from this: > > 1. Less work to prepare such emails. > 2. Easier for readers to find / read the change. > 3. Easier to read on mobile phones, rather than having to keep > scrolling down a very long email. > > This would be a good compromise between including the full information > and only including a notification that something has changed. > The long emails are really confusing for a non technical user. I would really like to see it in action. -- Manilal K M eJyothi Services http://www.ejyothi.com |
From: John R. <jr...@le...> - 2009-06-04 19:17:25
|
John Reese wrote: > - Issue #10217: Optionally show the bug action buttons at the top of the > bug view page. This has been requested by my employer, but while the > patch defaults to showing buttons at both top and bottom, I think > defaulting to the current behavior (bottom only) is preferred. Can I get devs to commit one or another to support or reject this feature? My employer wants it, but I'd like an official decision on whether it can make it in for 1.2? Cheers -- John Reese LeetCode.net |
From: Victor B. <vb...@gm...> - 2009-06-04 20:31:27
|
On Thu, Jun 4, 2009 at 12:17 PM, John Reese <jr...@le...> wrote: > John Reese wrote: >> - Issue #10217: Optionally show the bug action buttons at the top of the >> bug view page. This has been requested by my employer, but while the >> patch defaults to showing buttons at both top and bottom, I think >> defaulting to the current behavior (bottom only) is preferred. > > Can I get devs to commit one or another to support or reject this > feature? My employer wants it, but I'd like an official decision on > whether it can make it in for 1.2? We have similar behavior for the status legend on the View Issues page. I don't mind adding this as long as: 1. Use a consistent way to configure this (re-use constants or same pattern - depends on the current constant names). 2. Default to current behavior. Regards, Victor. |