Hi Jarrod,
I would be happy to merge any changes to my Gitorious Chef recipe for it
to work on CentOS/Redhat too. I can download a CentOS image for testing
it and I can help you with Chef specific bits as long as I understand it.
It just happens that there is a long time since I last used Redhat (last
version was 9 when Fedora was born and I changed to Suse at that time if
I remember correctly). I use Debian for several years now and I never
worked with something like yum in Redhat, Suse, Mandrake, Conectiva or
Mandriva. The only tool available at that time (that I knew) was "rpm"
which is "dpkg" equivalent.
If you want to help supporting CentOS in the Chef recipe, get in touch
with me and we can help each other.
Cheers, Rodrigo.
Em 26-06-2011 14:42, [email protected] escreveu:
On , Marius Mårnes Mathiesen <[email protected]> wrote:
> Anyone subscribed to this list will know that installing Gitorious
is not for the faint of heart. There are a lot of moving parts, a lot
of dependencies, and getting everything right is difficult. I really
want to change this.
>
> The question is: once we have an easily installed,
anonymous/authenticated, pull/push solution for Git traffic: is it
time to deprecate the other protocol handlers in Gitorious:
>
> - The SSH handler
> - The Git handler (git-daemon or git-proxy)
>
>
> Would anybody miss them?
Yes, lots of people disable the HTTP support completely and only use
SSH for writes and Git of read only access. This is what we do for our
installation.
This is very important for work flows where people should be able to
check out read only copies but not be able to write.
All my Java projects, and there and dozens and dozens of Java repos in
my Gitorious install, use Maven 3 and its support for the
maven-release-plugin and scm-plugin which it uses to update Git
automatically when preforming releases.
the SCM plugin likes to have a "developer" url and a "guest" url so it
can publish documentation with links that people can checkout the code
but not be able to write to it.
We only give write access to people that are responding to merge
requests and use the git protocol for adding remotes to private clones
to pull from the mainline repository.
This separation of concerns is very important to workflows like this.
If you want to enhance the HTTP, then by all means do that, but don't
remove any functionality that is already there and working great.
PS: As to the difficulty in installing Gitorious. It took me most of a
day and a half to get it up and running on a CentOS 5.5 server. Most
of the time was me dealing with all the very specific versions of Ruby
stuff that wasn't available via any one YUM repository. I do just
about every language but Ruby and it ecosystem, there were lots of
things I just had to guess at until I got it right. In particular
setting up Passenger details under Apache 2.2.x entailed lots and lots
of Googling and emails to the group and IRC chats, because most of the
Passenger documentation refers to config files and things with the
assumption you know where they actually are. Gitorious wasn't stable
until I got this nailed down.
There is already what looks like a nice Chef recipe for Ubuntu, we
don't do Ubuntu because we have standardized on RHEL5/CentOS5 because
that is what all our clients use, an RPM package and a custom YUM
repository for RHEL5/CentOS5.x that at least consolidated all the very
specific Ruby/Rails/Passenger details into a single RPM and have
dependencies on all the other stuff like Apache, MySQL, etc. would go
a long way to a more painless adoption. --
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
