Re: [MinGW-dvlpr] package contributions [WAS: libunistring]

[Keith M. <kei...@us...>]

On 16/10/11 18:55, Charles Wilson wrote:
> So, to sum up the areas of agreement so far:
> 
> 1) Contributions are welcome, and can/should be hosted on mingw.org

Yes.

> 2) They must be completely compatible with the core MinGW (or MSYS)
>     distribution (e.g. not clobber existing files, are installed
>     "properly" into the appropriate directory hierarchy, etc).

Imperative, yes.

>     a) It is the responsibility of the MinGW devs to ensure this
>        is true before approving a new contribution for upload.
>     [***]

Yes.

> Propositions for which consensus has not yet been achieved:
> 
> 3) Contributions should be mingw-get compatible (manifests, package
>     naming scheme, etc)

Ideally, yes, but who will assume retrospective responsibility for
bringing existing contributions up to standard, where the original
contributor has walked away?

> 4) Policies and procedures for approving new contributions. Also,
>     division of responsibility: what is the contributor responsible for,
>     and what are the MinGW devs responsible for?

Needs further discussion; I'll need to get back to you on this one.

> 5) Policies and procedures for handling updates of existing
>     contributions. Also, division of responsibility.

As (4).

> 6) No "official" or "core" package may depend on a Contributed item,
>     unless that item is also promoted to core.  As this imposes a higher
>     (and perpetual) responsibility on the MinGW devs, this promotion
>     probably needs unanimous agreement from the exising MinGW devs.

This is potentially problematic.  For example, we discussed adopting Lua
as a scripting engine for mingw-get.  I've been exploring that avenue of
development; the Lua core itself is easy.  I'd considered providing it
as a contributed package, as lua-5.1.4-mingw32, and linking mingw-get
statically with that specific version.  If I'm now required to only
depend on a core package, which implies responsibility for perpetual
updates, as Lua itself evolves, then who is going to accept that
responsibility; it isn't going to be me.  (Rationale: If I link
statically with that specific lua-5.1.4 implementation, then I can
continue to support mingw-get, without any need to follow future Lua
developments, which might actually have a detrimental impact for
mingw-get development.  I neither need, nor want, to be continually
chasing Lua evolution, on both sides of the development fence; even an
unmaintained contributed lua-5.1.4 package set is perfectly fine, and
may even be preferable, for mingw-get's development needs).

> 7) Contributed items should be housed on frs in their own subdirectory
>     of the appropriate subsystem.

Agreed.  I'd also suggest within a subsidiary hierarchy to demarcate the
boundary between core and contributed.

> 8) The xml manifests for Contributed items should specify a specific
>     affiliate group, either "MinGW Contributed" or "MSYS Contributed"

Agreed.  I would have suggested this myself, if you hadn't beaten me to it.

> 9) Should contributors be given write access to CVS to update their own
>     manifests, even if they do not join the project as MinGW devs?

No.  I don't believe that's even possible; only project members can be
granted CMS access, (regulated by SF's policies).

Alternative question: is it necessary to integrate manifests for any
contributed package, (beyond the need to add a reference in the master
catalogue), into mingw-dist CVS?  Adding the master catalogue reference
is a one time action for a MinGW dev; thereafter, the contributor can
maintain his own manifest, as part of his package set, requiring only
upload assistance for subsequent package updates.

>     Should they be given upload access to the frs to upload their own
>     contributions, even if they do not join the project as MinGW devs?

Again, I don't think SF's policy would accommodate this, even if we
wanted to permit it, (and IMO, we don't).

> [***] I assert (well, at this point it's just "hope") that if 
> contributors use mgwport for the Contribution, both (2) and (2a) will be 
> easier for us (MinGW devs) to do -- and therefore will get quicker 
> response to the Contributor.

This remains to be seen, but I share your hope.

-- 
Regards,
Keith.