Hi Nicolas.

> 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...
> It's just not acceptable.

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.

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

Best,
Marcel 
Am 13.04.2021 21:08:52 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
Hi Christoph,
yes, I saw that later,
but then decided that your first attempt was OK, some kind of
integrator privilege ;)
If someone has a strong opinion about it, we can change it again, but
IMO it's not worth it.

The problem with our dev model is that it's been designed with very
short cycles in mind.
Once the contributions are rotting for more than a month or two, it's
very inconvenient to retrieve the messages and discussion from the
mailing list, while reviewing the changes in the image. I personally
skip this step because the process is already too demanding.
Unlike pull/merge requests in github/gitlab, we have no way to let a
review process span multiple months, multiple commits, multiple steps
(understand separate steps for loading into a live image like we do
with MCM update maps), etc...
Answering a mail in a cold thread (2 month later or more) does not
make sense,see an example below...

We also have to use a 3rd tool for moving the package: the
source.squak.org web interface.
I can guarantee that I have to re-login at each package review (logins
are short lived).
The way our site URL works, it means that I have to retrieve the page
holding the exact version at each re-login.
If 1st package letter is > M, it can be 10 clicks away...
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, that's somehow discouraging, just put a picture of me and
Marcel faces here
https://en.wikipedia.org/wiki/Dana%C3%AFdes#/media/File:Danaides_by_John_William_Waterhouse,_1903.jpg
I'm generally satisfied with our lightweight model, except for the
review and integration of inbox contributions.

As example, yesterday, I wanted to reject
https://source.squeak.org/inbox/Kernel_ct.1366.diff
This is because (result := Compiler evaluate:... ifFail: [^nil]) is
not the same as your proposal:
there is a local return that exit the method in the former case, and
an assignment of result with nil in the later case.
I can see the diff on our site, but cannot add any annotation unlike
github/gitlab.
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...
It's just not acceptable.
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...

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.

Le mar. 13 avr. 2021 à 19:52, Christoph Thiede
a écrit :
>
> Hi Nicolas,
>
> actually, ST80-ct.255 should have been moved into the treated inbox in favor
> of ST80-ct.256 as discussed in the thread. Nevertheless, thanks for
> integrating all these patches! :-)
>
> Best,
> Christoph
>
>
>
> -----
> Carpe Squeak!
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210414/2d09acc4/attachment.html>