<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If 1st package letter is > M, it can be 10 clicks away...<br>
</blockquote><div><br></div><div>You can reduce it to 1 using the Search function.  Wildcards are accepted.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Plus the fact that I'm pretty sure that in the past, some packages<br>
that I previously moved to trunk or treated inbox did reappear in the<br>
inbox,</blockquote><div><br></div><div>I fixed that a while back.  If it isn't, someone please let me know.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I may try to answer a mail that is about 6 month old, but IMO, it does<br>
not make much sense.<br>
This mail is not in my client anymore, so it means going thru some<br>
forum API with extra login etc...<br></blockquote><div><br></div><div>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..</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's just not acceptable.<br></blockquote><div><br></div><div>Would you get your email fixed before deciding?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rejecting without a comment is not acceptable either.<br>
It's not fair for contributors, and not fair to ourselves: the reason<br>
why we reject is more important than the rejection itself: it is also<br>
information reusable for future contributions. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If we really want to stick to our lghtweight model, i suggest that we<br>
add one more commit message when we move some package to treated,<br>
possibly with an automated link to original commit message in some<br>
mailing list. This way, I will have a chance to give some additional<br>
reason for rejection...<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I stop the rant here. Above all, I don't want to restrain the will to<br>
contribute.<br>
Having enthusiastic users overwhelming the inbox with fixes, ideas and<br>
enhancements is not the problem, it's a chance!<br>
Having too few people to perform the review with poor tools is the<br>
problem. We have to do something about it.<br>
In my eyes, the reviews done in the mailing list a few month ago are<br>
dead, they are not easily findable/usable/amendable.<br>
Thanks for bringing the subject, and please, continue to chanllenge us!<br>
Ideas for improving the process are wecome too.<br></blockquote><div><br></div><div><div><div>I think the problem is that trying to treat trunk development with Monticello the same as you do development with Git.</div><div></div></div><div></div></div><div><br></div><div>> The problem with our dev model is that it's been designed with very<br></div><div>> short cycles in mind.<br></div><div><br></div><div>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..</div><div><br></div><div> - Chris</div></div></div>