[Release] 3.11 liaison change

[Keith Hodges]

> Guys, maybe you should turn a discussion in more rational plane?
>   
I have been planning to add a feedback mechanism to MC1.5 for ages. Some
method for adding comments to versions "after" they have been committed.
Some means to indicate whether a version is good for anything, whether
it has a bug etc.

In my opinion without that feedback mechanism in MC, MC is pretty much
useless as a medium for managing, and collating proposed changes to a
kernel image. MCM is also a very dry tool, when you look at an mcm in
the browser it doesnt even tell you what is going to be loaded.

This is entirely different to an MC package that has a maintainer, and
has undertaken to keep integrating incoming fixes. In this case the
maintainer is left with the responsibility of knowing what works where
and can maintain his own bug reporting and feedback mechanism.

3.9 used MC and they did nothing other than complain about it. So I dont
think that using MC as an inbox is the way forward.
=

The way forward as I see it is to be able to present an image with the
new item completed, or almost completed. Then having captured the
knowledge that you applied to make this transformation, publish that in
a manner than can be used as a component in the release integration process.

So lets take an example... I want to include Rio in the kernel replacing
FileDirectory. This is the use case that I have been considering all along.

I need an image to work on, and images with as many packages that may be
effected as possible to test with. So I start working, I load Rio, and I
start patching the system until I get something that works.

I am working in 3.11 to make a 3.11+rio , where rio is the build script
that loads rio and applies patches.
I am testing in 3.11-full to make a 3.11-full+rio
I am testing in 3.11-dev to make a 3.11-dev+rio
I am testing in 3.11-magmaserver to make a 3.11-magmaserver+rio

The results will be:

1. (un)Loadable Packages
2. ChangeSets/DS patches
3. An MC repository with all effected kernel packages saved, e.g.
Providing a -rio- branch of Network etc.
3. An MC repository with all effected loadable packages saved - e.g. if
I choose to port Magma to use Rio, I would have Magma versions with a
rio branch that the Magma maintainer can refer to.

I publish my work as a build script/task that is able to take a base
image and merge in Rio,
(the advantage of a task is that it is may, in theory, be constructed so
as to be resilient to variations in the image to which it is applied)

I test my build script in as several images as possible, and since it is
public all the forks have a chance to try loading the new module.

So along comes a 3.12 release team member, the release team member has
defined 3.12 as:

3.12 = 3.11 + latest + fixes + closures + namespaces

This build is performed and tested by bob on a regular basis, each part
of the process is being worked upon by a different volunteer.
he can include my new revolutionary change by applying my build script,
a combination of CS/DS and loaded packages.

3.12 = 3.11 + latest + fixes + closures + namespaces + rio

However, since the build team have made the build process publically
available long before it was complete I would have already made a

3.12-rio = 3.12 + rio

So to move forward... begin by proposing a project that we want, and get
working, publish the results in a manner which can be applied as a
component in a larger build process, or multiple build processes in use
by different forks.

So...

Project 1. Atomic loading (entirely loadable as a package)
Project 2. Anyone for fixing the changes file limit?
Project 3. Annex FileDirectory
Project 4. Replace ChangeSets with DS.



Keith