Hi!
On 06.01.20 19:56, Alexander Wirt wrote:
> On Mon, 06 Jan 2020, Ulrike Uhlig wrote:
>>> On 28.12.19 18:16, Alexander Wirt wrote:
>> >From your replies to emails in this thread I was wondering: do you mean
>> that the Salsa team does not need, or does not want, help? Or does not
>> need, or wan
On Mon, 06 Jan 2020, Ulrike Uhlig wrote:
> Hi formorer,
>
> > On 28.12.19 18:16, Alexander Wirt wrote:
> >> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> >> I am sure there are many ways to help the team and it is not just
> >> about Salsa/Gitlab admin stuff, but also about creating structure in
Hi formorer,
> On 28.12.19 18:16, Alexander Wirt wrote:
>> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
>> I am sure there are many ways to help the team and it is not just
>> about Salsa/Gitlab admin stuff, but also about creating structure in
>> the team, triaging issues, spreading best practices
On Mon, 06 Jan 2020, Sam Hartman wrote:
> > "Alexander" == Alexander Wirt writes:
>
> Alexander> For everything else: we are working on it.
>
> I just want to confirm that part of the things that you are working on
> is documenting the issues. At a number of points you've talked about
> "Alexander" == Alexander Wirt writes:
Alexander> For everything else: we are working on it.
I just want to confirm that part of the things that you are working on
is documenting the issues. At a number of points you've talked about
how people are misunderstanding the issues or are th
On Wed, 01 Jan 2020, Otto Kekäläinen wrote:
> Hello!
>
> ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> > On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > > Also, if resources are an issue: I've offered several times to see if I
> > > can get some k8s resources for g
Hello!
ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > Also, if resources are an issue: I've offered several times to see if I
> > can get some k8s resources for gitlab runners, but never got a reply.
> > Not even a no.
On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
>
>
> On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> > I don't think that salsa-ci is particularly problematic in terms of
> > "efficiency". With the exception of the LXC usage, there's not much
> > that can be "cut" to save resources.
>
> Also, if reso
On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.
Also, if resources are an issue: I've offered several times to see if I
On Mon, 30 Dec 2019, Raphael Hertzog wrote:
> On Sat, 28 Dec 2019, Alexander Wirt wrote:
> > On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> >
> > > Hello!
> > >
> > > I've seen many times before statements like these so I'd like to raise
> > > some discussion around the topic:
> > >
> > > pe 13.
On Sat, 28 Dec 2019, Alexander Wirt wrote:
> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
>
> > Hello!
> >
> > I've seen many times before statements like these so I'd like to raise
> > some discussion around the topic:
> >
> > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoit
On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> Hello!
>
> I've seen many times before statements like these so I'd like to raise
> some discussion around the topic:
>
> pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartm
On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> I am sure there are many ways to help the team and it is not just
> about Salsa/Gitlab admin stuff, but also about creating structure in
> the team, triaging issues, spreading best practices for users and
> helping the most advanced users to grow into a
Hello!
I've seen many times before statements like these so I'd like to raise
some discussion around the topic:
pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > The Salsa CA pipeline is recommended.
>
> For
Hi!
On Wed, 2019-11-06 at 12:43:58 +, Simon McVittie wrote:
> On Tue, 05 Nov 2019 at 02:41:29 +0100, Guillem Jover wrote:
> > It does, it's specifically mentioned as a branch that will be
> > rewinded. See the “Branch management for next and pu after a feature
> > release” section.
>
> gitwor
On Tue, 05 Nov 2019 at 02:41:29 +0100, Guillem Jover wrote:
> It does, it's specifically mentioned as a branch that will be
> rewinded. See the “Branch management for next and pu after a feature
> release” section.
gitworkflows(7) describes how git.git works, as an example of the workflow
of a par
On Sun, 2019-09-15 at 12:23:48 +0200, Marc Haber wrote:
> On Sun, 15 Sep 2019 00:04:14 +0200, Guillem Jover wrote:
> > I think the common prefixes for these are pu/ and next/? These are
> > also documented somehow in the gitworkflows(7) man page.
>
> The definition of those prefixes doesn't contai
Matt Zagrabelny:
> On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz wrote:
>
>>
>>> There are a number of ways forward:
>>>
>>> [...]
>>> 5) Make no recommendations in this space
>>
>> Why do all things need a recommendation? List the possible places to
>> host a repository with their advantages/dis
On Sun, 15 Sep 2019, Jonas Meurer wrote:
> Sam Hartman:
> >> "Bastian" == Bastian Blank writes:
> >
> > Bastian> Hi Sam
> > Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > >> The Salsa CA pipeline is recommended.
> >
> > Bastian> For this I need to
On Sat, Sep 14, 2019 at 07:44:44PM +0200, Inaki Malerba wrote:
> On 13/9/19 15:20, Bastian Blank wrote:
> > For this I need to use my veto as Salsa admin. With the CI people we
> > have to work through too much problems first.
> If there are _too much problems_ I think you should, at least,
> comm
Matt Zagrabelny writes:
> On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz wrote:
>> Why do all things need a recommendation? List the possible places to
>> host a repository with their advantages/disadvantages. If somebody is
>> not able to decide where to put a package based on that, they might not
On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz wrote:
>
> > There are a number of ways forward:
> >
> >[...]
> > 5) Make no recommendations in this space
>
> Why do all things need a recommendation? List the possible places to
> host a repository with their advantages/disadvantages. If somebody is
On 9/10/19 3:26 AM, Sam Hartman wrote:
> I tried to cover the disadvantages of this in the original mail:
>
> * Works poorly when maintainership changes
Why? Its git. Press the fork button, select a destination, update
debian/control, be happy.
> * Works poorly when account status changes
Wh
On Friday, 13 September 2019 15:00:11 CEST gregor herrmann wrote:
> That's obviously an artifact of our poor Vcs-* information handling
> (in source packages); in reality, of course all of the 3600+
> perl-team packages are maintained on salsa.
For what it's worth, Vcs-Git info can be updated auto
On 9/15/19 9:57 AM, Bastian Blank wrote:
> [...]
> But basically the Salsa CI stuff needs to reduce the resource usage in
> various stages as Salsa simply lacks them.
I really hope that adding more resources is not the problem here, Debian
has some funds and also I'd expect people to offer k8s
Sam Hartman:
>> "Bastian" == Bastian Blank writes:
>
> Bastian> Hi Sam
> Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> >> The Salsa CA pipeline is recommended.
>
> Bastian> For this I need to use my veto as Salsa admin. With the CI
> Bastian> pe
Hi,
On 15/9/19 1:27 PM, Bastian Blank wrote:
>> Are there additional resources either the salsa admins or the salsa CI
>> team needs to move forward to a place where you'd both feel comfortable
>> recommending Salsa CI?
>
> We need to sit down and disuss between the admins first what we exactly
> "Sean" == Sean Whitton writes:
>>>
>>> I would already assume any branch prefixed with 'wip' might be
>>> rebased myself, but others might be surprised.
>>
>> I would like to have this documented somewhere so that people
>> dont get surprised. I am not particularly
On Sun, 15 Sep 2019 00:04:14 +0200, Guillem Jover
wrote:
>On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote:
>> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote:
>> > On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>> > > How about documenting that branches prefixed with "wip" can
On Sun, Sep 15, 2019 at 09:57:15AM +0200, Bastian Blank wrote:
> On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
> > Bastian> For this I need to use my veto as Salsa admin. With the CI
> > Bastian> people we have to work through too much problems first.
After thinking about i
On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
> Bastian> For this I need to use my veto as Salsa admin. With the CI
> Bastian> people we have to work through too much problems first.
> What I am hearing you say is that right now, as service admins, you
> cannot support the C
Anthony DeRobertis writes:
> On 9/12/19 8:57 AM, Ansgar wrote:
>> I don't see much value in this requirement (besides additional work).
>> One should look at the repository anyway whan planning to do changes
>> (to match the existing style used); one would naturally see how files
>> are organized.
On 9/12/19 8:57 AM, Ansgar wrote:
I don't see much value in this requirement (besides additional work).
One should look at the repository anyway whan planning to do changes
(to match the existing style used); one would naturally see how files
are organized. We already had tons of packages shippi
On Sun, 2019-09-15 at 00:37:00 +0530, Pirate Praveen wrote:
> On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen
> wrote:
> > I guess because according to https://trends.debian.net/#vcs-hosting
> > there's *still*, today, almost 1 source packages in unstable which
> > declare they are main
On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote:
> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote:
> > On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
> > > How about documenting that branches prefixed with "wip" can be force
> > > pushed any time and people pulling from those b
On Thu, Sep 12, 2019 at 02:57:09PM +0200, Ansgar wrote:
> (Using dgit to upload packages is sadly incompatible with best
> practices around packaging.)
I'm genuinly curious: why do you say so? Which practices does it
violate?
--
cheers,
Holger
--
On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen
wrote:
>On Fri, Sep 13, 2019 at 11:30:51AM +0530, Pirate Praveen wrote:
>> On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber
> wrote:
>> >alioth.debian.org, anyone? That one went away pretty fast.
>> I wonder why people keep repeating this.
On Fri, Sep 13, 2019 at 11:30:51AM +0530, Pirate Praveen wrote:
> On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber
> wrote:
> >alioth.debian.org, anyone? That one went away pretty fast.
> I wonder why people keep repeating this.
I guess because according to https://trends.debian.net/#vcs-hosti
On 13/9/19 15:20, Bastian Blank wrote:
> For this I need to use my veto as Salsa admin. With the CI people we
> have to work through too much problems first.
If there are _too much problems_ I think you should, at least,
communicate with us.
Besides two issues[0][1] reported some time ago -which
Hello,
On Sat 14 Sep 2019 at 01:07PM +02, Marc Haber wrote:
> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton
> wrote:
>>On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>>> How about documenting that branches prefixed with "wip" can be force
>>> pushed any time and people pulling from thos
On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton
wrote:
>On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>> How about documenting that branches prefixed with "wip" can be force
>> pushed any time and people pulling from those branches should be
>> expected to handle that?
>
>This would be use
Hello,
On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
> How about documenting that branches prefixed with "wip" can be force
> pushed any time and people pulling from those branches should be
> expected to handle that?
This would be useful.
I would already assume any branch prefixed with
> "Bastian" == Bastian Blank writes:
Bastian> Hi Sam
Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
>> The Salsa CA pipeline is recommended.
Bastian> For this I need to use my veto as Salsa admin. With the CI
Bastian> people we have to work through
Hi Sam
On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> The Salsa CA pipeline is recommended.
For this I need to use my veto as Salsa admin. With the CI people we
have to work through too much problems first.
I don't have anything else to add for now.
Bastian
--
Totally illogic
Le Vendredi, Septembre 13, 2019 15:00 CEST, gregor herrmann
a écrit:
> On Thu, 12 Sep 2019 08:14:13 -0400, Sam Hartman wrote:
>
> > I did do a bit of looking at data.
> > In my unstable sources.list, there are 17863 source packages that
> > include salsa.debian.org in the vcs-git. Of those, 2192
On Thu, 12 Sep 2019 08:14:13 -0400, Sam Hartman wrote:
> I did do a bit of looking at data.
> In my unstable sources.list, there are 17863 source packages that
> include salsa.debian.org in the vcs-git. Of those, 2192 are in the
> debian group.
> That's the largestsingle group; perl-team (next) c
On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber
wrote:
>alioth.debian.org, anyone? That one went away pretty fast.
I wonder why people keep repeating this. This was migrated to salsa and also
archived, so nothing was lost. This was a planned move to a better solution
(gforge was unmaintai
On Thu, 2019-09-12 at 15:37:49 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Git Packaging Round 2: When to Salsa"):
> > (Using dgit to upload packages is sadly incompatible with best
> > practices around packaging.)
>
> Using dgit to upload packages is best
On Sun, 08 Sep 2019 22:05:17 -0700, Russ Allbery
wrote:
>Sean Whitton writes:
>> On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:
>
>>> You are encouraged to mirror your repository to Salsa so that people can
>>> find more of the Debian packaging in one place.
>
>> Hmm, if the Vcs-* are set
On Sun, 08 Sep 2019 17:35:10 -0400, Sam Hartman
wrote:
>* Use a public repository where in-progress and ongoing work are
> available to the public. Do not just push when you release.
I would liket to have a recommendation about git push --force in that
case. I frequently do rebase --interactive
Ansgar writes ("Re: Git Packaging Round 2: When to Salsa"):
> If dgit provides a program to figure this out, people interested in
> obtaining the information automatically can just extract and use that.
It is not possible to figure out the branch format automatically
given jus
Sam Hartman writes:
>> "Ansgar" == Ansgar writes:
>
> Ansgar> On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote:
> Ian> 1. The maintainer's git repository branch format must be
> Ian> documented. Otherwise another contributor has to guess. This
> Ian> could be done eith
> "Ansgar" == Ansgar writes:
Ansgar> On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote:
Ian> 1. The maintainer's git repository branch format must be
Ian> documented. Otherwise another contributor has to guess. This
Ian> could be done either by doing maintainer uploads w
On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote:
> Ian> 1. The maintainer's git repository branch format must be
> Ian> documented. Otherwise another contributor has to guess. This
> Ian> could be done either by doing maintainer uploads with dgit
> Ian> (since recent versions
Sam Hartman writes:
>
> I did do a bit of looking at data.
> In my unstable sources.list, there are 17863 source packages that
> include salsa.debian.org in the vcs-git. Of those, 2192 are in the
> debian group.
> That's the largestsingle group; perl-team (next) comes in at 1417.
>
> The debian g
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments ---
Ian> ...
>> I realize that not everyone wants all developers to have push
>> access to their packages. If you have a firm idea about
Ian Jackson writes:
> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments
>> ---
> ...
>> I realize that not everyone wants all developers to have push access to
>> their packages. If you have a firm idea about that, then this
>> recommendation is
> "David" == David Bremner writes:
l reaction,
David> but I'm not currently very comfortable with any DD being able
David> to make global changes to thousands of git repos. I think we
David> haven't yet developed any kind of social conventions or rules
David> about when that i
Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
> Discussion Comments
> ---
...
> I realize that not everyone wants all developers to have push access to
> their packages. If you have a firm idea about that, then this
> recommendation is not for you. I also realize th
On Tue, Sep 10, 2019 at 08:13:15AM -0300, David Bremner wrote:
> I'm also not sure if this is a completely rational reaction, but I'm not
> currently very comfortable with any DD being able to make global changes
> to thousands of git repos. I think we haven't yet developed any kind of
> social co
On September 10, 2019 10:12:39 AM UTC, Sam Hartman wrote:
>> "Scott" == Scott Kitterman writes:
>
>
>Scott> I don't think your alleged works poorly for using your own
>Scott> namespace are real problems.
>
>I would be a lot happier if your message was phrased in terms of
>discussin
Russ Allbery writes:
> 3. Anyone who comes from a tech company / Silicon Valley development
>environment is probably going to already be used to this style of
>collective ownership (along with politeness conventions about not
>messing with other people's stuff unless you have talked t
Quoting Russ Allbery (2019-09-10 03:50:47)
> I think using the debian namespace is the right default, particularly
> when we view it through the lens of what's best for the project.
>
> Think of it this way: we have a new Debian package maintained by
> someone who's maybe new to the project. Wh
> "Scott" == Scott Kitterman writes:
Scott> I don't think your alleged works poorly for using your own
Scott> namespace are real problems.
I would be a lot happier if your message was phrased in terms of
discussing which trade off you prefer.
It's clear from past discussion that peo
On September 10, 2019 1:26:35 AM UTC, Sam Hartman wrote:
>> "David" == David Bremner writes:
>
>David> Sam Hartman writes:
>>>> "Jonas" == Jonas Smedegaard writes:
>>>
>>>
> Jonas> I think there is a general consensus on working in teams, and
> Jonas> therefore
Sam Hartman writes:
> There are a number of ways forward:
> 1) Add a recommendation for people who don't want to give push access to
> all developers. Personal namespaces is the only option I've seen so
> far.
> 2) Only recommend personal namespaces and never debian
> 3) Note both options but
> "David" == David Bremner writes:
David> Sam Hartman writes:
>>> "Jonas" == Jonas Smedegaard writes:
>>
>>
Jonas> I think there is a general consensus on working in teams, and
Jonas> therefore using git repos belonging to teams - but not to use
Jonas> that
Sam Hartman writes:
>> "Jonas" == Jonas Smedegaard writes:
>
>
> Jonas> I think there is a general consensus on working in teams, and
> Jonas> therefore using git repos belonging to teams - but not to use
> Jonas> that one giant "team" called "debian".
>
> What would you recommen
> "Jonas" == Jonas Smedegaard writes:
Jonas> I think there is a general consensus on working in teams, and
Jonas> therefore using git repos belonging to teams - but not to use
Jonas> that one giant "team" called "debian".
What would you recommend people do if they have a package
Quoting Sam Hartman (2019-09-09 19:49:25)
> > "Ansgar" == Ansgar writes:
>
> Ansgar> Sam Hartman writes:
> >> If you are a Debian Developer packaging a package for inclusion
> >> in Debian, you should store your packaging information in one
> >> repository per package on sals
> "Ansgar" == Ansgar writes:
Ansgar> Sam Hartman writes:
>> If you are a Debian Developer packaging a package for inclusion
>> in Debian, you should store your packaging information in one
>> repository per package on salsa.debian.org in the debian group.
>> That is you s
Sam Hartman writes:
> If you are a Debian Developer packaging a package for inclusion in
> Debian, you should store your packaging information in one repository
> per package on salsa.debian.org in the debian group. That is you should
> create a repository under https://salsa.debian.org/debian .
Geert Stappers writes:
> On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote:
>> Higher chance that the repository won't go away.
>
> Where is Alioth? As retoric question.
The repositories on Alioth weren't lost and can still be found archived
on https://alioth-archive.debian.org/
>
On Mon, Sep 09, 2019 at 10:22:03AM +0100, Nikolaus Rath wrote:
> On Sep 08 2019, Sam Hartman wrote:
> > Hopefully you will choose to monitor merge requests for your
> > repository. If not, turn off merge requests.
>
> Monitor *and respond to* might be a better phrasing..?
I don't think I can pr
On Sep 08 2019, Sam Hartman wrote:
> Hopefully you will choose to monitor merge requests for your
> repository. If not, turn off merge requests.
Monitor *and respond to* might be a better phrasing..?
Best,
Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote:
> Sean Whitton writes:
> > On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:
>
> >> You are encouraged to mirror your repository to Salsa so that people can
> >> find more of the Debian packaging in one place.
>
> > Hmm, if the Vc
Sean Whitton writes:
> On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:
>> You are encouraged to mirror your repository to Salsa so that people can
>> find more of the Debian packaging in one place.
> Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
> salsa? (I don't o
Hello,
On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:
> You are encouraged to mirror your repository to Salsa so that people can
> find more of the Debian packaging in one place.
Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
salsa? (I don't object in the least; ju
78 matches
Mail list logo