On Thu, 2015-01-08 at 13:38 +0100, Justus Winter wrote: > Hello Svante :)
> > > 1/6: hurd_new_RPC.patch: add new RPC: file_record_lock > > 2/6: libdiskfs_file_record_lock.patch: implement > > diskfs_S_file_record_lock and modify diskfs_S_* accordingly, initialize > > and release lock_status. > > 3/6: libfshelp_rlock.patch: implement fshelp_rlock_* functions > > 4/6: libfshelp-tests_rlock.patch: implement file_record_lock tests > > 5/6: libnetfs_file_record_lock.patch: implement netfs_S_file_record_lock > > 6/6: libtrivfs_file_record_lock.patch: implement > > trivfs_S_file_record_lock > > For my taste, the order of patches is wrong. Please try to make sure, > that the source tree compiles at every point. If you add an RPC with > the first patch, the build will break. Instead, you have to add the > server implementation first, and the RPC definition later. Well, nothing hinders the committer to apply them in any order. Additionally, the original patches were one big blob, I can easily merge everything like that again. To be a little more constructive: Is this patch order correct? 1) libfshelp_rlock.patch: implement fshelp_rlock_* functions 2) libdiskfs_file_record_lock.patch: implement diskfs_S_file_record_lock and modify diskfs_S_* accordingly, initialize and release lock_status. 3) libnetfs_file_record_lock.patch: implement netfs_S_file_record_lock 4) libtrivfs_file_record_lock.patch: implement trivfs_S_file_record_lock 5) hurd_new_RPC.patch: add new RPC: file_record_lock 6) libfshelp-tests_rlock.patch: implement file_record_lock tests > I will not review patches that are not sent using git, but I'm only > speaking for myself of course. I'll try to use git to create the patches, but need some help. Please help me replace the question marks. git clone git://git.sv.gnu.org/hurd/hurd.git git branch my_branch master git checkout my_branch (including the debian/ directory) quilt push/pop/refresh debian/patches/... git apply debian/patches/... git commit ...??? git diff ??? git-format-patch ??? git-send-email ???
