I think Marcus said it best that the main problem right now is that 
there has been a long time with the unstable stream getting updates and 
nothing moving to the stable stream just yet.  If things moved to the 
stable stream every week or few days, you could probably just follow 
the stable stream and be able to contribute bug reports reasonably.

I'm not sure that being able to replace updates in place was 
necessarily the main point of the unstable stream.  (I think the main 
point is just that it's quite unstable.)  But I think the policy that 
updating-in-place is allowed in the unstable stream, and not allowed in 
the stable stream, is reasonable.

Anyway, I've mostly just let the update stream loose so that various 
harvesters are adding their updates directly.  (I haven't had much time 
to contribute in the last couple weeks.)  Naturally the big changes of 
m17n have required quite a bit of time to settle down.  I'm basically 
waiting for word from somebody that the unstable stream feels 
reasonably stable enough to move everything to the stable stream... I 
think we should do this soon even if it's not super-stable.

- Doug


On Monday, October 4, 2004, at 07:54 PM, Samuel Tardieu wrote:

>>>>>> "Marcus" == Marcus Denker <denker at iam.unibe.ch> writes:
>
> Marcus> It makes no sense to treat the unstable update stream as a
> Marcus> stable update stream.  Not.
>
> As I understood it, the unstable update stream was a stream where
> errors may slip in because more people can put things into it but can
> be corrected by further updates easily as several people have write
> access to it (as is Debian unstable). I didn't understand from
> previous threads that it was a stream where things may change back in
> time, but I believe you if you say that I have overlooked them.
>
> Let's face the obvious consequence of this: it means that even
> aventurous people should not use the unstable update stream for a
> basis of their work, as they will have to reload their own workset in
> it every time it is desynched -- if only they notice it. Which means
> that the unstable version will not receive much testing with real
> applications being developed or deployed, which isn't good in my
> opinion as the probability that bugs slip in and don't get noticed
> until very late (if they do) are very high -- the work to stabilize
> the final product will be much more important and the result will
> probably be of a lower quality than a constantly tested unstable 
> branch.
>
>   Sam
> -- 
> Samuel Tardieu -- sam at rfc1149.net -- http://www.rfc1149.net/sam
>
>