Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Inbox

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Bert Freudenberg

[squeak-dev] Inbox

I just merged a Monticello fix from the inbox (thanks Bernhard!) to
the trunk. Now that this package is dealt with, what do we do? Perhaps
we need an "inbox-merged" repository where we can move these packages?
Or possibly two repositories for accepted and rejected packages? Can
all developers move versions between repositories, or only admins?

- Bert -

Ken Causey-3

Re: [squeak-dev] Inbox

On Wed, 2009-08-12 at 14:49 +0200, Bert Freudenberg wrote:
> I just merged a Monticello fix from the inbox (thanks Bernhard!) to
> the trunk. Now that this package is dealt with, what do we do? Perhaps
> we need an "inbox-merged" repository where we can move these packages?
> Or possibly two repositories for accepted and rejected packages? Can
> all developers move versions between repositories, or only admins?
>
> - Bert -

I have to say I've wondered about this myself.

Regarding 'who' moves them: I assume you are asking about policy rather
than technical capability. Unless you are doing this some way I'm not
aware of anyone who has write capability can do it. In terms of policy
I would be comfortable mapping it to capability, which is to say that
all core-devs can move packages from inbox to trunk.

That said, you bring up a good point regarding tracking what has been
done. As it stands you have to see what is in inbox and then look at
the listing in trunk to see if that file is in the listing there. Of
course that ignores the possibility that it's not actually in the
ancestry of the current latest version and is ultimately overlooked that
way. It would also be useful to provide some easy feedback for those
submitting issues to the inbox indicating when their submission has been
accepted. Perhaps it's time for our own SqueakSource branch.

Ken

signature.asc (196 bytes) Download Attachment

keith1y

Re: [squeak-dev] Inbox

Ken Causey wrote:

> On Wed, 2009-08-12 at 14:49 +0200, Bert Freudenberg wrote:
>
>> I just merged a Monticello fix from the inbox (thanks Bernhard!) to
>> the trunk. Now that this package is dealt with, what do we do? Perhaps
>> we need an "inbox-merged" repository where we can move these packages?
>> Or possibly two repositories for accepted and rejected packages? Can
>> all developers move versions between repositories, or only admins?
>>
>> - Bert -
>>
>
> I have to say I've wondered about this myself.
>
> Regarding 'who' moves them: I assume you are asking about policy rather
> than technical capability. Unless you are doing this some way I'm not
> aware of anyone who has write capability can do it. In terms of policy
> I would be comfortable mapping it to capability, which is to say that
> all core-devs can move packages from inbox to trunk.
>
> That said, you bring up a good point regarding tracking what has been
> done. As it stands you have to see what is in inbox and then look at
> the listing in trunk to see if that file is in the listing there. Of
> course that ignores the possibility that it's not actually in the
> ancestry of the current latest version and is ultimately overlooked that
> way. It would also be useful to provide some easy feedback for those
> submitting issues to the inbox indicating when their submission has been
> accepted. Perhaps it's time for our own SqueakSource branch.
>
> Ken
>

So it turns out that this "new process" of yours isn't a process at all,
you are making it up as you go along.

So on the one hand you tell me that my process is not understood by the
community so lets replace it with a process that no one understands
because there isn't one.

Keith

Andreas.Raab

[squeak-dev] Re: Inbox

In reply to this post by Ken Causey-3

Good questions. How do the Pharo people deal with these issues? Anybody
know?

Cheers,
- Andreas

Ken Causey wrote:

> On Wed, 2009-08-12 at 14:49 +0200, Bert Freudenberg wrote:
>> I just merged a Monticello fix from the inbox (thanks Bernhard!) to
>> the trunk. Now that this package is dealt with, what do we do? Perhaps
>> we need an "inbox-merged" repository where we can move these packages?
>> Or possibly two repositories for accepted and rejected packages? Can
>> all developers move versions between repositories, or only admins?
>>
>> - Bert -
>
> I have to say I've wondered about this myself.
>
> Regarding 'who' moves them: I assume you are asking about policy rather
> than technical capability. Unless you are doing this some way I'm not
> aware of anyone who has write capability can do it. In terms of policy
> I would be comfortable mapping it to capability, which is to say that
> all core-devs can move packages from inbox to trunk.
>
> That said, you bring up a good point regarding tracking what has been
> done. As it stands you have to see what is in inbox and then look at
> the listing in trunk to see if that file is in the listing there. Of
> course that ignores the possibility that it's not actually in the
> ancestry of the current latest version and is ultimately overlooked that
> way. It would also be useful to provide some easy feedback for those
> submitting issues to the inbox indicating when their submission has been
> accepted. Perhaps it's time for our own SqueakSource branch.
>
> Ken
>
>
> ------------------------------------------------------------------------
>
>

SergeStinckwich

[squeak-dev] Re: Inbox

Andreas Raab a écrit :
> Good questions. How do the Pharo people deal with these issues? Anybody
> know?

You can read :
http://code.google.com/p/pharo/wiki/IntegrationProcessDescription
http://code.google.com/p/pharo/wiki/HowToContribute

Cheers,

--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Smalltalkers do: [:it | All with: Class, (And love: it)]
http://doesnotunderstand.org/

Andreas.Raab

[squeak-dev] Re: Inbox

Serge Stinckwich wrote:
> Andreas Raab a écrit :
>> Good questions. How do the Pharo people deal with these issues?
>> Anybody know?
>
> You can read :
> http://code.google.com/p/pharo/wiki/IntegrationProcessDescription
> http://code.google.com/p/pharo/wiki/HowToContribute

Thanks. This sounds very reasonable. It means we'd need a "Treated"
repository that we can move the integrated packages to. Ken, could you
set this up?

One thing I'm not sure is if every developer is allowed to move packages
or only the project admins. If it's only the project admins we might
consider making all developers admin for the inbox to simplify the process.

Cheers,
- Andreas

johnmci

Re: [squeak-dev] Re: Inbox

Since we are talking about repositories for incoming code can we
consider the process for outgoing VMs?
I think right now if you visit squeak.org and download squeak for any
platform you appear to get something perhaps years old.
It also seems all the links to the latest VMs for any platform which
are needed for the closure based images are found anywhere but
squeak.org

Would it be possible for someone in charge to enable the ability for
folks to download Squeak and get at least the current VMs for all
platforms?

Hint: The warranty on Squeak 3.8.18beta1U.app which squeak.org ships
has expired...

On 12-Aug-09, at 8:20 PM, Andreas Raab wrote:

> Serge Stinckwich wrote:
>> Andreas Raab a écrit :
>>> Good questions. How do the Pharo people deal with these issues?
>>> Anybody know?
>> You can read : http://code.google.com/p/pharo/wiki/IntegrationProcessDescription
>> http://code.google.com/p/pharo/wiki/HowToContribute
>
> Thanks. This sounds very reasonable. It means we'd need a "Treated"
> repository that we can move the integrated packages to. Ken, could
> you set this up?
>
> One thing I'm not sure is if every developer is allowed to move
> packages or only the project admins. If it's only the project admins
> we might consider making all developers admin for the inbox to
> simplify the process.
>
> Cheers,
> - Andreas
>

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

Andreas.Raab

[squeak-dev] Re: Inbox

Hi John -

Sounds good, but I'm not sure what exactly you are proposing. Are you
thinking about the VM download links on www.squeak.org? In this case we
should talk to the web team which maintains the web site. Or do you mean
to update the 3.10.2 release to ship with more modern VMs? In this case
we should ask Edgar if he can help us with that. Or both? Or something
entirely different?

Cheers,
- Andreas

John M McIntosh wrote:

> Since we are talking about repositories for incoming code can we
> consider the process for outgoing VMs?
> I think right now if you visit squeak.org and download squeak for any
> platform you appear to get something perhaps years old.
> It also seems all the links to the latest VMs for any platform which are
> needed for the closure based images are found anywhere but squeak.org
>
> Would it be possible for someone in charge to enable the ability for
> folks to download Squeak and get at least the current VMs for all
> platforms?
>
> Hint: The warranty on Squeak 3.8.18beta1U.app which squeak.org ships has
> expired...
>
> On 12-Aug-09, at 8:20 PM, Andreas Raab wrote:
>
>> Serge Stinckwich wrote:
>>> Andreas Raab a écrit :
>>>> Good questions. How do the Pharo people deal with these issues?
>>>> Anybody know?
>>> You can read :
>>> http://code.google.com/p/pharo/wiki/IntegrationProcessDescription
>>> http://code.google.com/p/pharo/wiki/HowToContribute
>>
>> Thanks. This sounds very reasonable. It means we'd need a "Treated"
>> repository that we can move the integrated packages to. Ken, could you
>> set this up?
>>
>> One thing I'm not sure is if every developer is allowed to move
>> packages or only the project admins. If it's only the project admins
>> we might consider making all developers admin for the inbox to
>> simplify the process.
>>
>> Cheers,
>> - Andreas
>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]> Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
>

SergeStinckwich

[squeak-dev] Re: Inbox

In reply to this post by Andreas.Raab

johnmci

[squeak-dev] Re: Inbox

In reply to this post by Andreas.Raab

On 12-Aug-09, at 9:05 PM, Andreas Raab wrote:

> Hi John -
>
> Sounds good, but I'm not sure what exactly you are proposing. Are
> you thinking about the VM download links on www.squeak.org? In this
> case we should talk to the web team which maintains the web site. Or
> do you mean to update the 3.10.2 release to ship with more modern
> VMs? In this case we should ask Edgar if he can help us with that.
> Or both? Or something entirely different?
>
> Cheers,
> - Andreas

All of the above, it's also the process of feeding the VMs from the
folks that build them to
squeak.org for distribution.

Just check squeak.org and see what you get if you download squeak

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

Bert Freudenberg

Re: [squeak-dev] Inbox

In reply to this post by Ken Causey-3

On 12.08.2009, at 16:47, Ken Causey wrote:

AFAICT only project admins can delete or move versions.

> In terms of policy
> I would be comfortable mapping it to capability, which is to say that
> all core-devs can move packages from inbox to trunk.

Right. I'd add a "devs can move" flag to SSAccessPolicy to allow
developers to move versions out of a repository that has this flag
enabled. Unless Adrian thinks that's a dumb idea ;)

Then I'd enable it for the inbox. So packages could be moved out of
it, but not out of the trunk, which I'd find safer.

Packages should be moved from the inbox only to the "treated" repo,
rather than directly into the trunk, IMHO. This is so it's clear in
the trunk repo which core developer uploaded a version. Possibly this
should be enforced by having two flags instead of one (devCanMoveIn
and devCanMoveOut).

- Bert -

> That said, you bring up a good point regarding tracking what has been
> done. As it stands you have to see what is in inbox and then look at
> the listing in trunk to see if that file is in the listing there. Of
> course that ignores the possibility that it's not actually in the
> ancestry of the current latest version and is ultimately overlooked
> that
> way. It would also be useful to provide some easy feedback for those
> submitting issues to the inbox indicating when their submission has
> been
> accepted. Perhaps it's time for our own SqueakSource branch.
>
> Ken
>

Ken Causey-3

Re: [squeak-dev] Re: Inbox

In reply to this post by Andreas.Raab

I've added the Treated project.

It turns out you were right that although the menu offers the choice to
move a version, only one with admin rights could do so. I chose to
change this, so now for the entire site anyone with write access to a
project has the write to move a version from the project to another
project.

A long range todo project would be to expose an interface to adjust
fine-grained access capabilities on a per project basis for SS.

Ken

P.S. I have to say I did not find the discussion of the Treated inbox on
the Pharo page at all clear. It sounds to me like it says that an issue
goes from the inbox into treated whether or not it is considered valid.
It then goes on to say that if it works it is 'published' to the Pharo
project. Am I to take this to mean that it is either moved out of
Treated or deleted? Also frankly, I don't understand what the word
'treated' means in this context.

On Wed, 2009-08-12 at 20:20 -0700, Andreas Raab wrote:

> Serge Stinckwich wrote:
> > Andreas Raab a écrit :
> >> Good questions. How do the Pharo people deal with these issues?
> >> Anybody know?
> >
> > You can read :
> > http://code.google.com/p/pharo/wiki/IntegrationProcessDescription
> > http://code.google.com/p/pharo/wiki/HowToContribute
>
> Thanks. This sounds very reasonable. It means we'd need a "Treated"
> repository that we can move the integrated packages to. Ken, could you
> set this up?
>
> One thing I'm not sure is if every developer is allowed to move packages
> or only the project admins. If it's only the project admins we might
> consider making all developers admin for the inbox to simplify the process.
>
> Cheers,
> - Andreas
>
>

signature.asc (196 bytes) Download Attachment

Ken Causey-3

Re: [squeak-dev] Inbox

In reply to this post by Bert Freudenberg

It seems like we need to coordinate a bit more closely as we have now
somewhat duplicated ourselves here (see separate email in this thread),
although my solution was much more simplistic. Bert would you care to
take over maintenance of source.squeak.org? I'm sure you are far more
familiar with the SS codebase than I.

Ken

On Thu, 2009-08-13 at 18:50 +0200, Bert Freudenberg wrote:

> On 12.08.2009, at 16:47, Ken Causey wrote:
>
> > On Wed, 2009-08-12 at 14:49 +0200, Bert Freudenberg wrote:
> >> I just merged a Monticello fix from the inbox (thanks Bernhard!) to
> >> the trunk. Now that this package is dealt with, what do we do?
> >> Perhaps
> >> we need an "inbox-merged" repository where we can move these
> >> packages?
> >> Or possibly two repositories for accepted and rejected packages? Can
> >> all developers move versions between repositories, or only admins?
> >>
> >> - Bert -
> >
> > I have to say I've wondered about this myself.
> >
> > Regarding 'who' moves them: I assume you are asking about policy
> > rather
> > than technical capability. Unless you are doing this some way I'm not
> > aware of anyone who has write capability can do it.
>
> AFAICT only project admins can delete or move versions.
>
> > In terms of policy
> > I would be comfortable mapping it to capability, which is to say that
> > all core-devs can move packages from inbox to trunk.
>
> Right. I'd add a "devs can move" flag to SSAccessPolicy to allow
> developers to move versions out of a repository that has this flag
> enabled. Unless Adrian thinks that's a dumb idea ;)
>
> Then I'd enable it for the inbox. So packages could be moved out of
> it, but not out of the trunk, which I'd find safer.
>
> Packages should be moved from the inbox only to the "treated" repo,
> rather than directly into the trunk, IMHO. This is so it's clear in
> the trunk repo which core developer uploaded a version. Possibly this
> should be enforced by having two flags instead of one (devCanMoveIn
> and devCanMoveOut).
>
> - Bert -
>
>
> > That said, you bring up a good point regarding tracking what has been
> > done. As it stands you have to see what is in inbox and then look at
> > the listing in trunk to see if that file is in the listing there. Of
> > course that ignores the possibility that it's not actually in the
> > ancestry of the current latest version and is ultimately overlooked
> > that
> > way. It would also be useful to provide some easy feedback for those
> > submitting issues to the inbox indicating when their submission has
> > been
> > accepted. Perhaps it's time for our own SqueakSource branch.
> >
> > Ken
> >
>
>
>

signature.asc (196 bytes) Download Attachment

Andreas.Raab

Re: [squeak-dev] Re: Inbox

In reply to this post by Ken Causey-3

Ken Causey wrote:
> I've added the Treated project.

Thanks.

> P.S. I have to say I did not find the discussion of the Treated inbox on
> the Pharo page at all clear. It sounds to me like it says that an issue
> goes from the inbox into treated whether or not it is considered valid.

Indeed. It's just a way of saying "we've dealt with the issue". Just
like you can resolve issues in Mantis as "won't fix" or "no change
required" some of these may not actually end up in the final product.

> It then goes on to say that if it works it is 'published' to the Pharo
> project. Am I to take this to mean that it is either moved out of
> Treated or deleted? Also frankly, I don't understand what the word
> 'treated' means in this context.

It means "resolved". I'm familiar with the Monticello workflow so it
makes sense to me. Effectively, the workflow goes like this:
* You merge a package from the inbox and publish the merged result into
the trunk. Sometimes you can "optimize" this (when the package in the
inbox is a direct derivative of the last trunk version) and just copy
the package; but often you will not.
* Once you've published the merge in the trunk, you move the package
(which has now been integrated or otherwise been dealt with) to the
"treated" repository. This keeps the inbox small and simple while still
having a backup of the original submission in the "treated" repository.
* If the package is screwy in its original submission you move it to
"treated" as well, but let the original submitter know what was wrong
with it or how to improve it.
In either case, submissions don't litter the inbox forever, but get
dealt with quickly and moved out of the way to increase visibility of
new submissions.

Cheers,
- Andreas

Ken Causey-3

Re: [squeak-dev] Inbox

In reply to this post by Ken Causey-3

Bert agreed to help out with source.squeak.org maintenance and I have
set him up to do so.

Ken

On Thu, 2009-08-13 at 12:00 -0500, Ken Causey wrote:
> It seems like we need to coordinate a bit more closely as we have now
> somewhat duplicated ourselves here (see separate email in this thread),
> although my solution was much more simplistic. Bert would you care to
> take over maintenance of source.squeak.org? I'm sure you are far more
> familiar with the SS codebase than I.
>
> Ken

signature.asc (196 bytes) Download Attachment

Bert Freudenberg

Re: [squeak-dev] Re: Inbox

In reply to this post by Andreas.Raab

On 13.08.2009, at 19:08, Andreas Raab wrote:

> Ken Causey wrote:
>> I've added the Treated project.
>
> Thanks.
>
>> P.S. I have to say I did not find the discussion of the Treated
>> inbox on
>> the Pharo page at all clear. It sounds to me like it says that an
>> issue
>> goes from the inbox into treated whether or not it is considered
>> valid.
>
> Indeed. It's just a way of saying "we've dealt with the issue". Just
> like you can resolve issues in Mantis as "won't fix" or "no change
> required" some of these may not actually end up in the final product.
>
>> It then goes on to say that if it works it is 'published' to the
>> Pharo
>> project. Am I to take this to mean that it is either moved out of
>> Treated or deleted? Also frankly, I don't understand what the word
>> 'treated' means in this context.
>
> It means "resolved". I'm familiar with the Monticello workflow so it
> makes sense to me. Effectively, the workflow goes like this:
> * You merge a package from the inbox and publish the merged result
> into the trunk. Sometimes you can "optimize" this (when the package
> in the inbox is a direct derivative of the last trunk version) and
> just copy the package; but often you will not.
> * Once you've published the merge in the trunk, you move the package
> (which has now been integrated or otherwise been dealt with) to the
> "treated" repository. This keeps the inbox small and simple while
> still having a backup of the original submission in the "treated"
> repository.
> * If the package is screwy in its original submission you move it to
> "treated" as well, but let the original submitter know what was
> wrong with it or how to improve it.
> In either case, submissions don't litter the inbox forever, but get
> dealt with quickly and moved out of the way to increase visibility
> of new submissions.

Core developers can now move packages out of the inbox.

So the developer who merges a package from "inbox" into "trunk" should
then move the package from "inbox" to "treated". Currently this
requires using the source.squeak.org web interface.

- Bert -