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