We talked a lot about the relationship of unhosted and remotestorage
in the past, and at the Unhost unconference finally with more people
than just Michiel and me. We concluded that since we introduce 2
technical concepts to people which do not necessarily need to be
connected, we should separate them more clearly. While there is lots
of possible overlap and remotestorage was born out of the then
Unhosted project, we should have 2 strong separated brands also to
avoid confusion what is what.
That is, unhosted web apps can work without remotestorage. They can
just use localStorage, or they can use Dropbox, Google Drive, iCloud
or any other storage standard. Although remotestorage for now is the
recommended open standard because it is standardized, interoperable
and can be deployed by anyone.
And remotestorage can be used by more than just unhosted web apps. We
talked to people of Libre Office and Thunderbird before, and in
presentations have always said that the web apps do not necessarily
need to be client-side only. But unhosted web apps are recommended,
since they are platform-independent, portable and do not track you.
So let’s go! We have a new Github organization at
http://github.com/remotestorage – I already added some people involved
with remotestorage, and the remotestorage.js repository moved there
from unhosted.
Join our IRC channel #remotestorage on freenode.net and the mailing
list is kicked off with this post – join by mailing to
remotestor...@librelist.com, the archives will be available at
http://librelist.com/browser/remotestorage/ Also follow https://twitter.com/remotestorage_
Do we fork them to the remotestorage Github organization? Or do we ask
the authors if they want to transfer ownership to remotestorage, in
which they can continue to develop them there? Or do we do nothing at
all, just maybe linking to them?
I think asking the authors to transfer ownership is best (except
ownCloud, which is not a dedicated remote storage only). Those which
don’t want to do that we’ll still link, but it’s best to have it under
one umbrella because it’s all about the same standard.
CC’d the authors – please let us know your stance on this.
On Wed, Sep 12, 2012 at 9:10 PM, Jan-Christoph Borchardt
<h...@jancborchardt.net> wrote:
> We talked a lot about the relationship of unhosted and remotestorage
> in the past, and at the Unhost unconference finally with more people
> than just Michiel and me. We concluded that since we introduce 2
> technical concepts to people which do not necessarily need to be
> connected, we should separate them more clearly. While there is lots
> of possible overlap and remotestorage was born out of the then
> Unhosted project, we should have 2 strong separated brands also to
> avoid confusion what is what.
> That is, unhosted web apps can work without remotestorage. They can
> just use localStorage, or they can use Dropbox, Google Drive, iCloud
> or any other storage standard. Although remotestorage for now is the
> recommended open standard because it is standardized, interoperable
> and can be deployed by anyone.
> And remotestorage can be used by more than just unhosted web apps. We
> talked to people of Libre Office and Thunderbird before, and in
> presentations have always said that the web apps do not necessarily
> need to be client-side only. But unhosted web apps are recommended,
> since they are platform-independent, portable and do not track you.
> So let’s go! We have a new Github organization at
> http://github.com/remotestorage – I already added some people involved
> with remotestorage, and the remotestorage.js repository moved there
> from unhosted.
> Join our IRC channel #remotestorage on freenode.net and the mailing
> list is kicked off with this post – join by mailing to
> remotestor...@librelist.com, the archives will be available at
> http://librelist.com/browser/remotestorage/ > Also follow https://twitter.com/remotestorage_
We also have http://remotestoragejs.com which is not a good fit for the whole project. We're trying to get remotestorage.org or, if that doesn't work out, remotestorage.io to put up a website for everything around Remote Storage, like
* description of the technology in general (linking to unhosted.org for describing the goal of unhosted web apps that we try to achieve
* spec (probably only linking to W3C)
* everything about storage
* everything about apps (clients)
* dev team
* ...
Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:
> Do we fork them to the remotestorage Github organization? Or do we ask
> the authors if they want to transfer ownership to remotestorage, in
> which they can continue to develop them there? Or do we do nothing at
> all, just maybe linking to them?
> I think asking the authors to transfer ownership is best (except
> ownCloud, which is not a dedicated remote storage only). Those which
> don’t want to do that we’ll still link, but it’s best to have it under
> one umbrella because it’s all about the same standard.
> CC’d the authors – please let us know your stance on this.
> On Wed, Sep 12, 2012 at 9:10 PM, Jan-Christoph Borchardt
> <h...@jancborchardt.net> wrote:
>> We talked a lot about the relationship of unhosted and remotestorage
>> in the past, and at the Unhost unconference finally with more people
>> than just Michiel and me. We concluded that since we introduce 2
>> technical concepts to people which do not necessarily need to be
>> connected, we should separate them more clearly. While there is lots
>> of possible overlap and remotestorage was born out of the then
>> Unhosted project, we should have 2 strong separated brands also to
>> avoid confusion what is what.
>> That is, unhosted web apps can work without remotestorage. They can
>> just use localStorage, or they can use Dropbox, Google Drive, iCloud
>> or any other storage standard. Although remotestorage for now is the
>> recommended open standard because it is standardized, interoperable
>> and can be deployed by anyone.
>> And remotestorage can be used by more than just unhosted web apps. We
>> talked to people of Libre Office and Thunderbird before, and in
>> presentations have always said that the web apps do not necessarily
>> need to be client-side only. But unhosted web apps are recommended,
>> since they are platform-independent, portable and do not track you.
>> So let’s go! We have a new Github organization at
>> http://github.com/remotestorage – I already added some people involved
>> with remotestorage, and the remotestorage.js repository moved there
>> from unhosted.
>> Join our IRC channel #remotestorage on freenode.net and the mailing
>> list is kicked off with this post – join by mailing to
>> remotestor...@librelist.com, the archives will be available at
>> http://librelist.com/browser/remotestorage/ >> Also follow https://twitter.com/remotestorage_
Note that the php-remoteStorage implementation depends on the
php-oauth authorization server (https://github.com/fkooman/php-oauth)
and was only tested with this OAuth server, it may work with other
OAuth servers, but this is untested.
> I think asking the authors to transfer ownership is best (except > ownCloud, which is not a dedicated remote storage only). Those
> which don t want to do that we ll still link, but it s best to have
> it under one umbrella because it s all about the same standard.
I'm okay with this, however, because of the OAuth AS dependency it may
be a bit weird to pull php-remoteStorage to the remoteStorage
organization and the OAuth server not... or is that not a problem?
Another idea I'm playing with is creating a "remoteStorage" VM that
has everything preconfigured. Would this be interesting?
Regards,
Fran ois
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> Do we fork them to the remotestorage Github organization? Or do we ask
> the authors if they want to transfer ownership to remotestorage, in
> which they can continue to develop them there? Or do we do nothing at
> all, just maybe linking to them?
> I think asking the authors to transfer ownership is best (except
> ownCloud, which is not a dedicated remote storage only). Those which
> don’t want to do that we’ll still link, but it’s best to have it under
> one umbrella because it’s all about the same standard.
> CC’d the authors – please let us know your stance on this.
From structural viewpoint I'm all for it, but not sure what that
transfer means from a technical perspective.
Probably a matter of reading the docs, but I thought I'll ask here
anyway.
Do github allow to retain admin access to a repo within organisation
without admin access to the rest of the repositories there?
How transfer itself should be performed?
Github won't let me transfer repo to an organisation unless I'm an
admin there, but granting me an admin privileges seem to be a totally
unnecessary overkill, if not a risk as well (if only because I might
leak my access due to poor security practices).
Though I guess such access will only be needed for a short time.
>> Do we fork them to the remotestorage Github organization? Or do we ask
>> the authors if they want to transfer ownership to remotestorage, in
>> which they can continue to develop them there? Or do we do nothing at
>> all, just maybe linking to them?
>> I think asking the authors to transfer ownership is best (except
>> ownCloud, which is not a dedicated remote storage only). Those which
>> don’t want to do that we’ll still link, but it’s best to have it under
>> one umbrella because it’s all about the same standard.
>> CC’d the authors – please let us know your stance on this.
> From structural viewpoint I'm all for it, but not sure what that
> transfer means from a technical perspective.
> Probably a matter of reading the docs, but I thought I'll ask here
> anyway.
> Do github allow to retain admin access to a repo within organisation
> without admin access to the rest of the repositories there?
> How transfer itself should be performed?
> Github won't let me transfer repo to an organisation unless I'm an
> admin there, but granting me an admin privileges seem to be a totally
> unnecessary overkill, if not a risk as well (if only because I might
> leak my access due to poor security practices).
> Though I guess such access will only be needed for a short time.
Hi!
You can just push from your local git repository to the remote storage organization's on github. You can be granted commit rights for that without being an organization admin.
I'd say if the maintainer wants to be part of the yet-to-be-formed Remote Storage organization/team it would be great to have the code in a repository in the github organization. Else we just link. (Not being closely related to the project in this way of course doesn't mean not being part of the Remote Storage community.)
Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:
> Do we fork them to the remotestorage Github organization? Or do we ask
> the authors if they want to transfer ownership to remotestorage, in
> which they can continue to develop them there? Or do we do nothing at
> all, just maybe linking to them?
> I think asking the authors to transfer ownership is best (except
> ownCloud, which is not a dedicated remote storage only). Those which
> don’t want to do that we’ll still link, but it’s best to have it under
> one umbrella because it’s all about the same standard.
> > Do github allow to retain admin access to a repo within organisation
> > without admin access to the rest of the repositories there?
> > How transfer itself should be performed?
> > Github won't let me transfer repo to an organisation unless I'm an
> > admin there, but granting me an admin privileges seem to be a totally
> > unnecessary overkill, if not a risk as well (if only because I might
> > leak my access due to poor security practices).
> > Though I guess such access will only be needed for a short time.
> Hi!
> You can just push from your local git repository to the remote storage organization's on github. You can be granted commit rights for that without being an organization admin.
It's not a transfer proper though - some github-specific metadata like
issues, watchers, stars, subscriptions, notifications, etc won't
be transferred.
Jan-Christoph has clarified that on irc (#remotestorage on freenode)
now that it should be done through admin access (and I've already
moved the thing).
I don't have a clear answer to other questions yet (again, should
probably just rtfm), but don't think they're as important.
If transfered through the admin settings of the repo, all the issues,
watchers, stars etc are also carried over. This is also the case with
your https://github.com/RemoteStorage/django-unhosted (see the 5
stargazers).
On Wed, Sep 12, 2012 at 11:39 PM, Mike Kazantsev <mk.frag...@gmail.com> wrote:
> On Wed, 12 Sep 2012 22:40:28 +0200
> Martin Stadler <mar...@siarp.de> wrote:
>> Am 12.09.2012 um 22:22 schrieb Mike Kazantsev:
>> > Do github allow to retain admin access to a repo within organisation
>> > without admin access to the rest of the repositories there?
>> > How transfer itself should be performed?
>> > Github won't let me transfer repo to an organisation unless I'm an
>> > admin there, but granting me an admin privileges seem to be a totally
>> > unnecessary overkill, if not a risk as well (if only because I might
>> > leak my access due to poor security practices).
>> > Though I guess such access will only be needed for a short time.
>> Hi!
>> You can just push from your local git repository to the remote storage organization's on github. You can be granted commit rights for that without being an organization admin.
> It's not a transfer proper though - some github-specific metadata like
> issues, watchers, stars, subscriptions, notifications, etc won't
> be transferred.
> Jan-Christoph has clarified that on irc (#remotestorage on freenode)
> now that it should be done through admin access (and I've already
> moved the thing).
> I don't have a clear answer to other questions yet (again, should
> probably just rtfm), but don't think they're as important.
Jan-Christoph Borchardt <h...@jancborchardt.net> wrote:
> >> You can just push from your local git repository to the remote storage organization's on github. You can be granted commit rights for that without being an organization admin.
> > It's not a transfer proper though - some github-specific metadata like
> > issues, watchers, stars, subscriptions, notifications, etc won't
> > be transferred.
> If transfered through the admin settings of the repo, all the issues,
> watchers, stars etc are also carried over. This is also the case with
> your https://github.com/RemoteStorage/django-unhosted (see the 5
> stargazers).
Indeed, but you must've missed the context of that (mine) response,
which was Martin's suggestion (above) to "push from your local git
repository to the remote storage organization's on github", which I've
(possibly mis-) interpreted as creating a new github repo and just
pushing all the same commits there.
What a lot of projects do for 3rd party repos is having a second organization suffixed with "-contrib", where all 3rd party code lives. That way it is clear for bystanders that the code has a bit of approvement by the project's core team, but is not maintained by them.
So, "remotestorage-contrib"?
On Sep 12, 2012, at 10:48 PM, Martin Stadler <mar...@siarp.de> wrote:
> I'd say if the maintainer wants to be part of the yet-to-be-formed Remote Storage organization/team it would be great to have the code in a repository in the github organization. Else we just link. (Not being closely related to the project in this way of course doesn't mean not being part of the Remote Storage community.)
> Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:
>> Do we fork them to the remotestorage Github organization? Or do we ask
>> the authors if they want to transfer ownership to remotestorage, in
>> which they can continue to develop them there? Or do we do nothing at
>> all, just maybe linking to them?
>> I think asking the authors to transfer ownership is best (except
>> ownCloud, which is not a dedicated remote storage only). Those which
>> don’t want to do that we’ll still link, but it’s best to have it under
>> one umbrella because it’s all about the same standard.
On Sat, Sep 15, 2012 at 4:11 PM, Sebastian Kippe <i...@sebastiankippe.de> wrote:
> What a lot of projects do for 3rd party repos is having a second organization suffixed with "-contrib", where all 3rd party code lives. That way it is clear for bystanders that the code has a bit of approvement by the project's core team, but is not maintained by them.
> So, "remotestorage-contrib"?
> On Sep 12, 2012, at 10:48 PM, Martin Stadler <mar...@siarp.de> wrote:
>> I'd say if the maintainer wants to be part of the yet-to-be-formed Remote Storage organization/team it would be great to have the code in a repository in the github organization. Else we just link. (Not being closely related to the project in this way of course doesn't mean not being part of the Remote Storage community.)
>> Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:
>>> Do we fork them to the remotestorage Github organization? Or do we ask
>>> the authors if they want to transfer ownership to remotestorage, in
>>> which they can continue to develop them there? Or do we do nothing at
>>> all, just maybe linking to them?
>>> I think asking the authors to transfer ownership is best (except
>>> ownCloud, which is not a dedicated remote storage only). Those which
>>> don’t want to do that we’ll still link, but it’s best to have it under
>>> one umbrella because it’s all about the same standard.
I’d say we make it simple: You are part of the remotestorage org
either way if you contribute in a substantial way (such as writing a
storage). No need for a separate contrib group. And then everyone can
choose for themselves if they want to have the repo in the org or on
their own space.
On Sat, Sep 15, 2012 at 4:11 PM, Sebastian Kippe <i...@sebastiankippe.de> wrote:
> What a lot of projects do for 3rd party repos is having a second organization suffixed with "-contrib", where all 3rd party code lives. That way it is clear for bystanders that the code has a bit of approvement by the project's core team, but is not maintained by them.
> So, "remotestorage-contrib"?
> On Sep 12, 2012, at 10:48 PM, Martin Stadler <mar...@siarp.de> wrote:
>> I'd say if the maintainer wants to be part of the yet-to-be-formed Remote Storage organization/team it would be great to have the code in a repository in the github organization. Else we just link. (Not being closely related to the project in this way of course doesn't mean not being part of the Remote Storage community.)
>> Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:
>>> Do we fork them to the remotestorage Github organization? Or do we ask
>>> the authors if they want to transfer ownership to remotestorage, in
>>> which they can continue to develop them there? Or do we do nothing at
>>> all, just maybe linking to them?
>>> I think asking the authors to transfer ownership is best (except
>>> ownCloud, which is not a dedicated remote storage only). Those which
>>> don’t want to do that we’ll still link, but it’s best to have it under
>>> one umbrella because it’s all about the same standard.
