diff mbox series

[3/3] README.md: Overview of snowpatch philosophy

Message ID 20180723032129.4365-3-andrew.donnellan@au1.ibm.com
State Superseded
Headers show
Series [1/3] CONTRIBUTING.md: Update references, add rustfmt information | expand

Commit Message

Andrew Donnellan July 23, 2018, 3:21 a.m. UTC
snowpatch is not unique when it comes to patches + CI. Add some
explanations of the overall design philosophy of snowpatch and why it's
better than alternatives for some projects.

Closes: #4 ("Document alternatives to snowpatch")
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
---
 README.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

Comments

Russell Currey July 23, 2018, 4:14 a.m. UTC | #1
On Mon, 2018-07-23 at 13:21 +1000, Andrew Donnellan wrote:
> snowpatch is not unique when it comes to patches + CI. Add some
> explanations of the overall design philosophy of snowpatch and why
> it's
> better than alternatives for some projects.
> 
> Closes: #4 ("Document alternatives to snowpatch")
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> ---

Would also mention Patchew which is kind of a combined
patchwork+snowpatch, without the maintainer influence on the listing,
distributed sources of tests etc - being a good choice for projects
that are singularly hosted & tested and aren't already using Patchwork
(and just want a plain mailing list view and not like a maintainer
patch status)
Andrew Donnellan July 23, 2018, 6:21 a.m. UTC | #2
On 23/07/18 14:14, Russell Currey wrote:
> Would also mention Patchew which is kind of a combined
> patchwork+snowpatch, without the maintainer influence on the listing,
> distributed sources of tests etc - being a good choice for projects
> that are singularly hosted & tested and aren't already using Patchwork
> (and just want a plain mailing list view and not like a maintainer
> patch status)

Ooh good point
diff mbox series

Patch

diff --git a/README.md b/README.md
index dff8dd64c8b9..f6a53e494438 100644
--- a/README.md
+++ b/README.md
@@ -17,6 +17,23 @@  At present, snowpatch supports
 [Patchwork](http://jk.ozlabs.org/projects/patchwork/) and
 [Jenkins](http://jenkins-ci.org).
 
+snowpatch is designed in line with Patchwork's philosophy of supplementing,
+rather than replacing, existing workflows. For projects which already use
+Patchwork as their core patch management tool, snowpatch does not impose any
+additional changes to the development workflow.
+
+snowpatch requires nothing more than a Patchwork account and Jenkins account
+with appropriate permissions and an API key. Many projects using patch-based
+workflows are highly decentralised, using Patchwork instances they do not
+administer, and build machines hidden behind corporate firewalls. As such,
+snowpatch is designed not to require administrator access or additional plugins
+for either Patchwork or Jenkins.
+
+snowpatch is deliberately minimalistic, which distinguishes it from tools like
+[Zuul](https://zuul-ci.org) which are more sophisticated and may be more
+appropriate for projects with a better ability to adapt their workflow around a
+comprehensive CI system.
+
 snowpatch is named in honour of
 [skiboot](https://github.com/open-power/skiboot), the project which inspired the
 creation of snowpatch.