Hi Rony, I don't think that I made myself clear in my suggestion. Just for clarity: I was just noting that a full list of committers could be retrieved by opening the drop-down of the Owner field on the tracker items. Anyway, that doesn't matter.
Your suggestion that promotions are approved by a request on the developers list specifying the tracker numbers works for me(+1). If that's ok with P.O. and anyone else who might join in the effort, let's go with that! thanks, Jon On Tue, 28 Oct 2025 at 10:05, Rony G. Flatscher <[email protected]> wrote: > On 27.10.2025 22:18, Sahananda wrote: > > 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. > > The Owner field can be changed by committers. > > How about posting the links to the documentation tracker items that are > "OK to promote" in this developer list? > > This would serve two purposes: > > - it gives an overview and easy access to the referred to > documentation tracker items, > - the mailing header would indicate, who was posting it. > > In addition it would allow others to look up the approved tracker items. > In the cases where a patch is missing, but the tracker item is clearly > formulated, then you, or everybody else would be "empowered" ;) to change > the explanation, the explanation, and to handle the change without asking > anyone. This way we might become able to address over time the > documentation tracker items, which would be especially important for the > users of ooRexx. > > ---rony > > > > 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
