>
> If 1st package letter is > M, it can be 10 clicks away...
>

You can reduce it to 1 using the Search function.  Wildcards are accepted.


> Plus the fact that I'm pretty sure that in the past, some packages
> that I previously moved to trunk or treated inbox did reappear in the
> inbox,


I fixed that a while back.  If it isn't, someone please let me know.

I may try to answer a mail that is about 6 month old, but IMO, it does
> not make much sense.
> This mail is not in my client anymore, so it means going thru some
> forum API with extra login etc...
>

Why isn't it in your client anymore?  Email is mission-critical, it sounds
like you've got your git set up better than your mail.  Mail is the
application optimized for having and organizing and archiving async
discussions.  Whether you want to ALSO have lengthy discussions in the SCM
tool or not, I don't think you'll be absolved from needing to participate
in the email discussions in any case.  So, it would seem like it just
introduces yet another place to have to look for and maintain..


> It's just not acceptable.
>

Would you get your email fixed before deciding?


> Rejecting without a comment is not acceptable either.
> It's not fair for contributors, and not fair to ourselves: the reason
> why we reject is more important than the rejection itself: it is also
> information reusable for future contributions.

If we really want to stick to our lghtweight model, i suggest that we
> add one more commit message when we move some package to treated,
> possibly with an automated link to original commit message in some
> mailing list. This way, I will have a chance to give some additional
> reason for rejection...
>

The submitter won't be notified.  I don't think that will provide the kind
of "flow" you're looking for.  There already aren't enough readers of the
Inbox submissions, NO ONE reads Treated.  It would just be creating objects
(Strings) that would never be consumed.


> I stop the rant here. Above all, I don't want to restrain the will to
> contribute.
> Having enthusiastic users overwhelming the inbox with fixes, ideas and
> enhancements is not the problem, it's a chance!
> Having too few people to perform the review with poor tools is the
> problem. We have to do something about it.
> In my eyes, the reviews done in the mailing list a few month ago are
> dead, they are not easily findable/usable/amendable.
> Thanks for bringing the subject, and please, continue to chanllenge us!
> Ideas for improving the process are wecome too.
>

I think the problem is that trying to treat trunk development with
Monticello the same as you do development with Git.

> The problem with our dev model is that it's been designed with very
> short cycles in mind.

Git's was.  Squeak+MC's wasn't, but we're forcing it to do that.  It isn't
surprising to me that using it this way isn't optimal.  IMO, MC trunk
commits were meant to be *tested and finished*, only after iterative
refinement in the Inbox.  It seems like little more than superficial
tooling could greatly streamline it..

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210415/f760abe7/attachment.html>