Re: [Buildroot] Make Acked/Reviewd/Tested-by tags visible
Hi, On Tue, Nov 12, 2013 at 7:58 AM, Thomas Petazzoni wrote: [..] >> Other projects have different policies for their tagging (some require 3 >> acks, for example), which will introduce a little complexity there too, >> but that's not insurmountable either. > > Another thing that comes to mind is that not all Acked-by or Tested-by > are equal, I believe. An Acked-by from a well-known long-time > contributor will not be seen with the same level of trust that an > Acked-by from an unknown newcomer. Do we want to add a mechanism of > "rating"? But that would mean the project maintainer would have to > "rate" developers, which is not nice. Or maybe just a list of e-mails > that the project's maintainer considers as trustworthy, and only those > ones would be taken into account when displaying the ART flags? > > Or maybe it doesn't matter too much, since in the vast majority of > cases, only well-known long-time contributors are doing reviews/acks. Patchwork already has the concept of maintainers, that is a list of people having patchwork change privileges. Maybe it is sufficient to differentiate Acked/Reviewed/Tested from either maintainer or non-maintainer? It would not require additional administration. Best regards, Thomas ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Make Acked/Reviewd/Tested-by tags visible
On 12/11/13 07:58, Thomas Petazzoni wrote: Dear Jeremy Kerr, On Tue, 12 Nov 2013 08:37:26 +0800, Jeremy Kerr wrote: We would like to suggest that the web GUI and the pwclient CLI both display such tags besides each patch, a bit like (hypotetical output of pwclient): ID Tags State Subject 123456 ART New Wonderfull patch to apply quickly I've been looking to implement this for a while, but didn't have any good ideas about how to present this in the UI. I love your proposal here with the flags, it's simple and I think would work well for the majority of cases. Since patchwork already inserts those tags to the commit log (eg. pwclient view PATCH-ID), I hope it would be easy enough to also display it in the patch list. It's easy enough to pull these out of the comment at patch-display time, but a little more tricky with list views (without some horrible SQL joining). I'll work out a nice way to to this; I think it'll involve applying these flags when the follow-up comment is parsed. Other projects have different policies for their tagging (some require 3 acks, for example), which will introduce a little complexity there too, but that's not insurmountable either. Another thing that comes to mind is that not all Acked-by or Tested-by are equal, I believe. An Acked-by from a well-known long-time contributor will not be seen with the same level of trust that an Acked-by from an unknown newcomer. Do we want to add a mechanism of "rating"? But that would mean the project maintainer would have to "rate" developers, which is not nice. Or maybe just a list of e-mails that the project's maintainer considers as trustworthy, and only those ones would be taken into account when displaying the ART flags? Or maybe it doesn't matter too much, since in the vast majority of cases, only well-known long-time contributors are doing reviews/acks. I think the ART flags in the patch list should never be used blindly anyway. Instead, it's an indicator of which patches are interesting to look at in more detail. Right? Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect+32-16-286500 Essensium/Mindhttp://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
suggestion: more information on project page
Could you add a link to a version of the code visible within the browser? For those that do not have git installed. (I finally found one on a mirror on https://bitbucket.org/bos/patchwork.) And maybe also one to the documentation? (The doc directory viewable in browser is good enough.) Greetings, Simon ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
[PATCH 3/4] tests/mboxviews: test for unchanged postscript
Currently a patch containing postscript is always modified in patch_to_mbox()
compared to the input patch.
A comment containing 'some comment\n---\n some/file | 1 +' will be changed to
'some comment\n\n---\nsome/file | 1 +\n' which is annoying.
This patch adds a test to detect that, a follow up patch will fix the error
then.
Signed-off-by: Andreas Bießmann
---
apps/patchwork/tests/mboxviews.py | 28
1 file changed, 28 insertions(+)
diff --git a/apps/patchwork/tests/mboxviews.py
b/apps/patchwork/tests/mboxviews.py
index 6209513..0e57f42 100644
--- a/apps/patchwork/tests/mboxviews.py
+++ b/apps/patchwork/tests/mboxviews.py
@@ -179,3 +179,31 @@ class MboxDateHeaderTest(TestCase):
mail = email.message_from_string(response.content)
mail_date = dateutil.parser.parse(mail['Date'])
self.assertEqual(mail_date, date)
+
+class MboxCommentPostcriptUnchangedTest(TestCase):
+""" Test that the mbox view doesn't change the postscript part of a mail.
+There where always a missing blank right after the postscript
+delimiter '---' and an additional newline right before. """
+def setUp(self):
+defaults.project.save()
+
+self.person = defaults.patch_author_person
+self.person.save()
+
+self.patch = Patch(project = defaults.project,
+ msgid = 'p1', name = 'testpatch',
+ submitter = self.person, content = '')
+self.patch.save()
+
+self.txt = 'some comment\n---\n some/file | 1 +\n'
+
+comment = Comment(patch = self.patch, msgid = 'p1',
+submitter = self.person,
+content = self.txt)
+comment.save()
+
+def testCommentUnchanged(self):
+response = self.client.get('/patch/%d/mbox/' % self.patch.id)
+self.assertContains(response, self.txt)
+self.txt += "\n"
+self.assertNotContains(response, self.txt)
--
1.7.10.4
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
[PATCH 4/4] views: fix patch_to_mbox() for postscript
Before we changed the comment 'some comment\n---\n some/file | 1 +' to 'some comment\n\n---\nsome/file | 1 +\n'. Now we pass this comment unchanged. Signed-off-by: Andreas Bießmann --- apps/patchwork/views/__init__.py |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/apps/patchwork/views/__init__.py b/apps/patchwork/views/__init__.py index a823388..dd307e0 100644 --- a/apps/patchwork/views/__init__.py +++ b/apps/patchwork/views/__init__.py @@ -173,7 +173,7 @@ def patch_to_mbox(patch): if len(parts) == 2: (body, postscript) = parts body = body.strip() + "\n" -postscript = postscript.strip() + "\n" +postscript = postscript.rstrip() else: postscript = '' @@ -181,11 +181,8 @@ def patch_to_mbox(patch): .exclude(msgid = patch.msgid): body += comment.patch_responses() -if body: -body += '\n' - if postscript: -body += '---\n' + postscript.strip() + '\n' +body += '---\n' + postscript + '\n' if patch.content: body += '\n' + patch.content -- 1.7.10.4 ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Make Acked/Reviewd/Tested-by tags visible
Dear Jeremy Kerr, On Tue, 12 Nov 2013 08:37:26 +0800, Jeremy Kerr wrote: > > We would like to suggest that the web GUI and the pwclient CLI both > > display such tags besides each patch, a bit like (hypotetical output of > > pwclient): > > > > ID Tags State Subject > > 123456 ART New Wonderfull patch to apply quickly > > I've been looking to implement this for a while, but didn't have any > good ideas about how to present this in the UI. I love your proposal > here with the flags, it's simple and I think would work well for the > majority of cases. > > > Since patchwork already inserts those tags to the commit log (eg. > > pwclient view PATCH-ID), I hope it would be easy enough to also display > > it in the patch list. > > It's easy enough to pull these out of the comment at patch-display time, > but a little more tricky with list views (without some horrible SQL > joining). I'll work out a nice way to to this; I think it'll involve > applying these flags when the follow-up comment is parsed. > > Other projects have different policies for their tagging (some require 3 > acks, for example), which will introduce a little complexity there too, > but that's not insurmountable either. Another thing that comes to mind is that not all Acked-by or Tested-by are equal, I believe. An Acked-by from a well-known long-time contributor will not be seen with the same level of trust that an Acked-by from an unknown newcomer. Do we want to add a mechanism of "rating"? But that would mean the project maintainer would have to "rate" developers, which is not nice. Or maybe just a list of e-mails that the project's maintainer considers as trustworthy, and only those ones would be taken into account when displaying the ART flags? Or maybe it doesn't matter too much, since in the vast majority of cases, only well-known long-time contributors are doing reviews/acks. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
[PATCH 2/4] settings.py: use python to find ROOT_DIR
Signed-off-by: Andreas Bießmann
---
apps/settings.py |4 +---
docs/INSTALL |7 ---
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/apps/settings.py b/apps/settings.py
index 43a37d8..4e09a29 100644
--- a/apps/settings.py
+++ b/apps/settings.py
@@ -68,9 +68,7 @@ ROOT_URLCONF = 'apps.urls'
LOGIN_URL = '/user/login/'
LOGIN_REDIRECT_URL = '/user/'
-# If you change the ROOT_DIR setting in your local_settings.py, you'll need to
-# re-define the variables that use this (MEDIA_ROOT and TEMPLATE_DIRS) too.
-ROOT_DIR = '/srv/patchwork'
+ROOT_DIR = os.path.join(os.path.dirname(os.path.abspath(__file__)), os.pardir)
TEMPLATE_DIRS = (
# Put strings here, like "/home/html/django_templates" or
"C:/www/django/templates".
# Always use forward slashes, even on Windows.
diff --git a/docs/INSTALL b/docs/INSTALL
index e5f88e8..b7924d8 100644
--- a/docs/INSTALL
+++ b/docs/INSTALL
@@ -113,13 +113,6 @@ in brackets):
chars = string.letters + string.digits + string.punctuation
print repr("".join([random.choice(chars) for i in range(0,50)]))
-If you have patchwork installed in somewhere other than /srv/patchwork,
-you'll also need to define:
-
- ROOT_DIR
- MEDIA_ROOT
- TEMPLATE_DIRS
-
If you wish to enable the XML-RPC interface, add the following to
your local_settings.py file:
--
1.7.10.4
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
[PATCH 1/4] INSTALL: adopt PYTHONPATH
Signed-off-by: Andreas Bießmann --- docs/INSTALL |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/INSTALL b/docs/INSTALL index 91c6081..e5f88e8 100644 --- a/docs/INSTALL +++ b/docs/INSTALL @@ -128,7 +128,7 @@ in brackets): Then, get patchwork to create its tables in your configured database: cd apps/ - PYTHONPATH=../lib/python/django ./manage.py syncdb + PYTHONPATH=../lib/python ./manage.py syncdb And add privileges for your mail and web users. This is only needed if you use the ident-based approach. If you use password-based database -- 1.7.10.4 ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
