[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Wiki repository now available though Savannah (was: GSoC projects)

From: Thomas Schwinge
Subject: Wiki repository now available though Savannah (was: GSoC projects)
Date: Mon, 4 Aug 2008 10:46:55 +0200
User-agent: Mutt/1.5.11


On Mon, Aug 04, 2008 at 03:00:46AM +0200, olafBuddenhagen@gmx.net wrote:
> On Sat, Aug 02, 2008 at 07:09:42PM +0200, Thomas Schwinge wrote:
> > I don't know github.com.  But not why simply host (a secondary/backup
> > of) the Hurd wiki on the GNU Savannah machine already now?  Then we
> > can -- later, when the needed infrastructure is in place -- just do a
> > clean switch-over (from Barry's flubber to GNU Savannah; for the main
> > wiki repository).

This is done now: <http://git.savannah.gnu.org/gitweb/?p=hurd/wiki.git>

There is read-only access for everyone and read-write access for people
that are registered with the Hurd Savannah group.  (Please shout if you
aren't, but have a need to be.)

> > I'd prefer if such things would go over some of the Hurd mailing
> > lists, before something is said to have been decided in an IRC
> > channel.  Which none of the GNU Hurd maintainers is really regularely
> > frequenting.

> Well, I do actually see one problem with hosting it on Savannah: It
> means every wiki committer needs To have a Savannah account, be part of
> the Hurd project, and have commit rights.

Yes, this nevertheless is the policy for doing RCS-commits to the wiki
repository.  (In contrast to web-commits, which are open to everyone.)

> (Which means commit rights to
> all Hurd stuff, unless Savannah has a way to selectively give commit
> permissions for individual git repositories...)

There currently is indeed no such possibility on Savannah.

> But maybe that's not really a big issue, considering that with the need
> for copyright assignment, outsiders are not very likely to be interested
> in Git access to the wiki anyways...

I think that outsiders are likely to do a quick web-commit, rather than
locally getting hold of the git repository first, etc.  And, as described
on <http://www.bddebian.com/~wiki/contributing/wiki/>, there is still the
possibility to send in patches by email.

> The real reason for setting up a repository on github is that discussing
> things on the mailing list; waiting for some Savannah Hurd admin to set
> things up etc.; is precisely *not* what we wanted here -- we need a
> *quick* and easy solution for the needs of organising GSoC stuff.

OK, it was not obvious to me that having the wiki working (commit-wise)
was an essential thing.  I merely saw its current unsettled working
status as inconvenient, but not fundamentally.

> (Especially as you are the only admin who has been active over the past
> two years or so, and even you have been mostly absent over the past
> couple of months.)

Yes and yes.

It always helps to keep me CCed (as described on
<http://www.bddebian.com/~wiki/mailing_lists/> /
<http://www.bddebian.com/~wiki/community/communication/>).  I don't
always get to read all the mailing lists in a timely fashion.  I will
eventually, but immediate issues should always have a CC directly to my

> To make matters worse, when I asked you a couple of days ago what you
> propose to do about the wiki situation, you gave me an answer that,
> quite frankly, sounded like "wait and pray"

Yes, yes, this soulds like standard tschwinge practices...  ;-)

> so I decided to take
> initiative and look for another solution. Luckily, with the
> decentralized nature of Git, this in to problem at all. (Except perhaps
> for some additional noise in the history...)

Yo, taking initiative often enough is a way to attrackt my attention and
even get me active again!  :-)

> Note that I have no objection to using the Savannah repository, once it
> actually exists *and* all the involved people have commit access...

I will take care of merging between the two/three (with github)


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]