update stream policy

Andreas Raab andreas.raab at gmx.de
Sun Jan 18 12:16:44 UTC 2004


> I would very much like to hear your opinions on this matter, in private
> if you prefer.

Okay since you asked:

It is fundementally wrong to forcefully exclude code in packages from the
community processes (e.g., "reduce the load" on harvesters). While I agree
that there is a resource problem the solution cannot be to exclude portions
of code from those processes by "putting it into packages". If anything, the
opposite is true - we need to include external packages in the community
processes, increase the number of people participating.

By removing portions of code from the community processes you only increase
the frustrations of people involved. Re-read the posts from Diego and Stef -
their "complaints" are not about that "code is in packages" but rather about
the inavailibility of the agreed-upon processes inside the community, about
the inability for people from the community to make changes. IOW, if you
have something like the new/initialize changes (or Babel, or socket rewrite,
or system notifications or any others) it is clear that some things have to
be changed regardless of a single maintainer's inclination or availability.
It's the frustration about the impossibility to make these changes in
external packages that upsets people. So if there's a change to make in
these areas you are requiring the people involved to invent entirely
different mechanisms for those community owned portions of code even though
we (should) have processes in place to deal with it.

Note that this is independent from the issue of "putting trust into
maintainers". The basic deal for community owned code is that there is some
sort of approval process involved by which the community decides whether or
not to accept a portion of work. For the "smaller bits and pieces" this is
in the form of a BFAV review, for the larger ones (say SM2, system
notification) in the form of design discussions, road maps and similar. But
some (small or large scale) approval is needed and the community reserves
the right and the ability to change community owned code if it wishes to.

One of the major current problems to make this work is the inability to
share responsibility for a maintainer. I have brought this example before
but here it is again: I would be more than happy to share the burden of
maintaining various of my packages with someone else. I would be more than
happy to have the community processes apply to it rather than having to wade
through all of the BFAV posts exclusively on my own. I am certain that
anyone who has ever considered maintaining a "reasonably sized" package
feels the same. But there is nothing right now that enables us to do that.
Bugs, fixes, enhancements have been [closed] because they "belong to package
XYZ", there is no community space to which maintainers can give other people
access rights, in short there isn't any community process for code in
packages whatsoever.

In short, this isn't about "packages vs. in-image". This is about enabling
the community to actually get work done once code is in packages. What we
see today is the mere beginning of a whole new set of frustrations because
of the impossibility for the community to do changes in community owned
code. Maintainers get frustrated because they cannot share their
responsibility. People submitting changes get frustrated because the
community processes don't apply to their changes. Unless you include
external packages in the community processes, unless you enable maintainers
to deal with the community processes in their packages, putting "more code
into packages" isn't going to work. Or could you imagine to be the sole
maintainer for an external package like "Morphic"?

Cheers,
  - Andreas




More information about the Squeak-dev mailing list