[squeak-dev] Andreas projects on SS

Chris Muller ma.chris.m at gmail.com
Thu Feb 13 22:05:12 UTC 2014


>> You suggested 1) gain access, 2) copy to new repo, 3)
>> delete old repo.  If we are talking about Andreas' projects, then I'm
>> strongly opposed to 3.  If we weren't, then I apologize for my
>> misunderstanding.
>
> The delete part was sloppy written - I never meant to *just* delete
> something! I meant, copy somewhere else and delete. In other words - move.

I knew that, and I am totally opposed to moving.  Please only copy it.

>> I'm also opposed to (1) only to the extent it mutates any objects
>> Andreas made.  If we could get by with ONLY adding new versions to a
>> project, then that'd only be extending Andreas' original work without
>> modifying it, probably fine.  Otherwise, I think we should extend it
>> in a new project of our own, and add or update appropriate entries in
>> the catalog.
>
> Interesting notion. I guess that is also a route, mark all Andreas projects
> as "These are not maintained but kept readonly as they were when Andreas
> left us to respect him. For maintained derivatives see xxxx."

I think we should not scatter lame catalog information about in our
source-code repository at all.

Even worse would be to break into spaces we do not have access to and
molest them with lame catalog information.

I said we should make a *new* project, of our *own*.  And let the new
Pharo catalog, Squeak catalog and search-engines direct people to the
new project.

> Sure, that works too. BUT... do note that many people find stuff by googling
> and this is a bit of an issue:
>
> - If people end up on the actual versions HTML pages, then they don't get
> any warning that they are looking at a stale repo.
>
> - If people google and find a repo doit, and enter that into Monticello,
> they also never see the note.

Good!  Because then they'll come complaining on the list and someone
can refer them to the new Pharo catalog or Squeak catalog and their
productivity will be enhanced forever going forward.

Look, Google finds old stuff and new stuff, related stuff and
unrelated stuff, such as some newly sprouted fork project with the
same name but maybe at a different repository.  So we should embrace,
not fight, this organic nature of software-dev community.

> Of course, the "hack" to add a snapshot mentioning that it is not a
> maintained repo - that actually works fairly well.
>
>> We could _try_ to do catalog management by deleting projects from SS
>> or leaving notes to go look somewhere else, but in a community and
>> license that encourages copy-and-modify, that is a futile and
>> certainly lame way to do cataloging, because a new project with the
>> same or similar name would spring up and lead to the same or similar
>> confusion you're trying to avoid for someone looking for Göran's code.
>>
>> For others' projects for which we have no admin access, it simply
>> doesn't work at all, because its wrong to break in and molest their
>> space.
>
> I agree, it is a hopeless war :) :) - but I still am free to do my best to
> avoid confusion on my own stuff. I really hope you are not seriously
> considering forbidding deleting projects.

Well, for the purposes for which you want to delete your projects (to
meet a cataloging requirement) makes me want to seriously consider it.
 "Ongoing-maintenance" is not the only need being served by the
repository.  Once something is put out there and people become
dependent on it, even if you own it, careful consideration should be
given about suddenly and arbitrarily deleting it.  At least something
like what the original SqueakSource folks did when they gave plenty of
notice about sunsetting squeaksource.com instead of simply killing the
server one day with no notice.

That way, people still dependent on it can do the necessary archiving
on their own.  In SS's case, others stepped up to take it over and the
great thing was preserved as, in my view, an _archive_.  Deleting from
archive is like deleting a book from a library because a new edition
of it just came out on amazon.


More information about the Squeak-dev mailing list