Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)

[Jonathan Dowland]

I was wondering what the Gitlab proponent's thoughts are on how the Issue
tracker functionality of Gitlab should be used in a Debian context,
particularly in how it might intersect/interact/conflict with the BTS.


Thanks,

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

www.lists.debian.org

[Nicolas Grant | SunnySide Web Networks Pty Ltd]

Hi,


I hope you are well. I work for a fast growing online marketing agency in  
Melbourne.



I was doing some research on your industry and I landed on your-website.  
Thing is it was not from Page 1 of-Google!



I had a look at some of the other businesses who are currently ranked on  
Page 1 and I truly believe you have a better-website and a better brand.



I have created an-Website-Audit which addresses all of the technical and  
web errors on your-website that is stopping you from ranking on PAGE-1…



I am happy to send you this report for-FREE-with-no-charge-associated—

All I want is the chance to talk to you and discuss THE-WEBSITE-AUDIT in  
greater detail.



Please just reply to this mail with your phone number and either myself or  
one of our team will be in touch with you soon after.



Best Regards,


NICHOLAS GRANT | WEB-EXPERT


SunnySide Web-Networks Pty Ltd
We are totally awesome!!
Level 2, 496 La Trobe St
Melbourne VIC 3000 Australia
Sydney, Brisbane, Wellington, Auckland and Canberra

Re: Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)

[Antonio Terceiro]

On Fri, Jun 10, 2016 at 10:56:54AM +0100, Jonathan Dowland wrote:
> I was wondering what the Gitlab proponent's thoughts are on how the Issue
> tracker functionality of Gitlab should be used in a Debian context,
> particularly in how it might intersect/interact/conflict with the BTS.

Gitlab supports disabling issues (and other features like wiki, snippets
etc) on a per-project(repository) basis, as well as making them disabled
by default on new projects.

A Debian gitlab instance should probably be configured to disable issues
by default.

I would imagine/expect that all other alternatives mentioned in this
thread also support this.


signature.asc
Description: PGP signature

experimental syslog-ng

[Matt Zagrabelny]

Greetings,

It appears that the version of syslog-ng for mirrors of
ftp.us.debian.org's experimental repository is still at version
3.6.1+git20141206-g4d90138-4+b1, while tracker.d.o is reporting that
the experimental version is at 3.7.1-3, and has been since Thu, 08 Oct
2015 21:51:09 +0200.

At least the following mirrors' Packages.xz file shows the older
3.6.1+git version:

64.50.236.52 (OSU)
128.61.240.89 (GATech)
128.30.2.26 (MIT)

Any ideas why this is the case?

Thanks for any feedback!

-m

Re: Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)

[Henrique de Moraes Holschuh]

On Fri, 10 Jun 2016, Jonathan Dowland wrote:
> I was wondering what the Gitlab proponent's thoughts are on how the Issue
> tracker functionality of Gitlab should be used in a Debian context,
> particularly in how it might intersect/interact/conflict with the BTS.

You can enable/disable it per project, might be a good idea to leave it
enabled for upstream projects, and leave it disabled for debian package
projects.

Also, you can use external "issue trackers" in gitlab, and these are
also per-project.  It has special support for Redmine and Jira (one for
the Debian BTS would have to be written).  It has very limited support
for an email workflow in its native issue tracker.

I didn't check how well the native gitlab issue tracker would play with
the Debian BTS upstream forwarding.  But it is way more limited/simpler
than the Debian BTS.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: experimental syslog-ng

[Ansgar Burchardt]

Hi,

Matt Zagrabelny  writes:
> It appears that the version of syslog-ng for mirrors of
> ftp.us.debian.org's experimental repository is still at version
> 3.6.1+git20141206-g4d90138-4+b1, while tracker.d.o is reporting that
> the experimental version is at 3.7.1-3, and has been since Thu, 08 Oct
> 2015 21:51:09 +0200.
>
> At least the following mirrors' Packages.xz file shows the older
> 3.6.1+git version:

The package failed to build, see [1].

Ansgar

  [1] 

Re: experimental syslog-ng

[Matt Zagrabelny]

On Fri, Jun 10, 2016 at 2:46 PM, Ansgar Burchardt <"Ansgar
Burchardt"@43-1.org> wrote:

>> At least the following mirrors' Packages.xz file shows the older
>> 3.6.1+git version:
>
> The package failed to build, see [1].

Ahhh. Thanks!

-m

Re: Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)

[Robert Edmonds]

Jonathan Dowland wrote:
> I was wondering what the Gitlab proponent's thoughts are on how the Issue
> tracker functionality of Gitlab should be used in a Debian context,
> particularly in how it might intersect/interact/conflict with the BTS.

Also note that GitLab merge requests are numbered (I think the GitLab
markdown extension syntax is !1, !2, etc.), and it wouldn't be unlikely
to see such references in Debian changelogs.

-- 
Robert Edmonds
edmo...@debian.org

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Pirate Praveen]

On Wednesday 08 June 2016 11:10 PM, Alexander Wirt wrote:
> On Wed, 08 Jun 2016, Jonathan Dowland wrote:
> 
>> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote:
>>> I am also not very keen on using a system with a "open core / enterprise"
>>> model. For such a crucial service I would really prefer a real open source
>>> system. But maybe I am alone with that oppinion. 
>>
>> You are not alone, but please do not call Gitlab CE not "real open source".
> I do for every software which forces me to sign things like:
> https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md
> 
> Thats far away from what I call open source. I also don't want to end with
> things like: 
> 
> Debian needs feature X but it is already in the e.nterprise version. We make
> a patch and for commercial reasons it never gets merged (they already sell it
> in the enterprise version). Which means we will have to fork the software and
> keep those patches forever. Been there done that. For me, that isn't
> acceptable. 
> I don't want another Nagios. 

I agree this is a legitimate concern. I have asked Gitlab Inc for their
policy on merge requests to Gitlab CE for features already in Gitlab EE.
Based on their reply, we can decide how to proceed. If their reply is
positive, I will ask them to make it public, and we can go ahead with a
debian.net instance of Gitlab. If their reply is negative, we can drop
gitlab and consider Pagure (second best option).

> Alex 
> 




signature.asc
Description: OpenPGP digital signature