From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1D1ECB5B-4956-4969-BB25-532831254927@corpus-callosum.com> References: <92606a17ce255a2e74049e4090d948b3@proxima.alt.za> <36c5eca0f06e9acbe2fac19067f457d8@ladd.quanstro.net> <20140519195016.B21E6B827@mail.bitblocks.com> <3a6dcbf0845989d60e627ad4e5df4313@ladd.quanstro.net> <3A01CE35-B176-4A24-B3D4-24AB0874BB48@9srv.net> <1c303148ec8dc74c876330176c2fa54c@mikro.quanstro.net> <1D1ECB5B-4956-4969-BB25-532831254927@corpus-callosum.com> Date: Tue, 20 May 2014 18:37:13 -0700 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b2e438625fa5804f9df09bc Subject: Re: [9fans] syscall 53 Topicbox-Message-UUID: eab32dc6-ead8-11e9-9d60-3106f5b1d025 --047d7b2e438625fa5804f9df09bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes, it was a lack of *any* notice; i occasionally check /n/sources/patch for incoming patches and i don't believe the NSEC patch went through that channel. in the past, changes that had a system-wide or kernel effect were announce, and instructions for upgrading were given. certainly, it's not required; but it is appreciated. i believe any successful Plan 9 distro will need to provide some transparency in the change review process. the sources patch process can work, but with codereview extensions now available, it might make sense to create/switch to a repository hosted on an hg site so that all the change requests, discussions and reviews are available to everyone; perhaps this is what Charles had in mind for http://code.google.com/p/plan9, but i'm not sure. -Skip On Tue, May 20, 2014 at 1:33 PM, Jeff Sickel wrote= : > > On May 20, 2014, at 11:41 AM, ron minnich wrote: > > > This is not a human communication problem. It's a technology problem, > > trivially solved for many years now by many systems. > > This event was a communication problem. > > The technology, replica, works as advertised. In general it does > a very good job at maintaining server->client updates and allows > you to work around differences in a way some may prefer over other > options that are out there. > > The technology, Plan 9 (and forks), have rather clean mechanisms > already in place to go through the classic development operation > cycle of > > think =E2=80=94 edit =E2=80=94 make =E2=80=94 test ... > > The feedback loop, like all, requires communication protocols > to complete the iteration and move the cycle to the next step. > > How many of those chromebooks have customized kernels to support > drivers undergoing new development? And of those that do run custom > kernels, are they getting automatic updates w/o a bill of materials > or other list defining what will be updated? And are the developers > working on those custom versions working in a vacuum or do they have > communication protocols in place to facilitate their working environment? > > For all practical purposes, 9fans is the last remaining forum for people > interested in using Plan 9 related systems. Please advise if you have > recommendations for other communications outlets that allow people to > develop, test, and maybe improve on ideas brought about by this system > many of us find enough interest in to actually use. > > -jas > > > --047d7b2e438625fa5804f9df09bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes, it was a lack of *any* notice; i occasional= ly check /n/sources/patch for incoming patches and i don't believe the = NSEC patch went through that channel. in the past, changes that had a syste= m-wide or kernel effect were announce, and instructions for upgrading were = given. certainly, it's not required; but it is appreciated.

i believe any successful Plan 9 distro will need to pro= vide some transparency in the change review process. the sources patch proc= ess can work, but with codereview extensions now available, it might make s= ense to create/switch to a repository hosted on an hg site so that all the = change requests, discussions and reviews are available to everyone; =C2=A0p= erhaps this is what Charles had in mind for http://code.google.com/p/plan9, but i'm not sure.

-Skip

On Tue, May 20, 2014 at 1:33 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:

On May 20, 2014, at 11:41 AM, ron minnich <rminnich@gmail.com> wrote:

> This is not a human communication problem. It's a technology probl= em,
> trivially solved for many years now by many systems.

This event was a communication problem.

The technology, replica, works as advertised. =C2=A0In general it does
a very good job at maintaining server->client updates and allows
you to work around differences in a way some may prefer over other
options that are out there.

The technology, Plan 9 (and forks), have rather clean mechanisms
already in place to go through the classic development operation
cycle of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 think =E2=80=94 edit =E2=80=94 make =E2=80=94 t= est ...

The feedback loop, like all, requires communication protocols
to complete the iteration and move the cycle to the next step.

How many of those chromebooks have customized kernels to support
drivers undergoing new development? =C2=A0And of those that do run custom kernels, are they getting automatic updates w/o a bill of materials
or other list defining what will be updated? =C2=A0And are the developers working on those custom versions working in a vacuum or do they have
communication protocols in place to facilitate their working environment?
For all practical purposes, 9fans is the last remaining forum for people interested in using Plan 9 related systems. =C2=A0Please advise if you have=
recommendations for other communications outlets that allow people to
develop, test, and maybe improve on ideas brought about by this system
many of us find enough interest in to actually use.

-jas



--047d7b2e438625fa5804f9df09bc--