From: Oleg O. <ole...@ol...> - 2009-01-12 22:46:38
|
Hello, I would like to see these bugs fixed in 1.2.0a3: 0009745 Making bugnote private, access check is wrong 0009828 Reopen issue access check is wrong 0009827 (security) 0009831 Wrong status is used for Reopen Status They all have simple fixes, and are annoying when you run into them. Also, I have a question about 1.2.0a3. There are some bugs that are marked as fixed in "git trunk" and "1.2.x". Are they all going to be included in 1.2.0a3, or are they set aside on branches (or whatever it is in git)? Thanks. olegos |
From: Siebrand M. <s.m...@xs...> - 2009-01-12 23:00:38
|
Hi Oleg, I think we have the same goals. I would like to go a bit futher than you though; I would like to see each open issue resolved in the next released. Let's see if we can accomplish this... I checked out the four issues you mentioned. Even though you are the reporter, and state that the issues "all have simple fixes" you have not attached a patch on trunk for any of these issues, which would make it a magnitude easier to get them resolved. I admire your aspirations, and share them, but please realise that everyone working on Mantis is a volunteer. As soon as we start to get funding, priotities may shift - until them it is mostly fun for people to work on, and all open source projects need all the help they can get - yours too. P.s. it is possible to pledge a certain sum of monery for getting issues fixed in our bug tracker. Oh, another thing: As with beauty, simplicity is in the eye of the beholder. Cheers! Siebrand -----Oorspronkelijk bericht----- Van: Oleg O. [mailto:ole...@ol...] Verzonden: maandag 12 januari 2009 22:28 Aan: man...@li... Onderwerp: Re: [mantisbt-dev] Preparing for 1.2.0a3 release Hello, I would like to see these bugs fixed in 1.2.0a3: 0009745 Making bugnote private, access check is wrong 0009828 Reopen issue access check is wrong 0009827 (security) 0009831 Wrong status is used for Reopen Status They all have simple fixes, and are annoying when you run into them. Also, I have a question about 1.2.0a3. There are some bugs that are marked as fixed in "git trunk" and "1.2.x". Are they all going to be included in 1.2.0a3, or are they set aside on branches (or whatever it is in git)? Thanks. olegos |
From: Oleg O. <ole...@ol...> - 2009-01-13 00:23:02
|
Hi Siebrand, It probably wasn't apparent (I can't seem to get threading in this ML right, at least according to the web archives), but I was replying to John Reese's message, particularly this part: > I would also like to ask community members and other developers to > propose any other issues for a3 that either: > > - break or prevent the use of important features > - have a simple fix > - have a posted patch for git master The issues I've listed are 2 out of 3. I define "simple" approximately as involving one or two lines of code where it's generally clear what these lines need to do. (Except #9827 which is not simple according to this criteria, but I think is important and is still not too complicated because it's exactly analogous to another bug that's been fixed.) By the way, I did attach patches to some other bugs; this list is far from all the bugs I've submitted. I haven't been attaching patches where I'm not too sure that my fix should be adopted verbatim. Since I think that it should be reviewed by someone with a better understanding of what's going on, and as these issues are simple, I reasoned that it would be just as easy for such a person to just fix the code... I did fix all these issues in my own installation (again, except #9827, which I took care of in a different way), so if you think my 1-line patches that I'm not very confident about are going to help move things along, I can produce them. olegos Siebrand Mazeland wrote: > I checked out the four issues you mentioned. Even though you are the > reporter, and state that the issues "all have simple fixes" you have not > attached a patch on trunk for any of these issues, which would make it a > magnitude easier to get them resolved. I admire your aspirations, and share > them, but please realise that everyone working on Mantis is a volunteer. As > soon as we start to get funding, priotities may shift - until them it is > mostly fun for people to work on, and all open source projects need all the > help they can get - yours too. P.s. it is possible to pledge a certain sum > of monery for getting issues fixed in our bug tracker. > > Oh, another thing: As with beauty, simplicity is in the eye of the > beholder. |
From: Siebrand M. <s.m...@xs...> - 2009-01-13 07:05:01
|
Hi Olegos, Thank you for clarifying. Correct me if I'm wrong, but you should be able to commit the fixes to the public Mantis GIT repo. More info at http://mantisforge.org/development. For those core developers better acquainted with Git, it should then be really easy to test and push the change(s) to the master repo. Some context from my side: I am not a PHP developer, but I am able to apply and test patches if use cases, observed and expected behaviour are documented properly in issue descriptions. Cheers! Siebrand -----Oorspronkelijk bericht----- Van: Oleg O. [mailto:ole...@ol...] Verzonden: dinsdag 13 januari 2009 1:23 Aan: man...@li... Onderwerp: Re: [mantisbt-dev] Preparing for 1.2.0a3 release Hi Siebrand, It probably wasn't apparent (I can't seem to get threading in this ML right, at least according to the web archives), but I was replying to John Reese's message, particularly this part: > I would also like to ask community members and other developers to > propose any other issues for a3 that either: > > - break or prevent the use of important features > - have a simple fix > - have a posted patch for git master The issues I've listed are 2 out of 3. I define "simple" approximately as involving one or two lines of code where it's generally clear what these lines need to do. (Except #9827 which is not simple according to this criteria, but I think is important and is still not too complicated because it's exactly analogous to another bug that's been fixed.) By the way, I did attach patches to some other bugs; this list is far from all the bugs I've submitted. I haven't been attaching patches where I'm not too sure that my fix should be adopted verbatim. Since I think that it should be reviewed by someone with a better understanding of what's going on, and as these issues are simple, I reasoned that it would be just as easy for such a person to just fix the code... I did fix all these issues in my own installation (again, except #9827, which I took care of in a different way), so if you think my 1-line patches that I'm not very confident about are going to help move things along, I can produce them. olegos Siebrand Mazeland wrote: > I checked out the four issues you mentioned. Even though you are the > reporter, and state that the issues "all have simple fixes" you have not > attached a patch on trunk for any of these issues, which would make it a > magnitude easier to get them resolved. I admire your aspirations, and share > them, but please realise that everyone working on Mantis is a volunteer. As > soon as we start to get funding, priotities may shift - until them it is > mostly fun for people to work on, and all open source projects need all the > help they can get - yours too. P.s. it is possible to pledge a certain sum > of monery for getting issues fixed in our bug tracker. > > Oh, another thing: As with beauty, simplicity is in the eye of the > beholder. ---------------------------------------------------------------------------- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: John R. <jr...@le...> - 2009-01-13 13:42:56
|
On 01/13/2009 02:04 AM, Siebrand Mazeland wrote: > Correct me if I'm wrong, but you should be able to > commit the fixes to the public Mantis GIT repo. More info at > http://mantisforge.org/development. For those core developers better > acquainted with Git, it should then be really easy to test and push the > change(s) to the master repo. Correction: you can commit to your local repository, and either generate a Git patch that you can attach to a bug, or you can push your changes to a private fork hosted on http://git.mantisforge.org - both methods are covered in the manual that Siebrand linked you to. Also, I'd rather have a patch submitted to a bug, even if it's not 100% "correct", as it can usually give me at least a better idea of what the problem code is and how to fix it, and at best, allows me to apply it directly, and with Git, even allows the patch submitter to retain credit for the fix. Cheers -- John Reese LeetCode.net |