update stream policy

ducasse ducasse at iam.unibe.ch
Sun Jan 18 13:14:04 UTC 2004


Hi andreas

I understand your feeling. That's why with envy we always made sure 
that everybody could publish and modify a package.
(ok we were a few persons at the same place).
My impression is that what we need is Monticello++ where we have real 
packages with dependencies and a
simple build mechanism (I want to load version 3.1 of balloon3d).
Because what is important if you have multiple maintainers is that we 
can rollback (because we can always
make a mistake, this happens to us just two days ago with the new 
traits implementation so we just rollbacked but this was easy as we 
have only one file but this is not really realistic) but we should know 
how stuff are related (version2.3 of this one works with 0.89 of that 
one).

Because if I propose a fix of package X this means:
	- I loaded it,
	- so I could just say publish my bug fix version for "maintainers to 
review"
	- the maintainer/s could be working on an older or more recent 
versions this would not be a problem
	as he could load the version related to the bug with all the context 
and prerequisites
	- There could be a group of maintainers. For example with our tools 
(now around 350 classes or more)
	we have one integrator, this is the guy that checks conflict and 
release new version when the tests are green.
        Still we can work distributed and in parallel.

When I see how we work with store (which is not that good), this would 
be really cool and efficient to have that for Squeak and we could share 
code and responsibility. This would be simple to have multiple people 
responsible of a packages (having the right to release new version). I 
discussed long time ago with avi and he has this long term goal. I know 
also that monticello is the way it is
because avi wanted to go slowly and be backwards compatible. But if we 
map category to package and we use the extra information contained in 
PackageInfo + add dependencies we get a good model (basically something 
similar to ginsu which
is not magic or super extra but just common sense).

We will arrive there now monticello uses new conventions override so we 
are getting slowly there,
dependencies are missing. we will need it anyway soon or later 
especially in presence of packages.
If we would let avi (modulo that he is willing) the freedom to have 
first class package in squeak (that would be mapped for
newbie as categories because the mapping is trivial) we would get 
something really good.

I promised to myself that if joseph succeeds to release his new baby 
(which is doing that) I will port it to squeak not for fun just because 
I need that. But I do not want to compete with monticello, still we 
need something to really work. Alex is also using monticello for his 
code but he share my wishes.


Stef




On 18 janv. 04, at 13:16, Andreas Raab wrote:

>> 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