Question of HP updates that depend on new packages
All, A requirement of packages in the platform is that all dependencies of packages also be in the platform (excluding C libs). When an updated version of an existing platform package includes dependencies on packages that are currently outside the platform we must decide if those packages are to be added to the platform (or if we must stick with the older version of the package). Sometimes this will be trivial, such as if a package splits in two but keeps essentially the same API and module namespace. Sometimes it would means pulling in new packages. Normally new packages should go through the standard process for adding packages [Note: currently, the HP steering committee is nearly ready to present a draft of the procedure for adding new packages.] The case of the OpenGL 2.2.x -> 2.3 update covers both cases above. That is it includes straightforward package splits and also new packages. The last HP release included OpenGL-2.2.1.1. The latest version on hackage is OpenGL-2.3.0.0. OpenGL-2.2.x depends on the base package. OpenGL-2.3.0.0 depends on these extra packages: OpenGLRaw GLURaw ObjectName StateVar Tensor The first two are relatively straightforward. The OpenGL package has modules in the namespace Graphics.Rendering.OpenGL. The OpenGLRaw and GLURaw add modules in the namespaces Graphics.Rendering.OpenGL.Raw and Graphics.Rendering.GLU.Raw. One can easily class these new packages as merely split from the OpenGL package and this does not need much review. The other three packages are: package: ObjectName modules: Data.ObjectName package: StateVar modules: Data.StateVar package: Tensor modules: Data.Tensor These add new modules in the common Data.* namespace, indicating that they are intended for re-use more widely by other packages. The release team should not make a decision on these three packages on its own. We wish to refer these packages to the libraries list for a decision. In particular the libraries list should decide if these new packages should be rubber stamped because they are new dependencies of a package already in the platform, or if the new packages should go through the standard review process for adding packages. Duncan, on behalf of the HP release team
Duncan Coutts wrote:
When an updated version of an existing platform package includes dependencies on packages that are currently outside the platform we must decide if those packages are to be added to the platform (or if we must stick with the older version of the package).
The other specific considerations in this mail aside, sticking with older versions of a package sounds like a recipe for disaster. Isn't there an implicit or explicit requirement on maintainers of packages in the platform that they will only make changes that are acceptable for the platform? I realise that for the current set that have sort of ended up in the platform by default there has been no process of those maintainers accepting these constraints, but nonetheless there needs to be some understanding in place for the future.
In particular the libraries list should decide if these new packages should be rubber stamped because they are new dependencies of a package already in the platform, or if the new packages should go through the standard review process for adding packages.
I don't think new dependencies of this nature, where the functionality exposed is not logically part of the original package, should ever be rubber stamped. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Mon, 2009-08-17 at 14:18 +0100, Sittampalam, Ganesh wrote:
Duncan Coutts wrote:
When an updated version of an existing platform package includes dependencies on packages that are currently outside the platform we must decide if those packages are to be added to the platform (or if we must stick with the older version of the package).
The other specific considerations in this mail aside, sticking with older versions of a package sounds like a recipe for disaster.
It's certainly not ideal. It'd conflict with the HP goal of trying to synchronise the versions of packages people are targeting and using.
Isn't there an implicit or explicit requirement on maintainers of packages in the platform that they will only make changes that are acceptable for the platform?
It's not explicitly codified, particularly how maintainers are expected to judge what is acceptable. In the case at hand the maintainer did ask for feedback on the libraries list about the new dependencies, though I'm not sure that it was clear to people that the implication was that these new packages would be intended become part of the platform.
I realise that for the current set that have sort of ended up in the platform by default there has been no process of those maintainers accepting these constraints, but nonetheless there needs to be some understanding in place for the future.
I agree. As an example, in the GNOME process they have a page listing the responsibilities of maintainers. There's an implication when packages are proposed for inclusion that they have maintainers who are happy to follow the guidelines. The steering committee will be putting a recommendation on the package addition process to this list very shortly. When that gets discussed here we might also like to talk about drawing up a short set of guidelines / principles for maintainers. So yes, the general point is if we all communicate properly and understand each others expectations then we should never end up in the situation where we're forced to decide between accepting under-reviewed dependencies or sticking with an old version of a package. It's completely avoidable.
In particular the libraries list should decide if these new packages should be rubber stamped because they are new dependencies of a package already in the platform, or if the new packages should go through the standard review process for adding packages.
I don't think new dependencies of this nature, where the functionality exposed is not logically part of the original package, should ever be rubber stamped.
That is also my opinion. Duncan
The other specific considerations in this mail aside, sticking with older versions of a package sounds like a recipe for disaster.
It's certainly not ideal. It'd conflict with the HP goal of trying to synchronise the versions of packages people are targeting and using.
I don't see what is so awful about it. Libraries often have a "stable" version and a "development" version. Sticking with the stable version is exactly the right thing for the Platform to do, until the maintainer of the library declares that the development version is sufficiently robust to become the new stable branch. And it is not a disaster if the Platform packagers take a different view on the relative stability of different versions. Regards, Malcolm
Malcolm Wallace wrote:
The other specific considerations in this mail aside, sticking with older versions of a package sounds like a recipe for disaster.
It's certainly not ideal. It'd conflict with the HP goal of trying to synchronise the versions of packages people are targeting and using.
I don't see what is so awful about it. Libraries often have a "stable" version and a "development" version. Sticking with the stable version is exactly the right thing for the Platform to do, until the maintainer of the library declares that the development version is sufficiently robust to become the new stable branch. And it is not a disaster if the Platform packagers take a different view on the relative stability of different versions.
Sorry for being unclear - I meant being indefinitely stuck on an old version, rather than temporarily while a new stable version was under development. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Tue, 2009-08-18 at 12:17 +0100, Malcolm Wallace wrote:
The other specific considerations in this mail aside, sticking with older versions of a package sounds like a recipe for disaster.
It's certainly not ideal. It'd conflict with the HP goal of trying to synchronise the versions of packages people are targeting and using.
I don't see what is so awful about it. Libraries often have a "stable" version and a "development" version. Sticking with the stable version is exactly the right thing for the Platform to do, until the maintainer of the library declares that the development version is sufficiently robust to become the new stable branch.
Sure, in general there can be stable versions and development / preview versions. In the current case, the maintainer recommends the latest version as the stable one and the one to use. There would be some unfortunate fragmentation in this case if no solution is found.
And it is not a disaster if the Platform packagers take a different view on the relative stability of different versions.
That's true, and there are cases like that, but if lots of people agree with the package maintainer (or depend on the latest features) then in practise we do get fragmentation. Duncan
On 17/08/2009 14:10, Duncan Coutts wrote:
All,
A requirement of packages in the platform is that all dependencies of packages also be in the platform (excluding C libs).
When an updated version of an existing platform package includes dependencies on packages that are currently outside the platform we must decide if those packages are to be added to the platform (or if we must stick with the older version of the package).
Sometimes this will be trivial, such as if a package splits in two but keeps essentially the same API and module namespace. Sometimes it would means pulling in new packages. Normally new packages should go through the standard process for adding packages
[Note: currently, the HP steering committee is nearly ready to present a draft of the procedure for adding new packages.]
The case of the OpenGL 2.2.x -> 2.3 update covers both cases above. That is it includes straightforward package splits and also new packages.
The last HP release included OpenGL-2.2.1.1. The latest version on hackage is OpenGL-2.3.0.0.
OpenGL-2.2.x depends on the base package.
OpenGL-2.3.0.0 depends on these extra packages: OpenGLRaw GLURaw ObjectName StateVar Tensor
The first two are relatively straightforward. The OpenGL package has modules in the namespace Graphics.Rendering.OpenGL. The OpenGLRaw and GLURaw add modules in the namespaces Graphics.Rendering.OpenGL.Raw and Graphics.Rendering.GLU.Raw. One can easily class these new packages as merely split from the OpenGL package and this does not need much review.
The other three packages are:
package: ObjectName modules: Data.ObjectName
package: StateVar modules: Data.StateVar
package: Tensor modules: Data.Tensor
These add new modules in the common Data.* namespace, indicating that they are intended for re-use more widely by other packages.
The release team should not make a decision on these three packages on its own. We wish to refer these packages to the libraries list for a decision.
In particular the libraries list should decide if these new packages should be rubber stamped because they are new dependencies of a package already in the platform, or if the new packages should go through the standard review process for adding packages.
We should consider these 3 packages as candidates for inclusion in the platform, and deal with them as we would other candidates; i.e. subject them to the proposal/review process (which I know is in the process of being specified). In this case, we are in the slightly unfortunate position that if the packages are not accepted for inclusion, and even in the absence of any decision at all, the platform will be unable to ship the latest version of OpenGL. In the event that the new packages were rejected, then I imagine OpenGL would either have to re-absorb those modules (as hidden modules), or the platform would have to drop OpenGL since the old version would be unmaintained. I'm fairly confident it wouldn't come to that, though. Personally, I doubt the new packages would be acceptable, at least in their current form. e.g. ObjectName is a very general term for a library that seems to have quite specific functionality. Cheers, Simon
On Mon, Aug 17, 2009 at 3:29 PM, Simon Marlow
We should consider these 3 packages as candidates for inclusion in the platform, and deal with them as we would other candidates; i.e. subject them to the proposal/review process (which I know is in the process of being specified).
In this case, we are in the slightly unfortunate position that if the packages are not accepted for inclusion, and even in the absence of any decision at all, the platform will be unable to ship the latest version of OpenGL.
I would expect this to become a common occurrence as the platform grows, unless a suitable policy is devised. I think Ganesh's suggestion of making this an explicit requirement of maintainers is a very good idea, and codifying exactly what changes are acceptable for the platform may also be helpful. Cheers, John Lato
On Mon, 2009-08-17 at 14:10 +0100, Duncan Coutts wrote:
In particular the libraries list should decide if these new packages should be rubber stamped because they are new dependencies of a package already in the platform, or if the new packages should go through the standard review process for adding packages.
Given the responses it seems that we think that new packages should go through the standard review process for adding packages. In particular "where the functionality exposed is not logically part of the original package" since there is an exception for straightforward package splits. I suggest the dividing line between package splits and genuinely new dependencies be left to the judgement of the release team. So maintainers who would like advice can talk to the release team. Are there any unresolved concerns? If not then we'll go with this as the policy. Duncan
participants (5)
-
Duncan Coutts -
John Lato -
Malcolm Wallace -
Simon Marlow -
Sittampalam, Ganesh