Libguestfs - Jun 2020 - Re: nbdkit rust plugin: copyright notices, Cargo workspace, and macro hygiene

On 6/17/20 6:23 AM, Richard W.M. Jones wrote:
> I pushed 2 & 3, thanks.
> 
> But ...
> 
>>  From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001
>> From: Alan Somers <asomers@gmail.com>
>> Date: Mon, 15 Jun 2020 16:59:53 -0600
>> Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level directory
>>
>> This is necessary for other Rust projects to depend on unrelesed
unreleased
>> versions of the nbdkit crate.
As a meta-comment, it's easier to review patches sent inline, one patch 
per email, rather than multiple patches as opaque attachments to one 
email; the difference being that I can immediately reply to the patch in 
my mailer without having to open a file and pasting contents.  git 
send-email makes it easy to send patch series in this way, if you want 
to figure out how to set that up.  But it's not a showstopper if you 
keep your current workflow for submitting patches.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

On Wed, Jun 17, 2020 at 7:33 AM Eric Blake <eblake@redhat.com> wrote:
> On 6/17/20 6:23 AM, Richard W.M. Jones wrote:
> > I pushed 2 & 3, thanks.
> >
> > But ...
> >
> >>  From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00
2001
> >> From: Alan Somers <asomers@gmail.com>
> >> Date: Mon, 15 Jun 2020 16:59:53 -0600
> >> Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level
directory
> >>
> >> This is necessary for other Rust projects to depend on unrelesed
>
> unreleased
>
> >> versions of the nbdkit crate.
>
> As a meta-comment, it's easier to review patches sent inline, one patch
> per email, rather than multiple patches as opaque attachments to one
> email; the difference being that I can immediately reply to the patch in
> my mailer without having to open a file and pasting contents.  git
> send-email makes it easy to send patch series in this way, if you want
> to figure out how to set that up.  But it's not a showstopper if you
> keep your current workflow for submitting patches.
>
As a meta-comment, it would be a lot easier to review patches if you would
accept PRs.  If you're wary of Github's closed-source nature, why not
Gitlab?  It's easy to move a project from github to gitlab, and its PR
system is in some ways even better.  Personally, I don't think Github
offers very much value at all if you eschew PRs.
-Alan

On Wed, Jun 17, 2020 at 08:38:30AM -0600, alan somers
wrote:
> On Wed, Jun 17, 2020 at 7:33 AM Eric Blake <eblake@redhat.com> wrote:
> 
> > On 6/17/20 6:23 AM, Richard W.M. Jones wrote:
> > > I pushed 2 & 3, thanks.
> > >
> > > But ...
> > >
> > >>  From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17
00:00:00 2001
> > >> From: Alan Somers <asomers@gmail.com>
> > >> Date: Mon, 15 Jun 2020 16:59:53 -0600
> > >> Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level
directory
> > >>
> > >> This is necessary for other Rust projects to depend on
unrelesed
> >
> > unreleased
> >
> > >> versions of the nbdkit crate.
> >
> > As a meta-comment, it's easier to review patches sent inline, one
patch
> > per email, rather than multiple patches as opaque attachments to one
> > email; the difference being that I can immediately reply to the patch
in
> > my mailer without having to open a file and pasting contents.  git
> > send-email makes it easy to send patch series in this way, if you want
> > to figure out how to set that up.  But it's not a showstopper if
you
> > keep your current workflow for submitting patches.
> >
> 
> As a meta-comment, it would be a lot easier to review patches if you would
> accept PRs.  If you're wary of Github's closed-source nature, why
not
> Gitlab?  It's easy to move a project from github to gitlab, and its PR
> system is in some ways even better.  Personally, I don't think Github
> offers very much value at all if you eschew PRs.
I don't think PRs are a good way to review, and until I can open and
edit one in emacs from the command line I don't think that's likely to
change for me.  However we are indeed looking at gitlab, although
we're planning to wait a little while to see how it works for the
libvirt team first.  Libvirt team moved to gitlab only a couple of
months ago.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v