Dear Rony, I'm willing, BUT:
I have applied the patch 325 successfully to my working copy, but when I try to commit docs/trunk I receive the following error. Command: Commit to svn://svn.code.sf.net/p/oorexx/code-0/docs/trunk > Error: Commit failed (details follow): > Error: Authorization failed > Completed!: I am signed in in the usual way, and have committed items from this userid before (though not recently, not from this working copy, not from this laptop, not with this install of Tortoise and not to docs). There is a button for 'Retry as different user' and pressing it I get a credentials dialog in which I enter my sourceforge signon; but then get the same error message. I am an admin on the sourceforge project with update, admin & create permissions I also tried just committing the individual changed files. No luck. I do remember that when I committed in the past I used to get three consecutive Login Dialogs from Tortoise, but now it does not even ask for my credentials when doing a commit. In case Tortoise had cached a bad password for me, I deleted the only file in %APPDATA%\Subversion\auth\svn.username, but that made no difference. Sorry to continue this already long thread, but I don't know where to take this now. Jon On Sat, 1 Nov 2025 at 17:05, Rony G. Flatscher <[email protected]> wrote: > Dear Jon, dear P.O., > > trying to follow the agreed-upon procedure. > > Here are three of Jospe Maria's doc patches that I looked at and which > look o.k.: > > - <https://sourceforge.net/p/oorexx/documentation/325/> > <https://sourceforge.net/p/oorexx/documentation/325/> > - <https://sourceforge.net/p/oorexx/documentation/351/> > <https://sourceforge.net/p/oorexx/documentation/351/> > - <https://sourceforge.net/p/oorexx/documentation/352/> > <https://sourceforge.net/p/oorexx/documentation/352/> > > Could you please be so kind as to process them? Thank you in advance for > your help! > > --- > > Just a general remark about Josep Maria's patches: he has an incredible > commandment of the ooRexx syntax acquired as can be seen by looking at his > Unicode-TUTOR ooRexx tool (https://github.com/JosepMariaBlasco/TUTOR) and > his rexx-parser (https://github.com/JosepMariaBlasco/rexx-parser) > project. Therefore, I would expect that all doc patches are correct. If any > of the committers would object to Josep Maria's doc bug reports, then they > probably would have done so. Personally, I have yet to see a > documentation-related bug report from him that is incorrect. > > Therefore, I think you can apply Josep Maria's documentation patches > without waiting for a committer to o.k. them. > > Also you could mostlikely resolve most of Josep Maria's documentation > related bug reports without his patches, as you are very knowledgeable > ooRexx programmers yourselves and therefore are able to assess the bug > reports! (Even if you do not think so! :) ) > > Best regards > > ---rony > > > On 29.10.2025 12:36, Sahananda wrote: > > 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
