Community Source Vault
Andy Bower
We're nearly ready to send out the D6.1 RC1 release. As mentioned
before, one of the main features of this release is the integration of
STS into the Community Edition and the ability of both versions to
connect to a shared STS repository, which will be hosted on the Object
Arts site.
I'm writing here to solicit opinions on how this "Community Source
Vault" should be run. We need to be careful that the administration of
the vault doesn't turn into a time-consuming nightmare. Here are my
initial thoughts for your comments:
1) At the moment I'm thinking of running two vaults. The first would be
a "stable vault" that contains stable editions of large-scale packages
such as Seaside and Swazoo. I would imagine that there would typically
only be one or two people with write access to each project -- these
would be the owners of the project. New versions would be checked in
only by the owners.
2) The second vault would be much more loosely controlled. One would
still need a username and password for write access but basically anyone
could create new projects and anyone can update existing ones. This
would mean that if a non-owner wanted to make changes to the Seaside
project they could check it into the general vault and then ask the
owner to review the changes before moving them to the stable vault.
I'm not sure whether it's necessary to have this dual vault system but I
can see that just having a general vault alone might be a recipe for
chaos. Bear in mind that I don't want to get into a complex arrangement
of authentication for users -- I just want to use what is built into the
STS remote connection as it stands.
I think we should all take this opportunity to thank David Gorisek, the
author of STS and the remote connection, for a) writing it in the first
place and b) allowing it to be included in the free DCE version of Dolphin.
Best regards
Andy Bower
GallegO
IMO two repositories is the best choice because the stable one does
not receive a lot of garbage from when intermediate package versions
are submitted.
In other way, I'm not sure if the new sts version can compare editions
between repositories so having two can be a kind of limitation.
Actually I do all my work in my personal Repository. This local
repository contains all the method and class editions for daily work.
When I need versioning, I do it in the stable repository (located on
our server). After a version release I copy the stable repository to
my workstation.
This works perfectly.
Best Regards
Sebastian Calvo
UML Almighty Support
Great news.
I will choose 2 repositories. To have one Clean Repository and other
for tests and so on, is the best idea IMHO.
Regards,
Bruno
Don Rylander replace with "at" symbol
"Andy Bower" <bo...@SnipThisObject-arts.com> wrote in message
news:83vqhv...@mid.individual.net...
> Folks,
[...]
> I'm not sure whether it's necessary to have this dual vault system but I
> can see that just having a general vault alone might be a recipe for
> chaos. Bear in mind that I don't want to get into a complex arrangement of
> authentication for users -- I just want to use what is built into the STS
> remote connection as it stands.
will need occasional clean-up as well. I know STS has a purge feature, but
I'm not sure whether it's right for that sort of thing. (I've never used
the purge feature because my repository is a pretty reasonable size, and,
not knowing exactly what it would do, I've been a bit leery of what might
happen.)
> I think we should all take this opportunity to thank David Gorisek, the
> author of STS and the remote connection, for a) writing it in the first
> place and b) allowing it to be included in the free DCE version of
> Dolphin.
Amen to that!
Thanks to you and everyone involved with this latest edition,
Don R
>
> Best regards
>
> Andy Bower
Travis Kay
> Folks,
>
> We're nearly ready to send out the D6.1 RC1 release. As mentioned
> before, one of the main features of this release is the integration of
> STS into the Community Edition and the ability of both versions to
> connect to a shared STS repository, which will be hosted on the Object
> Arts site.
This is great news!
>
> I'm writing here to solicit opinions on how this "Community Source
> Vault" should be run. We need to be careful that the administration of
> the vault doesn't turn into a time-consuming nightmare. Here are my
> initial thoughts for your comments:
>
> 1) At the moment I'm thinking of running two vaults. The first would be
> a "stable vault" that contains stable editions of large-scale packages
> such as Seaside and Swazoo. I would imagine that there would typically
> only be one or two people with write access to each project -- these
> would be the owners of the project. New versions would be checked in
> only by the owners.
>
> 2) The second vault would be much more loosely controlled. One would
> still need a username and password for write access but basically anyone
> could create new projects and anyone can update existing ones. This
> would mean that if a non-owner wanted to make changes to the Seaside
> project they could check it into the general vault and then ask the
> owner to review the changes before moving them to the stable vault.
>
> I'm not sure whether it's necessary to have this dual vault system but I
> can see that just having a general vault alone might be a recipe for
> chaos. Bear in mind that I don't want to get into a complex arrangement
> of authentication for users -- I just want to use what is built into the
> STS remote connection as it stands.
Sounds good to me, I like the idea of having a trusted source for
official and support packages. Having a general vault, where changes
and or packages can be accepted by the community, as trusted would be
excellent.
>
> I think we should all take this opportunity to thank David Gorisek, the
> author of STS and the remote connection, for a) writing it in the first
> place and b) allowing it to be included in the free DCE version of Dolphin.
Absolutely, thank you David!
Travis Kay
>
> Best regards
>
> Andy Bower
Malbs
> I'm not sure whether it's necessary to have this dual vault system but I
> can see that just having a general vault alone might be a recipe for
> chaos. Bear in mind that I don't want to get into a complex arrangement
> of authentication for users -- I just want to use what is built into the
> STS remote connection as it stands.
I guess a better understanding of the level of control that the system
provides would be good. Is there some sort of ACL/User/Group
management available? It would be nice to be able to create a project,
and be able to manage the ACL to my project myself (creator becomes
admin, and then can add/remove users with write access as necessary)
VisualWorks has the public store, doesn't require 2 systems, but I'm
not sure about how the control over access works there. I can't
remember how you actually get approved for write access (I've only
ever used the anonymous account).
I think if people wanted to publish changes/revisions to a project for
a maintainer to review, they could host their own STS service and
publish the URL, even if temporarily - or upload a .pac file to
github, or some other mechanism. I don't think you need that wild-west
2nd repository?
To me, the usefulness of an OA hosted repository is not so
RandomAnonymousGuy can post some minor change to a new project he can
create whenever he feels like, but rather that, if I want to get the
latest version of Swazoo for Dolphin, or Bills PaneHolder package, or
any of the goodies on DolphinHarbor, I don't have to go through
various websites to download that stuff, I can go to the OA
repository. If someone wants to publish a change to a package, e-mail
the change to the project owner, or post the .pac file to the
newsgroup, or whatever!
If there was a single repo, some level of trust needs to be given to
the community members with named accounts, that the creation of a new
project is not the purpose of publishing patches, or whatever, but for
genuinely useful projects that can be shared amongst all Dolphin
users.
We have 2 genuine public repos in other dialects, SqueakSource has a
feel of a Bazaar about it, it's noisy, theres a lot of cruft in there,
but generally, the important stuff is accessible. The same can be said
about the Cincom Public Store, except perhaps someone maintains and
removes dead packages from it, because even after 8 years of accessing
it, it doesn't seem to have picked up much junk.
I'm not fussed, whatever does not create a nightmare for you, and
works, I'm happy!
> I think we should all take this opportunity to thank David Gorisek, the
> author of STS and the remote connection, for a) writing it in the first
> place and b) allowing it to be included in the free DCE version of Dolphin.
Yeah I think it's awesome that David has provided the remote access
component, and allowed all that work to be released into the CE
Carsten
Great news.
I like the Cincom public store, and they need only one repository,
which is easier to manage. If you have to repositories there might be
problems with the tools and it is more compilicated to manage. However
if you have one repository you need something to flag certain versions
as stable or official and others as test and also the ability to add
comments. These two things are supported in VisualWorks and I am
missing these since use use the otherwise great STS system.
In VisualWorks, every version can have a comment, and also a
"blessing" level, which is something like "broken", "development",
"released", "stable". The blessing levels and comments can also be
changed after a version is published (the only things that can change
in a published version). To be it seems like a very simple extension
to STS.
@David Gorisek: How do you think about this, or maybe you already have
it?
If STS would have this simple extension, we could eventually live with
only one repository.
Regards
Carsten
Stefan Schmiedl
Carsten <carsten...@straightec.de> wrote:
> I like the Cincom public store, and they need only one repository,
... and at least I have often wished that they had two.
> which is easier to manage. If you have to repositories there might be
> problems with the tools and it is more compilicated to manage.
Really? Why?
> In VisualWorks, every version can have a comment, and also a
> "blessing" level, which is something like "broken", "development",
> "released", "stable". The blessing levels and comments can also be
> changed after a version is published (the only things that can change
> in a published version). To be it seems like a very simple extension
> to STS.
I admit that it's been about a year since I last looked at the VW public
store, but back then the blessing levels were quite often neglected by
the publishers, i.e. most of the packages were "development" and to
get new functionality, you had to jump the comfortable ship of stable
and use dev anyways ... an interesting parallel between smalltalk and
linux distros :-)
And another problem (at least) I had with the public store was dependency
management between the different versions. It was not really visible,
which versions would work, which not. And there were *lots* of old,
obsolete, abandoned packages in there, with no easy way to figure out
if they would even load into a current image.
So ... speaking from the point of view of a public repository USER,
I'd like a simple, clean repo, where I can "just get the stuff I need"
with working, automated dependency resolution. At least I'd want
it to show "minimum requirements" for image/VM.
As a repo COMMITTER I'd like a small "do-it"-able code snippet
that I could use to push something into the open.
Adding things together, I come up with a single repository sporting
lots of metadata or two repositories, one for creating, one for consumption.
Regards,
s.
picoVerse
It would fix the problem with VW store that it can be too public. I
don't know but that's just the feeling I get.
Or how about 5 repositories.
If two was good would 5 be better?
I'm just throwing this idea out there.
I have no idea if it is good or not.