automatic clean-up of inbox

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

automatic clean-up of inbox

Nicolas Cellier
Hi all,
when I review some inbox contribution, I make an effort to move accepted to trunk and rejected to treated via web interface.
However, this is tedious, and I have the impression that some of the package that I moved did come back which is quite discouraging... Is it possible?

BTW, there is also a bug when you select last page in the list of versions, nothing happens when it is following the ellipsis "..." . When you are on last page, jumping to page 1 works. The >> also seems to send you on page 1...
This makes cleaning via web UI even more tedious if the package begins with a letter > $M...
I would prefer first two letters of package as a page label rather than 1 2 3 (31 Co Cr Gr Ke Ke Mo ...

In order to reduce the burden, I propose that the server automatically remove the inbox contributions that were copied to trunk: more exactly, at each commit/copy in trunk, the inbox shall be scanned for equal package and cleaned if exact match (GUID included). Does it sound an acceptable change?



Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

Nicolas Cellier


Le sam. 9 mai 2020 à 01:54, Nicolas Cellier <[hidden email]> a écrit :
Hi all,
when I review some inbox contribution, I make an effort to move accepted to trunk and rejected to treated via web interface.
However, this is tedious, and I have the impression that some of the package that I moved did come back which is quite discouraging... Is it possible?

An example is Graphics-ct.411.
I integrated that in trunk by moving the package thru web API (pretty sure i did that).
Then I saw it back in Inbox.
I can't delete, so I moved it to Treated Inbox via web API (pretty sure it's me who did that too).
Now I see a Graphics-ct.411 in inbox again...
That's annoying, because IMO we should have the inbox list as short as possible
(it's like having tons of pending merge requests).
Graphics-ct.411 has been treated and should not lie in inbox any longer.


BTW, there is also a bug when you select last page in the list of versions, nothing happens when it is following the ellipsis "..." . When you are on last page, jumping to page 1 works. The >> also seems to send you on page 1...
This makes cleaning via web UI even more tedious if the package begins with a letter > $M...
I would prefer first two letters of package as a page label rather than 1 2 3 (31 Co Cr Gr Ke Ke Mo ...

In order to reduce the burden, I propose that the server automatically remove the inbox contributions that were copied to trunk: more exactly, at each commit/copy in trunk, the inbox shall be scanned for equal package and cleaned if exact match (GUID included). Does it sound an acceptable change?



Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

David T. Lewis
On Sat, May 09, 2020 at 11:53:25AM +0200, Nicolas Cellier wrote:

> Le sam. 9 mai 2020 ?? 01:54, Nicolas Cellier <
> [hidden email]> a ??crit :
>
> > Hi all,
> > when I review some inbox contribution, I make an effort to move accepted
> > to trunk and rejected to treated via web interface.
> > However, this is tedious, and I have the impression that some of the
> > package that I moved did come back which is quite discouraging... Is it
> > possible?
> >
>
> An example is Graphics-ct.411.
> I integrated that in trunk by moving the package thru web API (pretty sure
> i did that).
> Then I saw it back in Inbox.
> I can't delete, so I moved it to Treated Inbox via web API (pretty sure
> it's me who did that too).
> Now I see a Graphics-ct.411 in inbox again...
> That's annoying, because IMO we should have the inbox list as short as
> possible
> (it's like having tons of pending merge requests).
> Graphics-ct.411 has been treated and should not lie in inbox any longer.
>

I just moved 11 of my inbox packages to the treated inbox using the web
interface. The web interface locked up and timed out each time, requiring
me to log back in to a new session each time it did this.

The actual packages did get moved, and no longer appear in inbox. I'll
check back later to see if they are still gone.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

Nicolas Cellier


Le sam. 9 mai 2020 à 17:52, David T. Lewis <[hidden email]> a écrit :
On Sat, May 09, 2020 at 11:53:25AM +0200, Nicolas Cellier wrote:
> Le sam. 9 mai 2020 ?? 01:54, Nicolas Cellier <
> [hidden email]> a ??crit :
>
> > Hi all,
> > when I review some inbox contribution, I make an effort to move accepted
> > to trunk and rejected to treated via web interface.
> > However, this is tedious, and I have the impression that some of the
> > package that I moved did come back which is quite discouraging... Is it
> > possible?
> >
>
> An example is Graphics-ct.411.
> I integrated that in trunk by moving the package thru web API (pretty sure
> i did that).
> Then I saw it back in Inbox.
> I can't delete, so I moved it to Treated Inbox via web API (pretty sure
> it's me who did that too).
> Now I see a Graphics-ct.411 in inbox again...
> That's annoying, because IMO we should have the inbox list as short as
> possible
> (it's like having tons of pending merge requests).
> Graphics-ct.411 has been treated and should not lie in inbox any longer.
>

I just moved 11 of my inbox packages to the treated inbox using the web
interface. The web interface locked up and timed out each time, requiring
me to log back in to a new session each time it did this.

Yes, I experienced similar problems, it's not a pleasure...
Except yesterday, I was able to move 3 packages in a row
(well, I mean without relogging, not without waiting...)

The actual packages did get moved, and no longer appear in inbox. I'll
check back later to see if they are still gone.

Dave




Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

Chris Muller-3
Okay, I went ahead and applied the one-line patch directly in the
production server.  The Move function should be fast now.  I don't
have time to build and deploy a new image right now.  Anyone is
welcome to do that if they wish.  Fix is currently in
andreas:/srv/sourcesqueakorg/box4/squeaksource/webserver/patch.st,
I'll make a commit to /ss when I can get around to it..

 - Chris


On Sat, May 9, 2020 at 11:34 AM Nicolas Cellier
<[hidden email]> wrote:


>
>
>
> Le sam. 9 mai 2020 à 17:52, David T. Lewis <[hidden email]> a écrit :
>>
>> On Sat, May 09, 2020 at 11:53:25AM +0200, Nicolas Cellier wrote:
>> > Le sam. 9 mai 2020 ?? 01:54, Nicolas Cellier <
>> > [hidden email]> a ??crit :
>> >
>> > > Hi all,
>> > > when I review some inbox contribution, I make an effort to move accepted
>> > > to trunk and rejected to treated via web interface.
>> > > However, this is tedious, and I have the impression that some of the
>> > > package that I moved did come back which is quite discouraging... Is it
>> > > possible?
>> > >
>> >
>> > An example is Graphics-ct.411.
>> > I integrated that in trunk by moving the package thru web API (pretty sure
>> > i did that).
>> > Then I saw it back in Inbox.
>> > I can't delete, so I moved it to Treated Inbox via web API (pretty sure
>> > it's me who did that too).
>> > Now I see a Graphics-ct.411 in inbox again...
>> > That's annoying, because IMO we should have the inbox list as short as
>> > possible
>> > (it's like having tons of pending merge requests).
>> > Graphics-ct.411 has been treated and should not lie in inbox any longer.
>> >
>>
>> I just moved 11 of my inbox packages to the treated inbox using the web
>> interface. The web interface locked up and timed out each time, requiring
>> me to log back in to a new session each time it did this.
>>
> Yes, I experienced similar problems, it's not a pleasure...
> Except yesterday, I was able to move 3 packages in a row
> (well, I mean without relogging, not without waiting...)
>
>> The actual packages did get moved, and no longer appear in inbox. I'll
>> check back later to see if they are still gone.
>>
>> Dave
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

David T. Lewis
Thanks Chris,

I am willing to do the update, but I want to confirm the procedure
before I touch anything.

My assumptions:

The image to be updated is /srv/sourcesqueakorg/box4/squeaksource/webserver/ss.image,
and a backup copy of the current ss.image/changes should be saved.

The image can be updated off line by copying to my local system, applying
the patch, and copying back to the server.

Restarting the source.squeak.org image will restart it using the updated ss.image.

Clean shutdown should be done with sudo svc -d /service/squeaksource.

Startup is done with sudo svc -u /service/squeaksource.

The supervise script will restart the image, starting with ss.image and
loading everything back from the Magma backing store.

If anything goes wrong with the above steps, I can restore the saved
ss.image, restart it, and all would be well.

Does that sound right? If so I will plan to do the update tomorrow.

With your permission, I will also apply an update to MonticelloConfigurations
to enable versioning of MCM maps.

Also, if there is a VNC connection available for either the image or
for the dan.box.squeak.org server, I would feel more comfortable if you
can tell me how to open that connection.

Thanks,
Dave


On Sat, May 09, 2020 at 06:27:19PM -0500, Chris Muller wrote:

> Okay, I went ahead and applied the one-line patch directly in the
> production server.  The Move function should be fast now.  I don't
> have time to build and deploy a new image right now.  Anyone is
> welcome to do that if they wish.  Fix is currently in
> andreas:/srv/sourcesqueakorg/box4/squeaksource/webserver/patch.st,
> I'll make a commit to /ss when I can get around to it..
>
>  - Chris
>
>
> On Sat, May 9, 2020 at 11:34 AM Nicolas Cellier
> <[hidden email]> wrote:
>
>
> >
> >
> >
> > Le sam. 9 mai 2020 ?? 17:52, David T. Lewis <[hidden email]> a ??crit :
> >>
> >> On Sat, May 09, 2020 at 11:53:25AM +0200, Nicolas Cellier wrote:
> >> > Le sam. 9 mai 2020 ?? 01:54, Nicolas Cellier <
> >> > [hidden email]> a ??crit :
> >> >
> >> > > Hi all,
> >> > > when I review some inbox contribution, I make an effort to move accepted
> >> > > to trunk and rejected to treated via web interface.
> >> > > However, this is tedious, and I have the impression that some of the
> >> > > package that I moved did come back which is quite discouraging... Is it
> >> > > possible?
> >> > >
> >> >
> >> > An example is Graphics-ct.411.
> >> > I integrated that in trunk by moving the package thru web API (pretty sure
> >> > i did that).
> >> > Then I saw it back in Inbox.
> >> > I can't delete, so I moved it to Treated Inbox via web API (pretty sure
> >> > it's me who did that too).
> >> > Now I see a Graphics-ct.411 in inbox again...
> >> > That's annoying, because IMO we should have the inbox list as short as
> >> > possible
> >> > (it's like having tons of pending merge requests).
> >> > Graphics-ct.411 has been treated and should not lie in inbox any longer.
> >> >
> >>
> >> I just moved 11 of my inbox packages to the treated inbox using the web
> >> interface. The web interface locked up and timed out each time, requiring
> >> me to log back in to a new session each time it did this.
> >>
> > Yes, I experienced similar problems, it's not a pleasure...
> > Except yesterday, I was able to move 3 packages in a row
> > (well, I mean without relogging, not without waiting...)
> >
> >> The actual packages did get moved, and no longer appear in inbox. I'll
> >> check back later to see if they are still gone.
> >>
> >> Dave
> >>
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

David T. Lewis
Hi Chris,

I have prepared an updated image, and staged it on the server. There
are two new files on the server:

  /srv/sourcesqueakorg/box4/squeaksource/webserver/ss.updated.dtl.tgz

  /srv/sourcesqueakorg/box4/squeaksource/webserver/SqueakSource-dtl.1128.mcz

The tgz file can be unpacked to replace the current ss.image (back up
first, and check ownership and permissions after unpacking).

The mcz contains your patch.st, relative to SqueakSource-tpr.1127. If
you can add me as developer on the ss repository, I'll copy it to the
repository.

The new image also contains the following updates:

  MonticelloConfigurations-dtl.161
  TinyWiki-tpr.12
  SqueakSource-tpr.1127 (predecessor to SqueakSource-dtl.1128)

I'll also copy the MonticelloConfigurations update to the ss respository.

Assuming that my notes below are right, I can complete the server update
if you like. But I will not do anything further without your approval.

Thanks,

Dave


On Sat, May 09, 2020 at 08:43:52PM -0400, David T. Lewis wrote:

> Thanks Chris,
>
> I am willing to do the update, but I want to confirm the procedure
> before I touch anything.
>
> My assumptions:
>
> The image to be updated is /srv/sourcesqueakorg/box4/squeaksource/webserver/ss.image,
> and a backup copy of the current ss.image/changes should be saved.
>
> The image can be updated off line by copying to my local system, applying
> the patch, and copying back to the server.
>
> Restarting the source.squeak.org image will restart it using the updated ss.image.
>
> Clean shutdown should be done with sudo svc -d /service/squeaksource.
>
> Startup is done with sudo svc -u /service/squeaksource.
>
> The supervise script will restart the image, starting with ss.image and
> loading everything back from the Magma backing store.
>
> If anything goes wrong with the above steps, I can restore the saved
> ss.image, restart it, and all would be well.
>
> Does that sound right? If so I will plan to do the update tomorrow.
>
> With your permission, I will also apply an update to MonticelloConfigurations
> to enable versioning of MCM maps.
>
> Also, if there is a VNC connection available for either the image or
> for the dan.box.squeak.org server, I would feel more comfortable if you
> can tell me how to open that connection.
>
> Thanks,
> Dave
>
>
> On Sat, May 09, 2020 at 06:27:19PM -0500, Chris Muller wrote:
> > Okay, I went ahead and applied the one-line patch directly in the
> > production server.  The Move function should be fast now.  I don't
> > have time to build and deploy a new image right now.  Anyone is
> > welcome to do that if they wish.  Fix is currently in
> > andreas:/srv/sourcesqueakorg/box4/squeaksource/webserver/patch.st,
> > I'll make a commit to /ss when I can get around to it..
> >
> >  - Chris
> >
> >
> > On Sat, May 9, 2020 at 11:34 AM Nicolas Cellier
> > <[hidden email]> wrote:
> >
> >
> > >
> > >
> > >
> > > Le sam. 9 mai 2020 ?? 17:52, David T. Lewis <[hidden email]> a ??crit :
> > >>
> > >> On Sat, May 09, 2020 at 11:53:25AM +0200, Nicolas Cellier wrote:
> > >> > Le sam. 9 mai 2020 ?? 01:54, Nicolas Cellier <
> > >> > [hidden email]> a ??crit :
> > >> >
> > >> > > Hi all,
> > >> > > when I review some inbox contribution, I make an effort to move accepted
> > >> > > to trunk and rejected to treated via web interface.
> > >> > > However, this is tedious, and I have the impression that some of the
> > >> > > package that I moved did come back which is quite discouraging... Is it
> > >> > > possible?
> > >> > >
> > >> >
> > >> > An example is Graphics-ct.411.
> > >> > I integrated that in trunk by moving the package thru web API (pretty sure
> > >> > i did that).
> > >> > Then I saw it back in Inbox.
> > >> > I can't delete, so I moved it to Treated Inbox via web API (pretty sure
> > >> > it's me who did that too).
> > >> > Now I see a Graphics-ct.411 in inbox again...
> > >> > That's annoying, because IMO we should have the inbox list as short as
> > >> > possible
> > >> > (it's like having tons of pending merge requests).
> > >> > Graphics-ct.411 has been treated and should not lie in inbox any longer.
> > >> >
> > >>
> > >> I just moved 11 of my inbox packages to the treated inbox using the web
> > >> interface. The web interface locked up and timed out each time, requiring
> > >> me to log back in to a new session each time it did this.
> > >>
> > > Yes, I experienced similar problems, it's not a pleasure...
> > > Except yesterday, I was able to move 3 packages in a row
> > > (well, I mean without relogging, not without waiting...)
> > >
> > >> The actual packages did get moved, and no longer appear in inbox. I'll
> > >> check back later to see if they are still gone.
> > >>
> > >> Dave
> > >>
> > >>
> > >
> >

Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

Chris Muller-4
In reply to this post by David T. Lewis
Hi Dave,

> I am willing to do the update, but I want to confirm the procedure
> before I touch anything.

Thanks!

> My assumptions:
>
> The image to be updated is /srv/sourcesqueakorg/box4/squeaksource/webserver/ss.image,
> and a backup copy of the current ss.image/changes should be saved.

Yes.  The image is saved with nothing running, just the code base
installed.  The server is started via .st script.

> The image can be updated off line by copying to my local system, applying
> the patch, and copying back to the server.

Yes.  If you want to get your MCConfigurations enhancement in, it will
need to be able to run in Squeak 5.2 for now.

> Restarting the source.squeak.org image will restart it using the updated ss.image.
>
> Clean shutdown should be done with sudo svc -d /service/squeaksource.
>
> Startup is done with sudo svc -u /service/squeaksource.

Yup.

> The supervise script will restart the image, starting with ss.image and
> loading everything back from the Magma backing store.

Yes.

> If anything goes wrong with the above steps, I can restore the saved
> ss.image, restart it, and all would be well.

Yes, and I'm sure imply that you would do svc -d during that so
doesn't keep trying to restart it in uncontrolled fashion while you're
switching the image back.

> Does that sound right? If so I will plan to do the update tomorrow.
>
> With your permission, I will also apply an update to MonticelloConfigurations
> to enable versioning of MCM maps.

Sure, thanks.  As long as you're willing to support it if there's a
problem, go for it.  :)   It sounds like you definitely have a good
handle on the system, so I'm confident.

> Also, if there is a VNC connection available for either the image or
> for the dan.box.squeak.org server, I would feel more comfortable if you
> can tell me how to open that connection.

I'll send these details in a separate email.

Thanks, glad to have a backup for source.squeak.org.

 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: automatic clean-up of inbox

David T. Lewis
Thank you Chris :-)

I will follow up on this later today.

Dave

On Sun, May 10, 2020 at 05:17:02PM -0500, Chris Muller wrote:

> Hi Dave,
>
> > I am willing to do the update, but I want to confirm the procedure
> > before I touch anything.
>
> Thanks!
>
> > My assumptions:
> >
> > The image to be updated is /srv/sourcesqueakorg/box4/squeaksource/webserver/ss.image,
> > and a backup copy of the current ss.image/changes should be saved.
>
> Yes.  The image is saved with nothing running, just the code base
> installed.  The server is started via .st script.
>
> > The image can be updated off line by copying to my local system, applying
> > the patch, and copying back to the server.
>
> Yes.  If you want to get your MCConfigurations enhancement in, it will
> need to be able to run in Squeak 5.2 for now.
>
> > Restarting the source.squeak.org image will restart it using the updated ss.image.
> >
> > Clean shutdown should be done with sudo svc -d /service/squeaksource.
> >
> > Startup is done with sudo svc -u /service/squeaksource.
>
> Yup.
>
> > The supervise script will restart the image, starting with ss.image and
> > loading everything back from the Magma backing store.
>
> Yes.
>
> > If anything goes wrong with the above steps, I can restore the saved
> > ss.image, restart it, and all would be well.
>
> Yes, and I'm sure imply that you would do svc -d during that so
> doesn't keep trying to restart it in uncontrolled fashion while you're
> switching the image back.
>
> > Does that sound right? If so I will plan to do the update tomorrow.
> >
> > With your permission, I will also apply an update to MonticelloConfigurations
> > to enable versioning of MCM maps.
>
> Sure, thanks.  As long as you're willing to support it if there's a
> problem, go for it.  :)   It sounds like you definitely have a good
> handle on the system, so I'm confident.
>
> > Also, if there is a VNC connection available for either the image or
> > for the dan.box.squeak.org server, I would feel more comfortable if you
> > can tell me how to open that connection.
>
> I'll send these details in a separate email.
>
> Thanks, glad to have a backup for source.squeak.org.
>
>  - Chris
>