Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, 08 Jun 2016 15:14:36 +0100, Iain R. Learmonth wrote:
> Hi All,
>
> On 08/06/16 15:10, Peter Palfrader wrote:
>> On Wed, 08 Jun 2016, Marco d'Itri wrote:
>>> Since usability is the main reason many people hate using alioth,
>
> Do people really hate Alioth if they're just using it for git hosting?
> You do some ssh and make a repo and then you just pull and push as you
> would with anything else.
Git is not only for code hosting. It is also a tool for collaborating,
even with people not formally affiliated with your project.
So, say I want to contribute to a project I don't normally work in. Steps
in alioth:
- debcheckout project
- hack (possibly in own branch)
- ssh into alioth
- alioth$ mkdir -p ~/public_git/project.git
- alioth$ cd ~/public_git/project.git && git init --bare
- git remote add personal\
git+ssh://git.debian.org/git/users/$user/project.git
- git push -u personal $currentbranch
- Wait some minutes for cron job to pick up your repo
- Realize you did not edit description, nor touch the magic
git-daemon-export-ok file in the remote repo, do so.
- Wait some minutes again
- Send mail to project maintainer instructing them to pull from
https://anonscm.debian.org/git/users/$user/project.git
Compare with gitlab:
- go to https://gitlab.debian.org/project/project
- click fork
- git clone the url gitlab will tell you
- hack
- push
- click "Submit Merge Request" button on the same page
If the change is small enough (ie, doc/typo fixes), you can even edit the
file directly in the web browser.
For flyby contributions (eg, because you noticed a small thing you can
fix, or because you are working on lots of packages due to an archive-
wide task), the alioth workflow doesn't work very well.
>
>>> "because it's shiny" is a reasonable selling point for gitlab...
>
> It's also far from a feature-complete replacement for Alioth and has
> zero integration into our existing infrastructure.
Fortunately, integration can be worked on.
>
> A shiny web view of repositories is not a reason to run a whole new
> service. Just make a shiny theme for cgit.
No, gitlab is not a shiny web view of repositories. It is a (web) app
that helps people collaborate on projects. One of the things it does is
give you a web view of the git repository. But it also gives you tools to
manage repositories, track change proposals, triger CI builds, and
integrate with other services via hooks. It probably has more features
that I have just not used yet.
>
>
>> But that doesn't mean we as a project have to run and keep maintaining
>> all the things that were once shiney.
>
> +1
That speaks more to the need of actually dropping the not-shiny-anymore
services rather than block adding a new service.
--
Saludos,
Felipe Sateler
Reply to: