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/351/>
* <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
o 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
