Squeak Board minutes - 12/17/12

Members attending: Bert Freudenberg, Colin Putney, Chris Muller, Randal
Schwartz, Chris Cunnington, Levente Uzonyi

- Colin and Chris Muller volunteered to be the release managers for
Squeak 4.5

- we explored how the Jenkins server could send an email to Squeak-dev  
when a recent update to the Trunk breaks a test.

- moving services from the current server, box2, to the two new boxes,
box3 and box4, is under way

- we are talking to the managers of squeaksource.com about how to
provide facilities to help people move projects to SqueakSource3.

- There is agreement that having "officially supported" packages outside
the image is something everyone wants.  The new CI infrastructure could
run automated tests even for these packages.

On 18 December 2012 13:45, Chris Cunnington
<[hidden email]> wrote:
> Members attending: Bert Freudenberg, Colin Putney, Chris Muller, Randal
> Schwartz, Chris Cunnington, Levente Uzonyi
>
> - Colin and Chris Muller volunteered to be the release managers for Squeak
> 4.5

Cool! I started a wishlist here: http://wiki.squeak.org/squeak/6189

> - we are talking to the managers of squeaksource.com about how to provide
> facilities to help people move projects to SqueakSource3.

People can already very easily port any repositories to which they
have read rights:
http://marianopeck.wordpress.com/2011/11/08/migrating-projects-to-squeaksource3/

What facilities beyond these are we missing?

frank

On 2012-12-18, at 15:02, Frank Shearar <[hidden email]> wrote:


For one, this does not preserve meta data. But more importantly we're concerned about the long-term availability of the stuff stored there that is *not* copied to ss3. This just didn't make it into the minutes. So we're talking to the people for how to ensure that no data is lost should they decide to discontinue their service.

- Bert -

On 18 December 2012 14:33, Bert Freudenberg <[hidden email]> wrote:
You mean _project_ metadata here, I assume? Wikis, for instance, and
the various other settings a project might have, like committer info.
Fair enough, I didn't think of that.

frank

> - Bert -
>
>
>

I think we should be careful about mass-porting of projects.  If you look at original SqueakSource, there are a LOT of projects and a lot of them are junk projects.

On 2012-12-18, at 16:46, Chris Muller <[hidden email]> wrote:

> I think we should be careful about mass-porting of projects.  If you look at original SqueakSource, there are a LOT of projects and a lot of them are junk projects.
>
> Here with SS3 we have a chance to start fresh with more quality, less quantity.  Leave the old SS as-is with more quantity, less quality.  It's really not hard to set up Account + Projects at SS3, but just enough that we will end up with new, active projects.
>
> I know you say its nice to have just one place to go looking for code -- ahem, but you already know SS3 is not the answer to that..  Either way we intend to keep the original SS up and running right?

IMHO it would be convenient if old package URLs continued to work, but I see no point in keeping it active (allowing uploads) indefinitely.

- Bert -

On 18-12-2012, at 7:59 AM, Bert Freudenberg <[hidden email]> wrote:

> On 2012-12-18, at 16:46, Chris Muller <[hidden email]> wrote:
>
>> I think we should be careful about mass-porting of projects.  If you look at original SqueakSource, there are a LOT of projects and a lot of them are junk projects.
>>
>> Here with SS3 we have a chance to start fresh with more quality, less quantity.  Leave the old SS as-is with more quantity, less quality.  It's really not hard to set up Account + Projects at SS3, but just enough that we will end up with new, active projects.
>>
>> I know you say its nice to have just one place to go looking for code -- ahem, but you already know SS3 is not the answer to that..  Either way we intend to keep the original SS up and running right?
>
> IMHO it would be convenient if old package URLs continued to work, but I see no point in keeping it active (allowing uploads) indefinitely.


Suggestion;
a) keep the old URLs working as much as practical.
b) where a package has been migrated and is considered 'supported' in whatever sense people think suitable, use redirection magic to redirect to the new place.
c) where a package has not been migrated, add prominent notes to all relevant places (description page, listings, even the name of the package if that works) to the effect that it might no work, hasn't been re-adopted yet etc.
d) allow a sort of copy-on-write effect to find out which packages ever get used & brought up to date.
e) after some suitable period - say 100 years - drop anything not ever updated.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Implementation is the sincerest form of flattery.

> Suggestion;
> a) keep the old URLs working as much as practical.
> b) where a package has been migrated and is considered 'supported' in whatever sense people think suitable, use redirection magic to redirect to the new place.
> c) where a package has not been migrated, add prominent notes to all relevant places (description page, listings, even the name of the package if that works) to the effect that it might no work, hasn't been re-adopted yet etc.
> d) allow a sort of copy-on-write effect to find out which packages ever get used & brought up to date.
> e) after some suitable period - say 100 years - drop anything not ever updated.

I'm don't mean to sound like a broken record.  Until someone
volunteers to implement your suggestion, a possible alternative might
be to just document it in the Map.  That's actually its primary
purpose; to tell us where projects are.

On 18-12-2012, at 4:31 PM, Chris Muller <[hidden email]> wrote:

You're quite right - until there is a volunteer with time & appropriate knowledge, nothing much can be done.
I'd guess (and it is a guess…) that a & b should be fairly simple for any of the people that normally work on the repository stuff.
c might be doable by changing some template for the pages?
d would happen by looking at the 'old' stuff in a year or so and emailing authors of any package never updated.
e …. just wait…. and wait ….


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Mihi ignosce. Cum homine de cane debeo congredi = Excuse me. I've got to see a man about a dog.