Hi chris

I do not like the idea to get all the fix included directly in the 
image. Especially since we have not enough tests to make sure that we 
can identify easily simple problems. Then for your VM changes
I remember the story and I can tell you that I did not want to take the 
responsibility to introduce
some deep changes in the VM while I'm not expert there. So I think that 
the process works ok (I'm not saying that this should not change).  As 
a person sending a changes you have to a trust level or you should 
lobby. I think that the process is much smoother now than it was when 
we started KCP.

Stef


On 3 août 04, at 21:01, Chris Muller wrote:

>
> May I agitate this thread with intentions of good?
>
> In my personal experience, the actual submission of changes/fixes has 
> been
> difficult and laborious.  After the actual submission, some of them 
> further
> required continued hard lobbying/nagging/reminding, etc.  Even after 
> hours of
> work, many never made it.
>
> With such a high "cost" of getting a change, it really emphasizes what 
> Lex
> seems to be complaining about..  That the process does not support 
> small,
> simple, safe fixes.  What if someone merely wants to correct a class 
> or method
> comment?  There's no way that's worth going through the pain of the 
> current
> process, not only for the submitter but for the harvester, and that's 
> a shame
> because lots of "baby-step" improvements can contribute a lot to the 
> maturity
> of a system.
>
> What if we used an approach where, say, during the alpha phase, the 
> community
> *as a whole* had an opportunity to make and eat its own dog food.
>
>   - anyone can submit a change/fix that will make it to a 
> publicly-accessible
> update repository ("the update stream?")
>   - anyone can bring in these current public changes from others a la 
> "update"
> mode, i.e., they can see the change before they import it.  Also, 
> people will
> learn to save their image first..  :)
>   - We use a tool (BFAV?) that allows people to comment and possibly 
> even
> "vote" on each particular change.
>   - The same tool could be used to improve a particular change based 
> on others
> comments, of course.
>
> It's a different kind of pain, but it opens the door for a flood of 
> small fixes
> we could get in during alpha phase that would be unencumbered by the
> bureacracy.
>
> People will undoubtedly submit stuff that doesn't belong.  If that 
> happens, the
> community will vote "no" on it.  People will undoubtedly submit stuff 
> that
> breaks the image and, if so, people will attach feedback to it that 
> says,
> "beware, this hosed up my image.." so that others will be more wary of 
> it and,
> later, if not fixed, vote "no" on it.
>
> In the beta phase, once we *have them* all in there, it would again be 
> up to
> the community to vote and clean up.  Perhaps no more "new" changes 
> would be
> accepted other than improvements to the ones that were submitted 
> during alpha
> phase.
>
> To realize this, the tool would have to support all parts of this 
> process;
> submitting, commenting, voting, accepting, rejecting, etc.  The idea 
> is for the
> tool to be a central point of communication and management of
> changes/fixes/improvements for the community, by the community.
>
> This is a high-level suggestion; I realize there are a lot of "holes" 
> and
> technical challenges to implementing something like this.  Maybe BFAV 
> has us
> already half-way there..  But the premise is that the harvesting 
> process should
> be able to accomodate a *growing* community; so that as the community 
> grows, it
> is more capable of sustaining its own growth, rather than obliterating 
> three or
> four harvesters time and choking on the bottleneck in the process.
>
>  - Chris
>