<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Nicolas.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">I may try to answer a mail that is about 6 month old, but IMO, it does</span></div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> not make much sense.</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> This mail is not in my client anymore, so it means going thru some</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> forum API with extra login etc...</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> It's just not acceptable.</span><div class="mb_sig"></div>
                                        <div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">I find both ways manageable. It doesn't take too much time for me. Yet, I see the benefit of a platform with integrated tools such as GitHub.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">It should be possible to write a small tool (or extension to Monticello) to make a comment (via e-mail?) on an inbox version using the mailing list and the matching entry there.  No need to move all the data to a new platform where the tools are --- just add the missing tools. IMO the better cost-value ratio. ... Any takers? Christoph? :-D</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel </span></div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 13.04.2021 21:08:52 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Christoph,<br>yes, I saw that later,<br>but then decided that your first attempt was OK, some kind of<br>integrator privilege ;)<br>If someone has a strong opinion about it, we can change it again, but<br>IMO it's not worth it.<br><br>The problem with our dev model is that it's been designed with very<br>short cycles in mind.<br>Once the contributions are rotting for more than a month or two, it's<br>very inconvenient to retrieve the messages and discussion from the<br>mailing list, while reviewing the changes in the image. I personally<br>skip this step because the process is already too demanding.<br>Unlike pull/merge requests in github/gitlab, we have no way to let a<br>review process span multiple months, multiple commits, multiple steps<br>(understand separate steps for loading into a live image like we do<br>with MCM update maps), etc...<br>Answering a mail in a cold thread (2 month later or more) does not<br>make sense,see an example below...<br><br>We also have to use a 3rd tool for moving the package: the<br>source.squak.org web interface.<br>I can guarantee that I have to re-login at each package review (logins<br>are short lived).<br>The way our site URL works, it means that I have to retrieve the page<br>holding the exact version at each re-login.<br>If 1st package letter is > M, it can be 10 clicks away...<br>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, that's somehow discouraging, just put a picture of me and<br>Marcel faces here<br>https://en.wikipedia.org/wiki/Dana%C3%AFdes#/media/File:Danaides_by_John_William_Waterhouse,_1903.jpg<br>I'm generally satisfied with our lightweight model, except for the<br>review and integration of inbox contributions.<br><br>As example, yesterday, I wanted to reject<br>https://source.squeak.org/inbox/Kernel_ct.1366.diff<br>This is because (result := Compiler evaluate:... ifFail: [^nil]) is<br>not the same as your proposal:<br>there is a local return that exit the method in the former case, and<br>an assignment of result with nil in the later case.<br>I can see the diff on our site, but cannot add any annotation unlike<br>github/gitlab.<br>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>It's just not acceptable.<br>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.<br>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><br>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><br>Le mar. 13 avr. 2021 à 19:52, Christoph Thiede<br><christoph.thiede@student.hpi.uni-potsdam.de> a écrit :<br>><br>> Hi Nicolas,<br>><br>> actually, ST80-ct.255 should have been moved into the treated inbox in favor<br>> of ST80-ct.256 as discussed in the thread. Nevertheless, thanks for<br>> integrating all these patches! :-)<br>><br>> Best,<br>> Christoph<br>><br>><br>><br>> -----<br>> Carpe Squeak!<br>> --<br>> Sent from: http://forum.world.st/Squeak-Dev-f45488.html<br>><br><br></christoph.thiede@student.hpi.uni-potsdam.de></div></blockquote></div>