Hi Rony, 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. 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. 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. 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. I hope that is clearer Jon 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 list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
