Hi Rony, P.O. I think that if rather than +1 if you (or another committer) added a comment '*OK to promote*' that would be clearer. We would know they were a committer because their sign-on would appear in the Owner drop down on the ticket.
Jon On Mon, 27 Oct 2025 at 19:50, Rony G. Flatscher <[email protected]> wrote: > Hi Jon, > On 27.10.2025 16:42, Sahananda wrote: > > I have read this, and I don't think that I can answer it quickly. It is > more about project management and who makes the decision what goes into the > language than anything technical. > > Where it is just a case of Josep Maria correcting mistakes in and > improving the documentation (many thanks) I can make the judgement on > readability, but I can't really say anything about technical correctness as > most of these changes are in areas I'm unfamiliar with or I would need to > spend time getting to know the context. > > As it is, I did not build the documentation with Josep Maria's patches, > just judged the readability on the basis of the source xml. > > Would it help, if someone would post a +1 with the tracker item then? > > Were it native code, I would not be capable of 'judging' the merit or > otherwise of a change to a C++ segment. > > When you requested someone to promote those 4 patches, I was happy to do > it on the basis that I was just saving you some time with the mechanics of > applying the patches which I assumed you had already judged the merits of. > Later it became clear that P.O. could do it if I parsed the English. > > In principle, and time permitting, I am happy to take on the mechanics of > applying patches if that frees resource from those like yourself capable of > developing the code, but I do not want, without discussion, to create a > precedent that leads to an unguarded way into the source code. > > Thank you for this attitude, I really mean it! > > OTOH, there are quite a few tracker items where I think that you or P.O. > would be able to confidently handle them on your own. You are both very > knowledgeable ooRexx "users" for many, many years with a lot of experience! > > It would be of great help, if the tracker items could be reduced as much > as possible, either by applying patches, assess the reasoning and if you > have an educated disagreement, then do not accept, otherwise if you have an > educated agreement, then please agree (and maybe apply, fix), and if > undecided, post a follow-up hinting at the need to have an additional > assessment. (This would be really very helpful!) > > If it was left to me, I have sufficient regard for Josep Maria, and > knowing that he is active on the developers list and the ARB that I would > invite him to become a committer. > > +1 > > > I'm not asking that you (Rony) in particular solve this, and I do not have > a particular proposal for how to solve it. I just wanted to flag up my > concern. > > Thank you very much, Jon! > > I hope that is clearer > > Very much so! > > Best regards > > ---rony > > > On Sat, 25 Oct 2025 at 21:52, Rony G Flatscher <[email protected]> > wrote: > >> Hi Jon and P.O., >> >> would it maybe possible that you come up with a brief draft, suggestion? >> This way it wiuld probabky gelp the most and allow eg. Myself to better >> unddrstand the problem and possible solutions. >> >> Cheers >> >> —-rony >> Rony G. Flatscher (mobil/e) >> >> Am 25.10.2025 um 20:38 schrieb P.O. Jonsson <[email protected]>: >> >> Dear Rony, >> >> It is not just about the mechanics of applying a patch. What I think Jon >> is hinting at are guidelines for who and under what conditions parched are >> accepted. >> IMO it should really be up to the core developers if a patch should be >> allowed or not. If it is just about linguistic problems Jon may be in a >> position to help out (whereas I would prefer not to since I am not a native >> speaker). >> >> So some guidelines would be welcome indeed. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> [email protected] >> >> >> >> >> Am 25.10.2025 um 15:53 schrieb Rony G. Flatscher <[email protected] >> >: >> >> On 25.10.2025 15:24, Sahananda wrote: >> >> I have been thinking about this. If I apply a patch I am actually >> reviewing the providers work. >> >> We should really have some guidelines about this. >> >> Just because I was given committer status a decade ago, doesn't mean that >> I have an overview of all the changes that are going on nor that I can >> necessarily be the arbiter of whether a patch should be committed or not >> nor whether it would need falling back. >> >> I feel it would be helpful to me to have clearly stated procedures for >> accepting/rejecting/committing patches. >> >> How about this for creating patches: >> >> - a patch should be created in the "trunk" directory >> >> How about this for applying patches: >> >> - a patch must be applicable from the "trunk" directory >> >> - before applying a patch the command "svn update" should issued to >> get the latest version from Sourceforge >> >> - then the patch should be applied locally with "svn patch >> name-of-diff/patchfile" from the "trunk" directory >> >> - if there are problems, because there are overlapping changes with >> commits that occurred after the creation of the diff/patch file, then >> this >> should be communicated in the respective tracker entry; >> >> - the creator of the diff/patch can then do an "svn update" and >> see where his changes overlap with the newer text and can resolve >> them and >> then create an updated diff/patch file with "svn diff" and submit it >> >> - it may be the case that the problems are not complicated and >> can be resolved on the side of the applyer of the diff/patch file by >> inspecting the mark-up that "svn" applies >> >> Here are two links that explain much better how svn conflicts can be >> resolved: >> >> - Tortoise (Windows): >> >> <https://www.tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html> >> >> <https://www.tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html> >> - Command line (shown for Unix, but the command line is the same on >> Windows): >> <https://www.tutorialspoint.com/svn/svn_resolve_conflicts.htm> >> <https://www.tutorialspoint.com/svn/svn_resolve_conflicts.htm> >> >> There may be better explanations, tutorials on the net. >> >> Hope that helps >> >> ---rony >> >> >> On Sat, 25 Oct 2025 at 13:38, Rony G. Flatscher <[email protected]> >> wrote: >> >>> One important hint about applying patches. It may be the case that in >>> the meantime someone else committed changes. In order to make sure that >>> everything is alright, one should always do a "svn update" before a "svn >>> commit". This way one can see before the commit, whether there are areas >>> which got concurrently changed, in which case this needs to be resolved. >>> However, usually changes occur in different parts of the code, the >>> documentation and the tests which svn should be able to handle (it is able >>> to realize which version was used for the patch and infer any changes in >>> between and can usually apply patches in full if they do not overlap). >>> >>> ---rony >>> >>> >>> >>> On 24.10.2025 17:40, Sahananda wrote: >>> >>> Hi All, >>> >>> I think I am now in a position to apply patches. >>> >>> I reinstalled Tortoise, and now I see a child dialog of the diff dialog >>> that I didn't notice before allowing me to choose which patch to action (it >>> was a Hobsons Choice). The dialog was off my screen apart from a tiny >>> sliver, but once I managed to grab it and drag it onto the screen I could >>> choose the patch and then the diff was populated. >>> >>> As P.O. had already applied the changes (thank you) and I had updated to >>> the post change level while rebuilding my working copy to mirror Josep >>> Maria's there was now no change left to apply, but I am confident that it >>> would work in future. >>> >>> As Rony says, the patch to be actioned should be placed in the folder >>> above what is indicated in the Index: clause within the patch file. In >>> this case, the 'docs' folder. >>> >>> Jon >>> >>> >>> >>> On Fri, 24 Oct 2025 at 16:14, Rony G. Flatscher <[email protected]> >>> wrote: >>> >>>> First of all, thank you all *very* much for taking on the patches and >>>> also all of your work in the documentation/patch area! >>>> >>>> Sorry to read that you had so many problems with it, maybe a few words, >>>> hints: >>>> >>>> - The path given at the beginning of the diff/patch files tells one >>>> in which directory the creator of the diff/patch was located; so if it >>>> starts with "trunk/rexxref/en-US/....xml", it must have been the "docs" >>>> directory, so Josep Maria had that from the Sourceforge project checked >>>> out, but P.O. and Jon did probably check out the doc's "trunk" directory >>>> (and all its subdirectories), but not the directory "docs" in which >>>> "trunk" >>>> and the "releases" are located. Therefore applying the patch did not >>>> work. >>>> >>>> - Maybe to ease handling, please create the diff/patches from >>>> within the "trunk" directory (underneath a possibly existing "docs" >>>> directory), then the diff/patch should start with >>>> "rexxref/en-US/....xml" >>>> instead and one can apply them from "trunk" then. >>>> >>>> - Ad forward slashes: these should work on the Windows version of >>>> svn as well. >>>> >>>> Please keep up your great work! >>>> >>>> ---rony >>>> >>>> >>>> On 24.10.2025 12:41, Josep Maria Blasco wrote: >>>> >>>> The revision number shouldn't matter, as far as I know. >>>> It was the current one when I uploaded the patches. >>>> >>>> Regarding the paths, the instruction set I'm following reads >>>> >>>> Once you are ready with the intended changes, >>>> *go up to the root of the documentation* and issue "svn diff > >>>> myPatchForChapter3.1.2.diff" >>>> which will write all the changes to that text file. Submit that >>>> diff-file (patch-file) as a patch[...] >>>> >>>> Maybe the boldfaced part explains the difference? >>>> >>>> Josep Maria >>>> >>>> Missatge de Sahananda <[email protected]> del dia dv., 24 d’oct. >>>> 2025 a les 10:47: >>>> >>>>> I would also be interested in an answer to this. I tried creating a >>>>> patch locally and noted these differences from Josep Maria's patch. >>>>> >>>>> The file references did not have paths. >>>>> My Working copy was at revision 13031 whilst Josep Maria's was at 13026 >>>>> I also note that Josep Maria's patch which contained directory >>>>> information used '/' as the path separator. >>>>> >>>>> Jon >>>>> >>>>> >>>>> >>>>> My Header >>>>> >>>>>> Index: intro.xml >>>>>> =================================================================== >>>>>> --- intro.xml (revision 13031) >>>>>> +++ intro.xml (working copy) >>>>> >>>>> >>>>> Josep Maria's Header >>>>> >>>>>> Index: trunk/rexxref/en-US/intro.xml >>>>>> =================================================================== >>>>>> --- trunk/rexxref/en-US/intro.xml (revision 13026) >>>>>> +++ trunk/rexxref/en-US/intro.xml (working copy) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, 24 Oct 2025 at 08:15, ooRexx <[email protected]> wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> I wanted to apply the patches proposed by Josep Maria but failed >>>>>> miserably to do so. I have now applied the changes indicated in >>>>>> doc_bug_326.diff manually and that worked so there is nothing wrong with >>>>>> my >>>>>> SVN. I nevertheless would like to know why the patch did not work. Here >>>>>> is >>>>>> what I did: >>>>>> >>>>>> % cd /Users/jenkins/ooRexxSVN-Code-0/docs/trunk/rexxref/en-US >>>>>> % svn update >>>>>> Aktualisiere ».«: >>>>>> Revision 13031. >>>>>> % svn patch /Users/jenkins/Downloads/doc_bug_326.diff >>>>>> C trunk/rexxref/en-US/instrc.xml >>>>>> > Abschnitt @@ -2081,9 +2081,8 @@ zurückgewiesen >>>>>> Konfliktübersicht: >>>>>> Textkonflikte: 1 >>>>>> >>>>>> What am I doing wrong? >>>>>> Is the patch not in the correct form? >>>>>> Or do I have to perform the patches in a specific order? >>>>>> I am on r13031 and the patch was made at r13026, does that make a >>>>>> difference? >>>>>> >>>>>> Here the rejection grounds >>>>>> >>>>>> --- trunk/rexxref/en-US/instrc.xml >>>>>> +++ trunk/rexxref/en-US/instrc.xml >>>>>> @@ -2081,9 +2081,8 @@ >>>>>> in this case must be either >>>>>> <computeroutput>SCIENTIFIC</computeroutput> or >>>>>> <computeroutput>ENGINEERING</computeroutput>. You can omit the >>>>>> subkeyword >>>>>> VALUE if <emphasis role="italic">expression2</emphasis> does not >>>>>> begin with a >>>>>> -symbol or a literal string, >>>>>> -that is, if it starts with a special character, such as an operator >>>>>> character >>>>>> -or parenthesis.</para> >>>>>> +symbol, that is, if it starts with a string or a special character, >>>>>> +such as an operator character or parenthesis.</para> >>>>>> <para>You can retrieve the current NUMERIC FORM setting with the >>>>>> <xref linkend="bifForm" xrefstyle="select:title"/> built-in function. >>>>>> </para> >>>>>> >>>>>> >>>>>> Hälsningar/Regards/Grüsse, >>>>>> ooRexx >>>>>> [email protected] >>>>>> >>>>>> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > > _______________________________________________ > Oorexx-devel mailing > [email protected]https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > -- > -- > __________________________________________________________________________________ > > Prof. Dr. Rony G. Flatscher, iR > Department Wirtschaftsinformatik und Operations Management > WU Wien > Welthandelsplatz 1 > A-1020 Wien/Vienna, Austria/Europe > http://www.wu.ac.at > __________________________________________________________________________________ > > > > > > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
