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
