On 19.07.19 15:50, Stephen Finucane wrote:
[re-adding the list]
On Fri, 2019-07-19 at 14:44 +0200, Lukas Bulwahn wrote:
On Mon, Jul 15, 2019 at 5:39 PM Stephen Finucane <step...@that.guru> wrote:
On Mon, 2019-07-15 at 16:50 +0200, Mete Polat wrote:
[snip]
+ def add_arguments(self, parser):
+ parser.add_argument(
+ '-c', '--compress', action='store_true',
+ help='Bundle and compress projects.'
+ )
+ parser.add_argument(
+ '-l', '--level', action='store', type=int, default=9,
+ help='Set a compression level between 0 and 9 (default). 0 is no '
+ 'compression. '
+ )
Do we need this knob? It seems defaulting to 9 if the '-c' flag is
provided would be fine for 90% of users?
I am wondering if we need compression at all.
Following the UNIX philosophy (only do Make each program do one thing
well.), I would expect that the management command can either generate
files/an archive file or I can configure it to output the file/the
archive to standard output.
I can then simply compress by pipe-ing that to any other compression utility.
Stephen, Mete, what do you think?
That's a fair point but I'm not sure how we could support both dumping
to stdout and multiple projects: how would you decide which patches
belonged to which project? Looking at the logic here though, I do think
we could tweak it slightly. Could we *always* generate a tarball,
regardless of the number of projects, and optionally compress it if we
decide to keep the '--compress' flag? I've drafted this and it looks
good to me. I also think we might want to rename the command
'dumparchive' to match with 'parsearchive'. I'm happy to rework on both
counts. Thoughts?
Stephen
I agree you Stephen on both points. We should also consider using the
project's
listId instead of the linkname in order to match with the other
commands. Feel
free to implement your changes when Lukas also agrees on your points.
Mete
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
