On 2019, മാർച്ച് 3 10:45:19 PM IST, Justin Hallett
wrote:
>Well I hope it comes to that personally, cause I think you have been
>doing a great job, it’s a TON of work to maintain all the depends you
>do for gitlab and honestly there are rarely issues and when they are
>you fix them very
Well I hope it comes to that personally, cause I think you have been doing a
great job, it’s a TON of work to maintain all the depends you do for gitlab and
honestly there are rarely issues and when they are you fix them very quickly
after a report.
It’s very upsetting that I now have 10
On Mon, 25 Feb 2019 07:45:36 -0700 Justin Hallett
wrote:
> This ticket is bogus and should be closed and removed so that gitlab can be
> fixed in testing and restore the faith of its users.
I think we have not received the same level of respect from the rest of the
project. Since everyone is
On Mon, 25 Feb 2019 07:45:36 -0700 Justin Hallett
wrote:
> By keeping this out of testing you are really leaving those of us running it
> and depending on it in a real mess. To get rails 2.5 support I had to do
> some serious Debian badness, this really sucks, couldn’t it just be kept out
>
By keeping this out of testing you are really leaving those of us running it
and depending on it in a real mess. To get rails 2.5 support I had to do some
serious Debian badness, this really sucks, couldn’t it just be kept out of
backports if that is the issue instead of causing harm to those
On Wed, 19 Dec 2018 00:55:39 +0100 Dominik George
wrote:
> >> We had volatile, which, redefined properly, could help. I am trying
> >to draft such a definition.
> >
> >Did you get a chance to work on it?
>
> I do have this on my todo list for around Christmas.
>
> People who know me that I
>> We had volatile, which, redefined properly, could help. I am trying
>to draft such a definition.
>
>Did you get a chance to work on it?
I do have this on my todo list for around Christmas.
People who know me that I deliberately leave out the year, but my intentions
are 2018 ;).
-nik
On Wednesday, 19 December 2018 9:17:51 AM AEDT Thorsten Glaser wrote:
> Did you mean: in an unstable-like “volatile” repo?
Yes perhaps more like "unstable".
I'm saying that IMHO we should have only one common/shared "PPA" for "stable"
users. I do not want many personal/individual archives.
>
On Wed, 19 Dec 2018, Dmitry Smirnov wrote:
> trust - a something we can only have in backports-like "volatile" repo.
Did you mean: in an unstable-like “volatile” repo?
Backports have a defined mission, which has nothing to do
with the “volatile” proposal. What you were referring to,
On Wednesday, 19 December 2018 2:11:43 AM AEDT Holger Levsen wrote:
> instead of volatile we need PPAs.
I think concept of "volatile" is better, stronger.
PPA allows people to ship whatever they want without cooperating in policy
compliant (official) repo. This is the Debian way where many
On 12/18/18 8:41 PM, Holger Levsen wrote:
> On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote:
>> But if that is not possible, volatile as a separate archive is also fine.
>
> instead of volatile we need PPAs.
I think a redefined volatile is the best option for sharing work. But
On Tue, Dec 18, 2018 at 10:12 AM Holger Levsen wrote:
> On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote:
> > But if that is not possible, volatile as a separate archive is also fine.
>
> instead of volatile we need PPAs.
Shortly before the Stretch release, when I was scrambling to
On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote:
> But if that is not possible, volatile as a separate archive is also fine.
instead of volatile we need PPAs.
--
cheers,
Holger
---
On 2018, ഡിസംബർ 18 7:14:14 PM IST, Rhonda D'Vine wrote:
> And yes, I'm with Alexander, the volatile maintenance can't be dumped
>on the backports team. It's a different workflow anyway.
My proposal for backports is to have only the dependencies of packages in
volatile that fall in the
Hey,
* Pirate Praveen [2018-12-18 09:34:46 CET]:
> On 12/3/18 8:11 PM, Dominik George wrote:
> >> well, Debian is using gitlab!!! so this sentence has no sense. The
> >> problem here
> >> is that is a complex software that depends of a lot of pieces and it's
> >> not
> >> easy/possible to
On Tue, 18 Dec 2018, Pirate Praveen wrote:
> [adding -devel to cc]
>
> On 12/3/18 8:11 PM, Dominik George wrote:
> >> well, Debian is using gitlab!!! so this sentence has no sense. The
> >> problem here
> >> is that is a complex software that depends of a lot of pieces and it's
> >> not
> >>
[adding -devel to cc]
On 12/3/18 8:11 PM, Dominik George wrote:
>> well, Debian is using gitlab!!! so this sentence has no sense. The
>> problem here
>> is that is a complex software that depends of a lot of pieces and it's
>> not
>> easy/possible to fit the definition. So, maybe we should create
On Thu, 29 Nov 2018 20:59:59 +0100 Moritz Muehlenhoff
wrote:
> Source: gitlab
> Severity: serious
>
> Gitlab is too fast-moving with weekly releases and backporting security fixes
> has already
> failed us for stretch, keep it out of testing.
Just a clarification, major release happens every
On 2018, ഡിസംബർ 3 8:11:58 PM IST, Dominik George
wrote:
>We had volatile, which, redefined properly, could help. I am trying to
>draft such a definition.
Thanks, that is required to keep gitlab in a supportable form (unstable
directly is not the best option).
I think an Ubuntu PPA like
>well, Debian is using gitlab!!! so this sentence has no sense. The
>problem here
>is that is a complex software that depends of a lot of pieces and it's
>not
>easy/possible to fit the definition. So, maybe we should create another
>category
>of software.
Yes, and that Debian officially uses
El 30/11/18 a les 15:16, Thorsten Glaser ha escrit:
> On Fri, 30 Nov 2018, Pirate Praveen wrote:
>
>> That is indeed the current definition. The question is about the
>> possibility of changing that definition or finding other ways to
maybe creating another kind of repo. debian-contributuions
On Fri, Nov 30, 2018 at 06:01:26PM +0200, Jan Groenewald wrote:
> Hi
>
> On Fri, 30 Nov 2018 at 16:43, Holger Levsen wrote:
>
> On Fri, Nov 30, 2018 at 07:39:20PM +0530, Pirate Praveen wrote:
> > >Backports are *always* from testing because a backport is
> > >supposed to be replaced
On Fri, 30 Nov 2018 18:01:26 +0200
Jan Groenewald wrote:
> There is https://packages.gitlab.com/gitlab/gitlab-ce
>
> (deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ stretch main)
Sorry, but no. Just no, no, no and no. Those binary dumps are horrible. They
are essentially just
Hi
On Fri, 30 Nov 2018 at 16:43, Holger Levsen wrote:
> On Fri, Nov 30, 2018 at 07:39:20PM +0530, Pirate Praveen wrote:
> > >Backports are *always* from testing because a backport is
> > >supposed to be replaced by the regular stable version of
> > >the subsequent release.
> > That is indeed
On Fri, Nov 30, 2018 at 07:39:20PM +0530, Pirate Praveen wrote:
> >Backports are *always* from testing because a backport is
> >supposed to be replaced by the regular stable version of
> >the subsequent release.
> That is indeed the current definition.
Me too is very happy with it.
> Another
On Fri, 30 Nov 2018, Pirate Praveen wrote:
> That is indeed the current definition. The question is about the
> possibility of changing that definition or finding other ways to
No. It’s there for good reasons, including stability.
> accommodate fast changing software like gitlab. Broadening the
On 2018, നവംബർ 30 5:14:20 PM IST, Thorsten Glaser wrote:
>On Fri, 30 Nov 2018, Pirate Praveen wrote:
>
>> How about allowing gitlab to be backported directly from unstable?
>
>No.
>
>Backports are *always* from testing because a backport is
>supposed to be replaced by the regular stable
On Fri, 30 Nov 2018, Pirate Praveen wrote:
> How about allowing gitlab to be backported directly from unstable?
No.
Backports are *always* from testing because a backport is
supposed to be replaced by the regular stable version of
the subsequent release. Hence, only from testing, in the
hope
On 2018, നവംബർ 30 1:29:59 AM IST, Moritz Muehlenhoff wrote:
>Source: gitlab
>Severity: serious
>
>Gitlab is too fast-moving with weekly releases and backporting security
>fixes has already
>failed us for stretch, keep it out of testing.
>
>To meaningfully support it for use on stable, this
Source: gitlab
Severity: serious
Gitlab is too fast-moving with weekly releases and backporting security fixes
has already
failed us for stretch, keep it out of testing.
To meaningfully support it for use on stable, this would require some of the
infrastructure/policy changes discussed in the
30 matches
Mail list logo
