Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Quoting James Clarke (2017-05-22 16:25:38) > But I notice that for the sbuild path, schroot is completely missing, Maybe I should also point out that schroot is just the *default* sbuild chroot backend. It also supports the "sudo" mode (which essentially just uses "sudo chroot") and the

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Ian Jackson writes: > Use [dgit] to publish your git history, by doing your uploads with > dgit push. > > The root goal is this: Debian should publish the source for all our > packages, as git branches, in a format that is directly useable by > ordinary people.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On 22.05.2017 16:25, James Clarke wrote: > You say that, but this is incredibly biased. Even he admits that in the > colour choice. Disclaimer: as the cowbuilder maintainer (which comes > from the cow*dancer* source package, for historical reasons, despite > what the diagram may tell you) I am of

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Ben Finney writes ("Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"): > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > I want every maintainer who is using git to be able to use dgit. > > Use it

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Tue, May 23, 2017 at 06:34:09PM +0100, Sean Whitton wrote: > On Tue, May 23, 2017 at 06:38:29PM +0200, Emilio Pozuelo Monfort wrote: > > I have to deal with packages in svn, git-bp and plain git, and have started > > to > > write a set of (ugly) scripts that perform common actions in each of

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Ian Jackson writes: > I want every maintainer who is using git to be able to use dgit. Use it to do what, though? The package description is currently: git interoperability with the Debian archive dgit (with the associated infrastructure) makes it

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Tue, May 23, 2017 at 06:38:29PM +0200, Emilio Pozuelo Monfort wrote: > I have to deal with packages in svn, git-bp and plain git, and have started to > write a set of (ugly) scripts that perform common actions in each of those > formats, and a generic wrapper that calls the right one depending

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Tue, May 23, 2017 at 10:21:27AM +0100, Jonathan Dowland wrote: > On Mon, May 22, 2017 at 10:07:20PM +0100, James Clarke wrote: > > There already effectively is a semi-"primary" implementation given that > > sbuild is used on the buildds. > > Yes that is a very strong fact in favour of sbuild.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Jonathan Dowland writes: > Fair enough, cowbuilder was one of the ones in my hazy peripheral vision > as "another", along with some tools to use things like docker that I am > aware of but couldn't remember the names. None of them have the same > traction as pbuilder or sbuild.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Emilio Pozuelo Monfort writes ("Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"): > Besides, the sbuild/pbuilder duplicity is the least of your problems > in terms of multiple workflows, because once you choose one of those

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On 22/05/17 16:25, James Clarke wrote: > On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote: >> On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote: >>> Someone else already had this idea: >>> >>> https://people.debian.org/~stapelberg//2016/11/25/build-tools.html >> >>

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Sean Whitton writes ("Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"): > A way to set the version during the build, as you suggest, would be > sufficient to cover this. It is hard to see how we could relieve the &g

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Sean Whitton writes ("Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"): > On Mon, May 22, 2017 at 09:22:00PM +0100, Sean Whitton wrote: > > On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote: > > > Of

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 10:07:20PM +0100, James Clarke wrote: > There already effectively is a semi-"primary" implementation given that > sbuild is used on the buildds. Yes that is a very strong fact in favour of sbuild. > And as for making these "secondary" implementations not geared for real >

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 09:22:00PM +0100, Sean Whitton wrote: > On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote: > > Of course, dgit is yet another workflow and my understanding is that > > git-buildpackage (without dgit) is far more commonly used in Debian. > > This isn't fair to

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, 22 May 2017 22:20:29 +0200, Andreas Tille wrote: >On Mon, May 22, 2017 at 10:46:59PM +0500, Andrey Rahmatullin wrote: >> On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote: >> > there's just a hundred Debian workflows to maintain a package and 200 >> > manuals

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 05:10:26PM +0100, Jonathan Dowland wrote: > On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote: > > On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote: > > > Excellent, this is a great start, and seeing "Michael Stapelberg" for me > > > is an >

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 03:07:42PM +0100, Ian Jackson wrote: > Areas of work that could do with attention from people with relevant > expertise and effort: > > * Getting rid of the need to mess with the changelog. That might >involve changes to Debian changelog practice, or better tooling

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote: > Of course, dgit is yet another workflow and my understanding is that > git-buildpackage (without dgit) is far more commonly used in Debian. This isn't fair to dgit. While it does impose some minimal requirements upon git trees, it

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 10:46:59PM +0500, Andrey Rahmatullin wrote: > On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote: > > there's just a hundred Debian workflows to maintain a package and 200 > > manuals for that. > No, no, there are more workflows than manuals for them. For

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On 05/22/2017 07:42 PM, Jeremy Bicha wrote: > On Mon, May 22, 2017 at 10:07 AM, Ian Jackson > <ijack...@chiark.greenend.org.uk> wrote: >> Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away >> from (unsupportable) FusionForge on Alioth?)&q

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote: > there's just a hundred Debian workflows to maintain a package and 200 > manuals for that. No, no, there are more workflows than manuals for them. -- WBR, wRAR signature.asc Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 10:07 AM, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away > from (unsupportable) FusionForge on Alioth?)"): > I would encourage anyone who has effort to work on this

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote: > On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote: > > Excellent, this is a great start, and seeing "Michael Stapelberg" for me is > > an ^^^ > > indication of quality. emphasis on

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote: > On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote: > > Someone else already had this idea: > > > > https://people.debian.org/~stapelberg//2016/11/25/build-tools.html > > Excellent, this is a great start, and seeing

infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"): > I can totally confirm this. When people ask me how to get foo fixed in Debian > and I start explaining the above, people role their eyes and poi

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote: > Someone else already had this idea: > > https://people.debian.org/~stapelberg//2016/11/25/build-tools.html Excellent, this is a great start, and seeing "Michael Stapelberg" for me is an indication of quality. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 12:28:01PM +0200, Emilio Pozuelo Monfort wrote: > Do you mean cdbs rather than cmake? I'm struggling to make a connection > between > dh and cmake. Yes, I do; thanks for the correction. (although it does remind me that this issue of more-than-one-way-to-do-it extends up

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 10:29:24AM +0100, Jonathan Dowland wrote: > I often think about this problem, and I start to wonder if step 0 is to try > and > enumerate it properly. That is: I picture in my mind some kind of huge diagram > (perhaps generated from more structured data, I dunno, something

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On 22/05/17 11:29, Jonathan Dowland wrote: > I often think about this problem, and I start to wonder if step 0 is to try > and > enumerate it properly. That is: I picture in my mind some kind of huge diagram > (perhaps generated from more structured data, I dunno, something into a > graphviz) >

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

I often think about this problem, and I start to wonder if step 0 is to try and enumerate it properly. That is: I picture in my mind some kind of huge diagram (perhaps generated from more structured data, I dunno, something into a graphviz) of a landscape of debian developer tools, grouped by

infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

On Mon, May 22, 2017 at 07:52:34AM +, Riku Voipio wrote: > Right now, if you have a minor change - such fixing Homepage: or typo on > definition, it's not as straitforward as submitting a pull request. And > it gets much worse if you want to patch against upstream or build a new > upstream