Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Jonathan Dowland]

On Wed, Jun 08, 2016 at 01:46:56PM +, Luca Filipozzi wrote:
> Let me rephrase, then: can we have a plan that addresses alioth / git /
> gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool
> because it's shiny?
> 
> This has more to do with delivering sustainable services while reducing the
> overhead / technical debt.

I think Perfect is the enemy of Good, here. Standing up a new shiny service
seems to be almost a Herculean task as it is; consolidating, having a joined-up
vision, all that stuff is, I think, quite impossible for us. I'd rather not
scare away people like Pirate who are prepared to channel their inner Hercules
and provide (another) useful service by demanding they do something even harder.

Frankly I'd love it if cdbs went away, everyone used git for Debian packages,
we all used dh, we all stuck to one agreed git-for-debian wrapper (or none),
pts.qa was finally removed and tracker linked from packages.d.o; and a whole
bunch of other things; but there is neither project consensus that this is what
we should do, nor the volunteers prepared to do it.  The nature of the project
is loosely-coupled, some redundancy, lots of legacy cruft, and sadly more than
one way to do it.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Joachim Breitner]

Hi,

Am 8. Juni 2016 22:47:24 MESZ, schrieb Julien Cristau :
>On Wed, Jun  8, 2016 at 15:56:31 +0200, Joachim Breitner wrote:
>
>> We’ll have to allow for some diversity, if only to try new paths (and
>> then, eventually, cut off old ones). Especially as long as there is
>> motivation. 
>> 
>I haven't seen much motivation to maintain alioth (especially the
>fusionforge bits) for a few years now.  Alex is doing a great job of
>preventing things from collapsing under their own weight entirely, but
>there's a difference.

I was referring to the motivation of those who want to intrude new things.

Joachim 

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Julien Cristau]

On Wed, Jun  8, 2016 at 15:56:31 +0200, Joachim Breitner wrote:

> We’ll have to allow for some diversity, if only to try new paths (and
> then, eventually, cut off old ones). Especially as long as there is
> motivation. 
> 
I haven't seen much motivation to maintain alioth (especially the
fusionforge bits) for a few years now.  Alex is doing a great job of
preventing things from collapsing under their own weight entirely, but
there's a difference.

Cheers,
Julien

Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Michael Lustfield]

On Wed, Jun 8, 2016 at 12:39 PM, Milan Kupcevic  wrote:

> On 06/08/2016 02:55 PM, Michael Lustfield wrote:
> > On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen
> > > wrote:
> >>Thanks for this nice summary. It helped me understand things better.
> >
> > I'm... actually gonna save this for later because it helps me understand
> > the alioth workflow.
> >
>
> [...]
>
> Great sarcasm.
>
> Milan
>


This was not in any way intended as sarcasm. If it came across as such,
please accept this as my apology.

Alioth has been, and continues to be, the hardest thing for me to wrap my
head around.

Whatever option (gitlab, gogs, gitolite) is rolled out and is able to
eventually replace at least the git (and projects) functionality of Alioth
would very much help me, and others, dive into other projects.

Currently, I don't like to even poke at other projects that I'm not already
familiar with; I'm scared I'll break something because I don't understand
the workflows and processes involved. I /did/ star that message and save it
for future use because I /did/ find it valuable.

Again, I'm sorry if I came across sarcastic. Hopefully elaborating helps
explain what I meant originally. :)

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Milan Kupcevic]

On 06/08/2016 02:08 PM, Milan Kupcevic wrote:
> On 06/08/2016 11:19 AM, Felipe Sateler wrote:
>>
>> So, say I want to contribute to a project I don't normally work in. Steps 
>> in alioth:
>>
> 
> [...]
> 
> Well, I would go this route:
> 
> - git clone 
> - hack
> - git commit -a -v
> - git format-patch -1 --to=proj...@lists.alioth.debian.org | mailx -t
> 

The last line is missing --stdout for correct piping:

  git format-patch -1 --to=proj...@domain.tld --stdout | mailx -t





signature.asc
Description: OpenPGP digital signature

Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Milan Kupcevic]

On 06/08/2016 02:55 PM, Michael Lustfield wrote:
> On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen
> > wrote:
>>Thanks for this nice summary. It helped me understand things better.
> 
> I'm... actually gonna save this for later because it helps me understand
> the alioth workflow.
> 

[...]

Great sarcasm.

Milan




signature.asc
Description: OpenPGP digital signature

Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Michael Lustfield]

On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen
 wrote:
>Thanks for this nice summary. It helped me understand things better.

I'm... actually gonna save this for later because it helps me understand
the alioth workflow.

I'm still relatively fresh to Debian dev and can say, without any doubt,
alioth was (continues to be) the hardest part, by far for me to wrap my
head around.

Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Marc Haber]

On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen
 wrote:
>Thanks for this nice summary. It helped me understand things better.

What Holger says +1.

I must say that I like the discussion style shown in this thread up to
now. Please more of this friendly constructivism.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Milan Kupcevic]

On 06/08/2016 11:19 AM, Felipe Sateler wrote:

[...]

> 
> So, say I want to contribute to a project I don't normally work in. Steps 
> in alioth:
> 

[...]

Well, I would go this route:

- git clone 
- hack
- git commit -a -v
- git format-patch -1 --to=proj...@lists.alioth.debian.org | mailx -t

> 
> 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
> 

[...]


Milan



signature.asc
Description: OpenPGP digital signature

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Luca Filipozzi]

On Wed, Jun 08, 2016 at 05:16:54PM +0100, Ian Jackson wrote:
> Luca Filipozzi writes ("Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: 
> Next steps for gitlab.debian)"):
> > On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote:
> > > That speaks more to the need of actually dropping the not-shiny-anymore 
> > > services rather than block adding a new service.
> > 
> > We aren't saying 'no'; we're saying 'please have a transition plan'.
> > 
> > Dropping a not-shiny-anymore service without a transition plan to
> > move users of the service off is not great.  That said, maybe that's
> > what we do.  Announce a date and move on.
> 
> We have a situation where someone thinks the existing services are
> poor, and wants to set up what they think is an improved one.
> Presumably they hope that lots of people will use it.
> 
> But what you are saying is that they must, right away, pick a fight
> with the administrators and users of the existing services.  They have
> to declare their intent to obsolete it and write out a detailed plan
> on how everyone will have to change.

I'm not asking anyone to pick a fight.  I'm asking for a transition plan (more
below).

If Alioth is no longer fit for purpose, then let's see if this is the
opportunity to find a replacement.

> I think that this would be very aggressive and harmful behaviour.  You
> can see in this thread the kind of (very measured, under the
> circumstances) responses from people who have qualms about such a
> plan.
> 
> Requiring this requires those who want improvement to (a) enter into a
> political battle (b) make explicit and public their criticisms of
> the existing setups (c) "win" against the now-"enemies" who support
> the existing services.
> 
> It is bad enough that it is sometimes thought acceptable to aggressive
> declare someone else's project obsolete.  Encouraging this behaviour,
> which is what you are doing, is (I'm sorry to say) very bad indeed.

A discussion between those proposing a new service and those currently
operating the current service doesn't need to be confrontational.

Asking for a conversation to develop a plan, if possible, should not be seen as
promoting a conflict.

Maybe the sole remaining administrator of Alioth is interested in making a
transition, also.

Maybe those proposing the new service can join the Alioth team to ease the
transition.

Maybe after gitlab is up, we give people six months to move off of Alioth.

Without additional people joining the Alioth team, that service is
under-resourced.  If the count of members reaches zero, then we will likely
consider the service abandoned, regardless of active user count.  (Maybe we
need to introduce RFH, RFA, O, etc. for services.)

Any new service transitioned to d.o needs to have a dedicated team to operate
it.  That's part of service planning.

> Also, from a practical point of view, this is an impractical way of
> carrying on change.  We don't know, in general, whether the new thing
> will indeed be better.  The best way is to try it and see.

Try it and see means debian.net.  That's fine.  That's not the same as
debian.org.

> We happily have some people who want to do the work of setting it up.
> They should be encouraged and supported.  They should not be set up in
> some kind of manufactured conflict with existing services.

I don't view it as a conflict.  There is one remaining Alioth administrator; we
should ask him what he wants to do.

> If the new thing really is great then we can think about what other
> things it might have obsoleted.  That would principally be a decision
> for those who are supporting and using the services which might be
> withdrawn.
> 
> And, that would be the time to think about firming the thing up - for
> example, by transitioning to a .org name on a DSA-owned machine.
> 
> For now I would advise the people who want to try gitlab to _consider
> in advance_[1] that transition, but to feel free to set something up
> outside DSA control for now.
> 
> [1] I'm sure DSA and others will be happy to advise on how to make
> choices which make moving to DSA infrastructure easier rather than
> harder.

Always.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Ian Campbell]

On Wed, 2016-06-08 at 20:29 +0530, Balasankar C wrote:
> Tell me an "easy" way to do merging in alioth,

I think perhaps it hasn't been made clear to folks on this thread that
gitlab is more like a github style thing (with a webui for PRs and
whatnot) rather than a more "traditional"/"simple" git hosting service
(like gitorious et al) used by people with ML driven development models
(who use "git send-email", "git pull-request" and "git am" etc and only
need push and pull from their service).

At least I assume that's what gitlab is based on what I'm infering from
what some folks are skirting around on this thread, perhaps someone who
is familiar with gitlab can comment.

(Iain was asking why people host only use alioth for simple git hosting
hate it, so your response was something of a non sequitur in that
context because you began talking about a usecase which is more than
simple git hosting)

Ian.

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Ian Jackson]

Luca Filipozzi writes ("Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: 
Next steps for gitlab.debian)"):
> On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote:
> > That speaks more to the need of actually dropping the not-shiny-anymore 
> > services rather than block adding a new service.
> 
> We aren't saying 'no'; we're saying 'please have a transition plan'.
> 
> Dropping a not-shiny-anymore service without a transition plan to
> move users of the service off is not great.  That said, maybe that's
> what we do.  Announce a date and move on.

We have a situation where someone thinks the existing services are
poor, and wants to set up what they think is an improved one.
Presumably they hope that lots of people will use it.

But what you are saying is that they must, right away, pick a fight
with the administrators and users of the existing services.  They have
to declare their intent to obsolete it and write out a detailed plan
on how everyone will have to change.

I think that this would be very aggressive and harmful behaviour.  You
can see in this thread the kind of (very measured, under the
circumstances) responses from people who have qualms about such a
plan.

Requiring this requires those who want improvement to (a) enter into a
political battle (b) make explicit and public their criticisms of
the existing setups (c) "win" against the now-"enemies" who support
the existing services.

It is bad enough that it is sometimes thought acceptable to aggressive
declare someone else's project obsolete.  Encouraging this behaviour,
which is what you are doing, is (I'm sorry to say) very bad indeed.


Also, from a practical point of view, this is an impractical way of
carrying on change.  We don't know, in general, whether the new thing
will indeed be better.  The best way is to try it and see.

We happily have some people who want to do the work of setting it up.
They should be encouraged and supported.  They should not be set up in
some kind of manufactured conflict with existing services.

If the new thing really is great then we can think about what other
things it might have obsoleted.  That would principally be a decision
for those who are supporting and using the services which might be
withdrawn.

And, that would be the time to think about firming the thing up - for
example, by transitioning to a .org name on a DSA-owned machine.

For now I would advise the people who want to try gitlab to _consider
in advance_[1] that transition, but to feel free to set something up
outside DSA control for now.

[1] I'm sure DSA and others will be happy to advise on how to make
choices which make moving to DSA infrastructure easier rather than
harder.

Ian.

why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Holger Levsen]

On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote:
> 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.
 
Thanks for this nice summary. It helped me understand things better.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Luca Filipozzi]

On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote:
> >> 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.

We aren't saying 'no'; we're saying 'please have a transition plan'.

Dropping a not-shiny-anymore service without a transition plan to move users of
the service off is not great.  That said, maybe that's what we do.  Announce a
date and move on.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Felipe Sateler]

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

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Balasankar C]

On ബുധന്‍ 08 ജൂണ്‍ 2016 07:44 വൈകു, Iain R. Learmonth wrote:
> 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.
>

Tell me an "easy" way to do merging in alioth, and then let's talk about
people hating Alioth.
Gitlab (or similar tools) is not preferred because they are shiny. They
are preferred because
they provide better, usable features. :)

People don't use git for just "push and pull", you are missing the whole
point of VCS and
collaborative development. :)

-- 
Balasankar C
http://balasankarc.in

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Antonio Terceiro]

On Wed, Jun 08, 2016 at 03:14:36PM +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.
> 
> >> "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.
> 
> A shiny web view of repositories is not a reason to run a whole new
> service. Just make a shiny theme for cgit.

gitlab (and, to be fair, gogs which was also mentioned in the thread)
are way more than a "shiny web view of repositories". you are completely
missing the point.


signature.asc
Description: PGP signature

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Iain R. Learmonth]

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.

>> "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.

A shiny web view of repositories is not a reason to run a whole new
service. Just make a shiny theme for cgit.

> 
> But that doesn't mean we as a project have to run and keep maintaining
> all the things that were once shiney.

+1

Thanks,
Iain.

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Peter Palfrader]

On Wed, 08 Jun 2016, Marco d'Itri wrote:

> On Jun 08, Luca Filipozzi  wrote:
> 
> > Let me rephrase, then: can we have a plan that addresses alioth / git /
> > gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool
> > because it's shiny?
> Since usability is the main reason many people hate using alioth, 
> "because it's shiny" is a reasonable selling point for gitlab...

But that doesn't mean we as a project have to run and keep maintaining
all the things that were once shiney.


-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Joachim Breitner]

Hi,

Am Mittwoch, den 08.06.2016, 13:46 + schrieb Luca Filipozzi:
> On Wed, Jun 08, 2016 at 03:17:44PM +0200, Joachim Breitner wrote:
> > 
> Let me rephrase, then: can we have a plan that addresses alioth / git /
> gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool
> because it's shiny?

Probably as likely as we can have a plan to agree on one version
control system, on one packaging scheme, on one repository layout, on
one CI system (we have jenkings.d.o, ci.d.o, and many people have their
own scripts).

We’ll have to allow for some diversity, if only to try new paths (and
then, eventually, cut off old ones). Especially as long as there is
motivation. 


Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

signature.asc
Description: This is a digitally signed message part

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Marco d'Itri]

On Jun 08, Luca Filipozzi  wrote:

> Let me rephrase, then: can we have a plan that addresses alioth / git /
> gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool
> because it's shiny?
Since usability is the main reason many people hate using alioth, 
"because it's shiny" is a reasonable selling point for gitlab...

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Luca Filipozzi]

On Wed, Jun 08, 2016 at 03:17:44PM +0200, Joachim Breitner wrote:
> Am Mittwoch, den 08.06.2016, 10:21 +0100 schrieb Jonathan Dowland:
> > On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote:
> > > Thanks for the offer. It would be great if I have more hands to help with
> > > migrating git.debian.org
> > 
> > Whoah there. Running an official Debian gitlab instance is one thing, 
> > migrating
> > git.debian.org is quite another. Did I miss where there was consensus on 
> > this?
> 
> it was a misunderstanding that went this way:
> 
>  * Someone wanted gitlab.debian.org.
>  * Someone pointed out that d.o services should be named by task, not
>    implementation.
>  * Someone figured that the task provided by gitlab is git hosting,
>    hence understood the above as a suggestion to use git.debian.org.

Let me rephrase, then: can we have a plan that addresses alioth / git /
gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool
because it's shiny?

This has more to do with delivering sustainable services while reducing the
overhead / technical debt.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian

Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

[Joachim Breitner]

Hi,

Am Mittwoch, den 08.06.2016, 10:21 +0100 schrieb Jonathan Dowland:
> On Tue, Jun 07, 2016 at 10:25:07AM +0530, Pirate Praveen wrote:
> > Thanks for the offer. It would be great if I have more hands to help with
> > migrating git.debian.org
> 
> Whoah there. Running an official Debian gitlab instance is one thing, 
> migrating
> git.debian.org is quite another. Did I miss where there was consensus on this?

it was a misunderstanding that went this way:

 * Someone wanted gitlab.debian.org.
 * Someone pointed out that d.o services should be named by task, not
   implementation.
 * Someone figured that the task provided by gitlab is git hosting,
   hence understood the above as a suggestion to use git.debian.org.
 * Someone concluded that therefore, we need to consider a migration
   from git.debian.org to gitlab.
 * And then, because git.debian.org is run by alioth, someone started
   talking about alioth.

The problem was between step 2 and 3.

Two suggestsions:

 * Consider gitlab.debian.org. Gitlab is not “just some implementation”
   that can be swapped for another, so it is ok to name the service
   according to that. Just like we have jenkings.debian.org.
 * If that is not acceptable, consider something like
   projects.debian.org
   as gitlab is about (git-centric) hosting of projects.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

signature.asc
Description: This is a digitally signed message part