process

[Nemo]

Hi,

At lsub we are going to abandon hg, but keep the code review process.
It's likely we will not submit new patches to the google code rep.

Instead, we have setup a new development process, similar to the current one,
only that using new tools, hosted on nix.

We made the process so that it's trivial to migrate from google code to nix
just by

9fs sources.lsub.org
cp /n/sources.lsub.org/nix/rc/bin/patch/* /rc/bin/patch

as said in the /PROCESS file.

The main nix tree kept at sources.lsub.org corresponds to the current
state of affairs in google code.

Also, http://lsub.org/export/nix.tgz contains it all.

I include there the new /PROCESS file in case anyone wants to try the new tools.
If you want to make sure the new tools work fine, you might just give us one week
so we suffer all the bugs ourselves.

Until next monday, the announces generated by the tools are going to
a lsub mailing list to avoid noise in this list. Then, we'll make them report
to this list to keep it posted and keep discussions here, as usual.

Enjoy.

---------------------------------------------------------------------
The NIX development process has been
created to simplify distributed development.

HOW TO INSTALL:
--------------

1a. Download the nix distribution
(for example:
9fs sources.lsub.org
cp /n/sources.lsub.org/nix.tgz .
or
hget http://lsub.org/export/nix.tgz >nix.tgz
then
...unpack it...

)

or

1b. Prepare an already downloaded nix (perhaps from googlecode) to
work with the process.

(for example:
9fs sources.lsub.org
cp /n/sources.lsub.org/nix/rc/bin/patch/* /rc/bin/patch
)

2. Run it.
(for example, after tar zx <nix.tgz,
9vx.OSX -r nix -u glenda
)

HOW TO UPDATE YOUR COPY:
-----------------------

run this:
% patch/pull
...you'll see patches applied...

HOW TO CONTRIBUTE AND REVIEW:
---------------------------
1. Subscribe to the nix-dev mailing list
http://groups.google.com/group/nix-dev (all development
correspondance, including codereviews, goes here).

2. Install a copy as explained before.

3. In nix, run:

patch/create patchname your@mail files-changed-or-removed...

You should see a mail in nix-dev in a while reporting the new patch.
At this point, patch reviewers would:

patch/apply patchname

to try the patch, and, when done, run

patch/undo patchname

to restore the previous state of affairs.

Reviewing happens by following up to the mail reporting the patch
creation.

4. You might want to make changes after reviewing. To do so, you woud:

patch/create patchname your@mail files-changed-or-removed...

Here, it's important that you use exactly the same patchname.
The process continues until the patch has been LGTM'd in the mailing list.
At that point, a maintainer of the nix distribution will

patch/Apply patchname

and, from that point in time, everyone running

patch/pull

will get your patch applied.

[erik quanstrom]

thanks for all this!

i have one question though.

> run this:
> % patch/pull
> ...you'll see patches applied...
>

do you have a recommendation for
selectively applying patches? i need to be
careful about not breaking other things.

something like the plan 9 patch does, keeping the old new and applied
version wrt to the main file server at bell labs is really great. one can
diff one's own version against the original, in case the original differences
were forgotten.

sorry to be a pain about this.

also, do you at lsub still need to use some of the equipment
we've got?

- erik

[Nemo]

pull will know which ones to apply.
and yes.

I'll elaborate later when I get a keyboard.

--
iphone kbd. excuse typos :)

[Charles Forsyth]

I get this a lot, now. Perhaps you need a screen and a keyboard? They might conveniently be packaged together! I don't know what to call it. "Notebook"?

[David du Colombier]

Thanks for your work. It looks really great.

How synchronization with Plan 9 will work?

You could apply the patches sent by the 9changes [1]
mailing list directly, and automatically generate
a NIX patch with patch/create.

[1] https://groups.google.com/group/9changes

--
David du Colombier

[Nemo]

I think I could make something
to generate the patches from there.
will take a look.

--
iphone kbd. excuse typos :)

[Nemo]

First, to answer Charles, the problem is that in the cinema the macbook air would look
much more weird than the iphone :) Otherwise I'd carry it there.

Now...

On Apr 13, 2012, at 8:30 PM, erik quanstrom wrote:

> do you have a recommendation for
> selectively applying patches? i need to be
> careful about not breaking other things.
>

The idea is that when you patch/Apply (ie., apply to the main tree)
the patch name is added to /dist/patch/applied, an append only file.
That's done by patch/applied btw.

Now, when you patch/pull from any clone of the main tree, pull
takes a look to the local /dist/patch/applied, and takes the suffix from
/n/sources.lsub.org/nix/dist/patch/applied (IIRC) to determine which patches
must be applied to your tree, and in which order.

It then applies them one by one.

The apply process tries to merge changes. But, should this fail or should you
want to gain manual control, you can find at /dist/patch the original files
(at the time of patch creation), the new (patched) files, the list of files to delete,
and (if you have applied the patch) the backup files (the ones you had before applying
the patch).

So, you should have everything you need.
Plus, I'd be more than happy to change the tools and/or the format of the patches
to provide everything we all need.

I hope I answered your question now that I don't have to use the iphone keyboard.

Regarding equipment, yes, I've been busy with other stuff but I'd like to get access
to that to try the kernel in a different platform. I'll drop you a line off list.
Thanks for offering that again!

cheers

[Nemo]

More tips, mainly to answer Erik,

with the new version you can patch/apply any patch
you want, and then patch/pull when you want.

pull tries to be careful not to undo your local changes,
if it finds conflicts it does not apply the patch at all, and stops.

If you want to skip one patch, you could
echo patchname >>/dist/patch/applied
so that it's considered applied and ignored.

If want to apply part of a patch, after a conflict, you can just edit
/dist/patch/patchname/files
and remove from the file list those you don't want.

I don't know if perhaps we should include something like
patch/skip patchname [files]

Any idea there?

[Steve Simon]

> patch/skip patchname [files]

personally I would go for this, I would keep the patch file list
unchanged and store a seperate skipped file list.

-Steve

[Nemo]

Or perhaps just two files you could edit?

/lib/patch.skip
/lib/patch.skipfiles

the former could list patch names to ignore,
the other could list files that are never "patched"

patch/apply could be changed to look at those
and pretend that, if the patch or a file is a skip, it's just ok
but ignored.

It would be trivial to make this change.

[steve]

sounds good.

in my experience with replica, i sometimes want to skip updates
only temporally - whilst my patch is in discussion, having the ability
to skip a patch or file, and then later re-apply it.

when we have a locally modified file that clashes with a patch it would be
great to have the usual VCS options:

diff of local vs patch
merge local with patch
take local -add file to skipfile list
take patch - force overwrite

the nicest way to do these IMHO, is to print the commands to do these
operations and let the user select and "send" the one they want, like kill(1)
and friends.

how would the patches to be read? directly from a remote
filesystem, like replica, (maybe using ix to speed access on high latency links)?
maybe read a mkfs image which can be transferred via 9p or even http?

i'm not suggesting you add all these features now, just that they are things to
consider in the design.

-Steve

[Nemo]

> the nicest way to do these IMHO, is to print the commands to do these
> operations and let the user select and "send" the one they want, like kill(1)
> and friends.

That's a good idea. I'll change diagnostics to do that.

>
> how would the patches to be read? directly from a remote
> filesystem, like replica, (maybe using ix to speed access on high latency links)?
> maybe read a mkfs image which can be transferred via 9p or even http?

What apply does is that it copies from patches.lsub.org the patch to
/dist/patch/patchname

then it uses that to process the patch.
If there are conflicts or any problem, you have at /dist/patch/patchname
everything you need to fix the problems.

patchname/files -> list of files that change (or are added)
patchname/removed -> list of files to remove

patchname/file, file.orig, file.backup

the new file, the original file by the time of the patch creation and your version of
the file by the time of the apply.

patchname/diffs

are the differences.

The aim of patch(1) is that the tool should make it easy for you to directly use
the patch directory and the /dist/patch/applied file to edit them at will and use
them to do what you might want to do that patch(1) did not envision.

[Anthony Martin]

One request: can we have patch/diff output
context-style diffs. I find them easier to
read.

Thanks,
Anthony

[Francisco J Ballesteros]

Sure.
I'll make the change.