Re: "Move to Treated Inbox" and double-checking policy

Hi Tony,

Yes, I do think this discussion is good for the squeak-dev list. I hope
you don't mind, I am CCing the list for follow ups.


On Fri, Feb 09, 2018 at 05:58:24PM +0000, Tony Garnock-Jones wrote:
> Hi again David,
>
> So just now I thought I'd practice a bit by treating some old packages
> to get them out of the inbox. I managed to treat two, apparently
> successfully, but each time, when I clicked on the move-to-treated-inbox
> button, the web server never came back, eventually yielding 504 gateway
> timeout. The session appeared to be borked at that point, so I logged in
> fresh from the front page.

Yes, that is what I have been seeing also. I think that Eliot had suggested
that it was something to do with gathering diffs for the list when committing,
but it seems now that it is happening after any sort of update. I even
got a timeout after I set a temporary password for you, so it seems like
a thing that happens after any sort of respository change.

>
> No problems with squeaksource.com that I've noticed yet.
>

I am trying guess what the difference might be. The squeaksource.com
image is just doing an hourly image save, whereas the source.squeak.org
never saves its image, but instead is serializing the repository out to
a data.obj file (this based on my taking a quick look around the server
earlier today to try to find out what was going on).

I wonder if perhaps changes to the repository are triggering long-running
serialize to disk operations?

Best practices for these cases are not obvious, and we should probably
document them better.

>
> 1. Say I have what seems to me to be an uncontroversial change, but it's
> in the Kernel package, which seems a bit special. Should I:
>   A) put it in Inbox, and ask on the mailing list for a bit of review?
>   B) trust myself, stick it in Trunk, and deal with any fallout later?

Either way you should trust yourself :-)

If you think that other people are likely to comment, or to suggest
alternative approaches, then it is good to put it in the inbox first.
Give it a day or two for review and comment, then move from inbox
to trunk (using the web interface) if there no objections. I would
say that "no objections" is a good test, since you may grow old waiting
for positive acknowledgements sometimes ;-)

If you are happy with the change and do not expect much feedback, then
just go ahead and commit to trunk. That gets it done quickly with no
worries concerning branching. Once in a while you will make a mistake,
and that is not a problem. It is easy to back out a mistake, and we all
do it from time to time.

>
> 2. Say we're in the situation now with fn.1151 getting some pushback,
> but imagine that my tonyg.1151 is totally OK and the right thing to do
> is stick it in Trunk. Should I (or whoever does it):
>   A) Move It To Trunk with the special button?
>   B) Wait for the situation with fn.1151 to resolve itself, at which
>      point a merge of tonyg.1151 and fn.1151 will end up being committed
>      to Trunk as whoever.1152?
>   C) Something else??

Move it from inbox to trunk using the web interface, then do a merge if
needed and commit the merge to trunk. This preserves all original MCZ
files to avoid confusion, and the merging is an easy step to resolve
any conflicts.

In your example above, the fn.1151 can also be merged at a later time,
so your moving tonyg.1151 does not prevent fn.1151 from being adopted
also.

>
> I was thinking it seems like whenever there are multiple heads, there'll
> be some merge-related pain at some point, and I'm wondering when that
> pain is best dealt with.
>
>
> Tony

I was rather nervous about doing the merging too, but it turns out to be
painless.

Dave

Hi David,

On 02/09/2018 09:03 PM, David T. Lewis wrote:
> Yes, I do think this discussion is good for the squeak-dev list. I hope
> you don't mind, I am CCing the list for follow ups.

Thanks - perfect - and thank you for the responses to my questions. I'll
give it a try now.

Regards,
  Tony