Hi Chris.

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

Looks good. It was like 3-4 weeks ago, right? No issues so far. Yet, I keep on moving the duplicates from inbox to treated if I find some. :-) Should be over soon.

Best,
Marcel
Am 16.04.2021 03:55:25 schrieb Chris Muller <asqueaker at gmail.com>:
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/20210416/503d3e02/attachment.html>