8 files changed, 389 insertions, 0 deletions
diff --git a/dev/patchbot/prompts/prompt14-2.9-airo14-pfx.txt b/dev/patchbot/prompts/prompt14-2.9-airo14-pfx.txt
new file mode 100644
index 0000000..2f3fde2
--- /dev/null
+++ b/dev/patchbot/prompts/prompt14-2.9-airo14-pfx.txt
@@ -0,0 +1,70 @@
+BEGININPUT
+BEGINCONTEXT
+
+HAProxy's development cycle consists in one development branch, and multiple
+maintenance branches.
+
+All the development is made into the development branch exclusively. This
+includes mostly new features, doc updates, cleanups and or course, fixes.
+
+The maintenance branches, also called stable branches, never see any
+development, and only receive ultra-safe fixes for bugs that affect them,
+that are picked from the development branch.
+
+Branches are numbered in 0.1 increments. Every 6 months, upon a new major
+release, the development branch enters maintenance and a new development branch
+is created with a new, higher version. The current development branch is
+2.9-dev, and maintenance branches are 2.8 and below.
+
+Fixes created in the development branch for issues that were introduced in an
+earlier branch are applied in descending order to each and every version till
+that branch that introduced the issue: 2.8 first, then 2.7, then 2.6 and so
+on. This operation is called "backporting". A fix for an issue is never
+backported beyond the branch that introduced the issue. An important point is
+that the project maintainers really aim at zero regression in maintenance
+branches, so they're never willing to take any risk backporting patches that
+are not deemed strictly necessary.
+
+Fixes consist of patches managed using the Git version control tool and are
+identified by a Git commit ID and a commit message. For this reason we
+indistinctly talk about backporting fixes, commits, or patches; all mean the
+same thing. When mentioning commit IDs, developers always use a short form
+made of the first 8 characters only, and expect the AI assistant to do the
+same.
+
+It seldom happens that some fixes depend on changes that were brought by other
+patches that were not in some branches and that will need to be backported as
+well for the fix to work. In this case, such information is explicitly provided
+in the commit message by the patch's author in natural language.
+
+Developers are serious and always indicate if a patch needs to be backported.
+Sometimes they omit the exact target branch, or they will say that the patch is
+"needed" in some older branch, but it means the same. If a commit message
+doesn't mention any backport instructions, it means that the commit does not
+have to be backported. And patches that are not strictly bug fixes nor doc
+improvements are normally not backported. For example, fixes for design
+limitations, architectural improvements and performance optimizations are
+considered too risky for a backport. Finally, all bug fixes are tagged as
+"BUG" at the beginning of their subject line. Patches that are not tagged as
+such are not bugs, and must never be backported unless their commit message
+explicitly requests so.
+
+ENDCONTEXT
+
+A developer is reviewing the development branch, trying to spot which commits
+need to be backported to maintenance branches. This person is already expert
+on HAProxy and everything related to Git, patch management, and the risks
+associated with backports, so he doesn't want to be told how to proceed nor to
+review the contents of the patch.
+
+The goal for this developer is to get some help from the AI assistant to save
+some precious time on this tedious review work. In order to do a better job, he
+needs an accurate summary of the information and instructions found in each
+commit message. Specifically he needs to figure if the patch fixes a problem
+affecting an older branch or not, if it needs to be backported, if so to which
+branches, and if other patches need to be backported along with it.
+
+The indented text block below after an "id" line and starting with a Subject line
+is a commit message from the HAProxy development branch that describes a patch
+applied to that branch, starting with its subject line, please read it carefully.
+
diff --git a/dev/patchbot/prompts/prompt14-2.9-alpaca-pfx.txt b/dev/patchbot/prompts/prompt14-2.9-alpaca-pfx.txt
new file mode 100644
index 0000000..cabe7f0
--- /dev/null
+++ b/dev/patchbot/prompts/prompt14-2.9-alpaca-pfx.txt
@@ -0,0 +1,68 @@
+### Instruction:
+
+HAProxy's development cycle consists in one development branch, and multiple
+maintenance branches.
+
+All the development is made into the development branch exclusively. This
+includes mostly new features, doc updates, cleanups and or course, fixes.
+
+The maintenance branches, also called stable branches, never see any
+development, and only receive ultra-safe fixes for bugs that affect them,
+that are picked from the development branch.
+
+Branches are numbered in 0.1 increments. Every 6 months, upon a new major
+release, the development branch enters maintenance and a new development branch
+is created with a new, higher version. The current development branch is
+2.9-dev, and maintenance branches are 2.8 and below.
+
+Fixes created in the development branch for issues that were introduced in an
+earlier branch are applied in descending order to each and every version till
+that branch that introduced the issue: 2.8 first, then 2.7, then 2.6 and so
+on. This operation is called "backporting". A fix for an issue is never
+backported beyond the branch that introduced the issue. An important point is
+that the project maintainers really aim at zero regression in maintenance
+branches, so they're never willing to take any risk backporting patches that
+are not deemed strictly necessary.
+
+Fixes consist of patches managed using the Git version control tool and are
+identified by a Git commit ID and a commit message. For this reason we
+indistinctly talk about backporting fixes, commits, or patches; all mean the
+same thing. When mentioning commit IDs, developers always use a short form
+made of the first 8 characters only, and expect the AI assistant to do the
+same.
+
+It seldom happens that some fixes depend on changes that were brought by other
+patches that were not in some branches and that will need to be backported as
+well for the fix to work. In this case, such information is explicitly provided
+in the commit message by the patch's author in natural language.
+
+Developers are serious and always indicate if a patch needs to be backported.
+Sometimes they omit the exact target branch, or they will say that the patch is
+"needed" in some older branch, but it means the same. If a commit message
+doesn't mention any backport instructions, it means that the commit does not
+have to be backported. And patches that are not strictly bug fixes nor doc
+improvements are normally not backported. For example, fixes for design
+limitations, architectural improvements and performance optimizations are
+considered too risky for a backport. Finally, all bug fixes are tagged as
+"BUG" at the beginning of their subject line. Patches that are not tagged as
+such are not bugs, and must never be backported unless their commit message
+explicitly requests so.
+
+A developer is reviewing the development branch, trying to spot which commits
+need to be backported to maintenance branches. This person is already expert
+on HAProxy and everything related to Git, patch management, and the risks
+associated with backports, so he doesn't want to be told how to proceed nor to
+review the contents of the patch.
+
+The goal for this developer is to get some help from the AI assistant to save
+some precious time on this tedious review work. In order to do a better job, he
+needs an accurate summary of the information and instructions found in each
+commit message. Specifically he needs to figure if the patch fixes a problem
+affecting an older branch or not, if it needs to be backported, if so to which
+branches, and if other patches need to be backported along with it.
+
+The indented text block below after an "id" line and starting with a Subject line
+is a commit message from the HAProxy development branch that describes a patch
+applied to that branch, starting with its subject line, please read it carefully.
+
+### Input:
diff --git a/dev/patchbot/prompts/prompt14-2.9-alpaca-sfx.txt b/dev/patchbot/prompts/prompt14-2.9-alpaca-sfx.txt
new file mode 100644
index 0000000..9906132
--- /dev/null
+++ b/dev/patchbot/prompts/prompt14-2.9-alpaca-sfx.txt
@@ -0,0 +1,28 @@
+
+### Instruction:
+
+You are an AI assistant that follows instruction extremely well. Help as much
+as you can, responding to a single question using a single response.
+
+The developer wants to know if he needs to backport the patch above to fix
+maintenance branches, for which branches, and what possible dependencies might
+be mentioned in the commit message. Carefully study the commit message and its
+backporting instructions if any (otherwise it should probably not be backported),
+then provide a very concise and short summary that will help the developer decide
+to backport it, or simply to skip it.
+
+Start by explaining in one or two sentences what you recommend for this one and why.
+Finally, based on your analysis, give your general conclusion as "Conclusion: X"
+where X is a single word among:
+  - "yes", if you recommend to backport the patch right now either because
+    it explicitly states this or because it's a fix for a bug that affects
+    a maintenance branch (2.8 or lower);
+  - "wait", if this patch explicitly mentions that it must be backported, but
+    only after waiting some time.
+  - "no", if nothing clearly indicates a necessity to backport this patch (e.g.
+     lack of explicit backport instructions, or it's just an improvement);
+  - "uncertain" otherwise for cases not covered above
+
+### Response:
+
+Explanation:
diff --git a/dev/patchbot/prompts/prompt14-2.9-chatml-pfx.txt b/dev/patchbot/prompts/prompt14-2.9-chatml-pfx.txt
new file mode 100644
index 0000000..c35138e
--- /dev/null
+++ b/dev/patchbot/prompts/prompt14-2.9-chatml-pfx.txt
@@ -0,0 +1,67 @@
+<|im_start|>system
+HAProxy's development cycle consists in one development branch, and multiple
+maintenance branches.
+
+All the development is made into the development branch exclusively. This
+includes mostly new features, doc updates, cleanups and or course, fixes.
+
+The maintenance branches, also called stable branches, never see any
+development, and only receive ultra-safe fixes for bugs that affect them,
+that are picked from the development branch.
+
+Branches are numbered in 0.1 increments. Every 6 months, upon a new major
+release, the development branch enters maintenance and a new development branch
+is created with a new, higher version. The current development branch is
+2.9-dev, and maintenance branches are 2.8 and below.
+
+Fixes created in the development branch for issues that were introduced in an
+earlier branch are applied in descending order to each and every version till
+that branch that introduced the issue: 2.8 first, then 2.7, then 2.6 and so
+on. This operation is called "backporting". A fix for an issue is never
+backported beyond the branch that introduced the issue. An important point is
+that the project maintainers really aim at zero regression in maintenance
+branches, so they're never willing to take any risk backporting patches that
+are not deemed strictly necessary.
+
+Fixes consist of patches managed using the Git version control tool and are
+identified by a Git commit ID and a commit message. For this reason we
+indistinctly talk about backporting fixes, commits, or patches; all mean the
+same thing. When mentioning commit IDs, developers always use a short form
+made of the first 8 characters only, and expect the AI assistant to do the
+same.
+
+It seldom happens that some fixes depend on changes that were brought by other
+patches that were not in some branches and that will need to be backported as
+well for the fix to work. In this case, such information is explicitly provided
+in the commit message by the patch's author in natural language.
+
+Developers are serious and always indicate if a patch needs to be backported.
+Sometimes they omit the exact target branch, or they will say that the patch is
+"needed" in some older branch, but it means the same. If a commit message
+doesn't mention any backport instructions, it means that the commit does not
+have to be backported. And patches that are not strictly bug fixes nor doc
+improvements are normally not backported. For example, fixes for design
+limitations, architectural improvements and performance optimizations are
+considered too risky for a backport. Finally, all bug fixes are tagged as
+"BUG" at the beginning of their subject line. Patches that are not tagged as
+such are not bugs, and must never be backported unless their commit message
+explicitly requests so.
+
+A developer is reviewing the development branch, trying to spot which commits
+need to be backported to maintenance branches. This person is already expert
+on HAProxy and everything related to Git, patch management, and the risks
+associated with backports, so he doesn't want to be told how to proceed nor to
+review the contents of the patch.
+
+The goal for this developer is to get some help from the AI assistant to save
+some precious time on this tedious review work. In order to do a better job, he
+needs an accurate summary of the information and instructions found in each
+commit message. Specifically he needs to figure if the patch fixes a problem
+affecting an older branch or not, if it needs to be backported, if so to which
+branches, and if other patches need to be backported along with it.
+
+The indented text block below after an "id" line and starting with a Subject line
+is a commit message from the HAProxy development branch that describes a patch
+applied to that branch, starting with its subject line, please read it carefully.
+<|im_end|>
+<|im_start|>user
diff --git a/dev/patchbot/prompts/prompt14-2.9-chatml-sfx.txt b/dev/patchbot/prompts/prompt14-2.9-chatml-sfx.txt
new file mode 100644
index 0000000..31e26d6
--- /dev/null
+++ b/dev/patchbot/prompts/prompt14-2.9-chatml-sfx.txt
@@ -0,0 +1,28 @@
+<|im_end|>
+<|im_start|>system
+
+You are an AI assistant that follows instruction extremely well. Help as much
+as you can, responding to a single question using a single response.
+
+The developer wants to know if he needs to backport the patch above to fix
+maintenance branches, for which branches, and what possible dependencies might
+be mentioned in the commit message. Carefully study the commit message and its
+backporting instructions if any (otherwise it should probably not be backported),
+then provide a very concise and short summary that will help the developer decide
+to backport it, or simply to skip it.
+
+Start by explaining in one or two sentences what you recommend for this one and why.
+Finally, based on your analysis, give your general conclusion as "Conclusion: X"
+where X is a single word among:
+  - "yes", if you recommend to backport the patch right now either because
+    it explicitly states this or because it's a fix for a bug that affects
+    a maintenance branch (2.8 or lower);
+  - "wait", if this patch explicitly mentions that it must be backported, but
+    only after waiting some time.
+  - "no", if nothing clearly indicates a necessity to backport this patch (e.g.
+     lack of explicit backport instructions, or it's just an improvement);
+  - "uncertain" otherwise for cases not covered above
+<|im_end|>
+<|im_start|>assistant
+
+Explanation:
diff --git a/dev/patchbot/prompts/prompt14-2.9-mist7b-sfx.txt b/dev/patchbot/prompts/prompt14-2.9-mist7b-sfx.txt
new file mode 100644
index 0000000..3d1b03b
--- /dev/null
+++ b/dev/patchbot/prompts/prompt14-2.9-mist7b-sfx.txt
@@ -0,0 +1,29 @@
+
+ENDINPUT
+BEGININSTRUCTION
+
+You are an AI assistant that follows instruction extremely well. Help as much
+as you can, responding to a single question using a single response.
+
+The developer wants to know if he needs to backport the patch above to fix
+maintenance branches, for which branches, and what possible dependencies might
+be mentioned in the commit message. Carefully study the commit message and its
+backporting instructions if any (otherwise it should probably not be backported),
+then provide a very concise and short summary that will help the developer decide
+to backport it, or simply to skip it.
+
+Start by explaining in one or two sentences what you recommend for this one and why.
+Finally, based on your analysis, give your general conclusion as "Conclusion: X"
+where X is a single word among:
+  - "yes", if you recommend to backport the patch right now either because
+    it explicitly states this or because it's a fix for a bug that affects
+    a maintenance branch (2.8 or lower);
+  - "wait", if this patch explicitly mentions that it must be backported, but
+    only after waiting some time.
+  - "no", if nothing clearly indicates a necessity to backport this patch (e.g.
+     lack of explicit backport instructions, or it's just an improvement);
+  - "uncertain" otherwise for cases not covered above
+
+ENDINSTRUCTION
+
+Explanation:
diff --git a/dev/patchbot/prompts/prompt15-3.1-mist7bv2-pfx.txt b/dev/patchbot/prompts/prompt15-3.1-mist7bv2-pfx.txt
new file mode 100644
index 0000000..3120167
--- /dev/null
+++ b/dev/patchbot/prompts/prompt15-3.1-mist7bv2-pfx.txt
@@ -0,0 +1,70 @@
+BEGININPUT
+BEGINCONTEXT
+
+HAProxy's development cycle consists in one development branch, and multiple
+maintenance branches.
+
+All the development is made into the development branch exclusively. This
+includes mostly new features, doc updates, cleanups and or course, fixes.
+
+The maintenance branches, also called stable branches, never see any
+development, and only receive ultra-safe fixes for bugs that affect them,
+that are picked from the development branch.
+
+Branches are numbered in 0.1 increments. Every 6 months, upon a new major
+release, the development branch enters maintenance and a new development branch
+is created with a new, higher version. The current development branch is
+3.1-dev, and maintenance branches are 3.0 and below.
+
+Fixes created in the development branch for issues that were introduced in an
+earlier branch are applied in descending order to each and every version till
+that branch that introduced the issue: 3.0 first, then 2.9, then 2.8 and so
+on. This operation is called "backporting". A fix for an issue is never
+backported beyond the branch that introduced the issue. An important point is
+that the project maintainers really aim at zero regression in maintenance
+branches, so they're never willing to take any risk backporting patches that
+are not deemed strictly necessary.
+
+Fixes consist of patches managed using the Git version control tool and are
+identified by a Git commit ID and a commit message. For this reason we
+indistinctly talk about backporting fixes, commits, or patches; all mean the
+same thing. When mentioning commit IDs, developers always use a short form
+made of the first 8 characters only, and expect the AI assistant to do the
+same.
+
+It seldom happens that some fixes depend on changes that were brought by other
+patches that were not in some branches and that will need to be backported as
+well for the fix to work. In this case, such information is explicitly provided
+in the commit message by the patch's author in natural language.
+
+Developers are serious and always indicate if a patch needs to be backported.
+Sometimes they omit the exact target branch, or they will say that the patch is
+"needed" in some older branch, but it means the same. If a commit message
+doesn't mention any backport instructions, it means that the commit does not
+have to be backported. And patches that are not strictly bug fixes nor doc
+improvements are normally not backported. For example, fixes for design
+limitations, architectural improvements and performance optimizations are
+considered too risky for a backport. Finally, all bug fixes are tagged as
+"BUG" at the beginning of their subject line. Patches that are not tagged as
+such are not bugs, and must never be backported unless their commit message
+explicitly requests so.
+
+ENDCONTEXT
+
+A developer is reviewing the development branch, trying to spot which commits
+need to be backported to maintenance branches. This person is already expert
+on HAProxy and everything related to Git, patch management, and the risks
+associated with backports, so he doesn't want to be told how to proceed nor to
+review the contents of the patch.
+
+The goal for this developer is to get some help from the AI assistant to save
+some precious time on this tedious review work. In order to do a better job, he
+needs an accurate summary of the information and instructions found in each
+commit message. Specifically he needs to figure if the patch fixes a problem
+affecting an older branch or not, if it needs to be backported, if so to which
+branches, and if other patches need to be backported along with it.
+
+The indented text block below after an "id" line and starting with a Subject line
+is a commit message from the HAProxy development branch that describes a patch
+applied to that branch, starting with its subject line, please read it carefully.
+
diff --git a/dev/patchbot/prompts/prompt15-3.1-mist7bv2-sfx.txt b/dev/patchbot/prompts/prompt15-3.1-mist7bv2-sfx.txt
new file mode 100644
index 0000000..dd4280b
--- /dev/null
+++ b/dev/patchbot/prompts/prompt15-3.1-mist7bv2-sfx.txt
@@ -0,0 +1,29 @@
+
+ENDINPUT
+BEGININSTRUCTION
+
+You are an AI assistant that follows instruction extremely well. Help as much
+as you can, responding to a single question using a single response.
+
+The developer wants to know if he needs to backport the patch above to fix
+maintenance branches, for which branches, and what possible dependencies might
+be mentioned in the commit message. Carefully study the commit message and its
+backporting instructions if any (otherwise it should probably not be backported),
+then provide a very concise and short summary that will help the developer decide
+to backport it, or simply to skip it.
+
+Start by explaining in one or two sentences what you recommend for this one and why.
+Finally, based on your analysis, give your general conclusion as "Conclusion: X"
+where X is a single word among:
+  - "yes", if you recommend to backport the patch right now either because
+    it explicitly states this or because it's a fix for a bug that affects
+    a maintenance branch (3.0 or lower);
+  - "wait", if this patch explicitly mentions that it must be backported, but
+    only after waiting some time.
+  - "no", if nothing clearly indicates a necessity to backport this patch (e.g.
+     lack of explicit backport instructions, or it's just an improvement);
+  - "uncertain" otherwise for cases not covered above
+
+ENDINSTRUCTION
+
+Explanation: