[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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
