Re: feedback for NEW packages: switch to using the BTS?

Hello, On Sun 01 May 2022 at 07:52am +08, Paul Wise wrote: > On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote: > >> This would really slow things down; >> I don't think we could work that way. > > Using separate bug reports or not would of course be up to the person > filing them, but I

Re: feedback for NEW packages: switch to using the BTS?

On Sat, 30 Apr 2022, Paul Wise wrote: > I suppose debbugs could allow the package state to go out of sync with > NEW and instead retain the addresses for a certain period of time > after packages are removed from NEW and while there are open bugs on > the packages that were removed from NEW.

Re: feedback for NEW packages: switch to using the BTS?

What does it help to have it sitting there instead of rejected? I gave it more thought, and I don't think it has to be sitting in the NEW queue at all. As far as I understand it, the main advantage to gain is additional context; a bug report provides documentation and a place to discuss

Re: feedback for NEW packages: switch to using the BTS?

ocess. >The NEW queue is a mandatory review of their packaging effort, and >the REJECT is feedback which they will (hopefully) address, and then >try again. Maybe, in some circumstances, they will abandon the >package, but I'd say that this not typical. > >Converting the NEW

Re: feedback for NEW packages: switch to using the BTS?

is basically a stateless process; a package is either fit for inclusion in the archive or it is not. For the uploading DD, it is merely a particular (undesirable) state in the packaging process. The NEW queue is a mandatory review of their packaging effort, and the REJECT is feedback which

Re: feedback for NEW packages: switch to using the BTS?

Paul Wise left as an exercise for the reader: > I think the same problem and suggestions also apply with the current > system of prods and rejects, so please do add or propose adding it in > the appropriate documentation and templates. I will of course seek to > preserve these statements if I end

Re: feedback for NEW packages: switch to using the BTS?

On Sat, 2022-04-30 at 22:47 -0400, nick black wrote: > i understand. i suppose that what i'm saying is it will probably > be worthwhile to convey in Mentors etc. documentation that > "resolving the bugs filed thus far [regarding the package in > NEW] does not imply that no further bugs will be

Re: feedback for NEW packages: switch to using the BTS?

Paul Wise left as an exercise for the reader: > > if resolving the resulting bug report is the bar needing clearing to > > enter the archive, that does seem to require FTPmasters to create a > > complete statement of REJECT-worthy problems in each uploaded > > package, which seems like more work

Re: feedback for NEW packages: switch to using the BTS?

On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote: > This would really slow things down; > I don't think we could work that way. Using separate bug reports or not would of course be up to the person filing them, but I expect the process could be automated well enough that it wouldn't be much

Re: feedback for NEW packages: switch to using the BTS?

Hello, On Sat 30 Apr 2022 at 07:44AM +08, Paul Wise wrote: > It also means the ftpmasters can file separate bugs for each problem, > rather than combining them all into one mail. This would really slow things down; I don't think we could work that way. -- Sean Whitton signature.asc

Re: feedback for NEW packages: switch to using the BTS?

On Sat, 2022-04-30 at 03:09 -0400, nick black wrote: > currently, as far as i understand things, a REJECT can be issued > for the first REJECT-worthy problem. The same would occur under the proposal, except that there would presumably be separate bug reports for separate issues. > if resolving

Re: feedback for NEW packages: switch to using the BTS?

Paul Wise left as an exercise for the reader: > Packages with incomplete or incorrect debian/copyright information > currently would recieve a REJECT rather than acceptance. The proposal > would not change that, just turn that REJECT into a bug report, which > you could fix in a second upload to

Re: feedback for NEW packages: switch to using the BTS?

On Sat, 2022-04-30 at 00:13 +, Scott Kitterman wrote: > I'm still not understanding how any of that needs to have a package > we've decided not to accept sitting in New? My thinking is that debbugs would require a package (imported from new.822) to exist for maintainer addresses. If you file

Re: feedback for NEW packages: switch to using the BTS?

On April 29, 2022 11:44:54 PM UTC, Paul Wise wrote: >On Fri, 2022-04-29 at 23:32 +, Scott Kitterman wrote: > >> I don't understand why this is any better than just rejecting the >> package?  Once it's been determined that the upload won't be >> accepted, I don't see a benefit to having it

Re: feedback for NEW packages: switch to using the BTS?

On Fri, 2022-04-29 at 23:32 +, Scott Kitterman wrote: > I don't understand why this is any better than just rejecting the > package?  Once it's been determined that the upload won't be > accepted, I don't see a benefit to having it remain in New. The initial upload might not get an ACCEPT,

Re: feedback for NEW packages: switch to using the BTS?

On Fri, 2022-04-29 at 18:08 +0200, Andreas Tille wrote: > To give some actual examples that IMHO are candidates for accept + bug > report: Packages with incomplete or incorrect debian/copyright information currently would recieve a REJECT rather than acceptance. The proposal would not change

Re: feedback for NEW packages: switch to using the BTS?

On April 29, 2022 11:04:57 PM UTC, Paul Wise wrote: >On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote: > >> Just to clarify: is this suggesting that packages from NEW would end >> up in the archive even with serious bugs? If not, what's the point of >> the "eventual removal" above? I'm

Re: feedback for NEW packages: switch to using the BTS?

ective they > are and then remove them later if the bugs aren't fixed.  If that's what is > proposed, my thought is absolutely not. That is definitely *not* what was proposed, and I think it is a bad idea to accept packages that are not suitable for the archive. The proposal is simply to change

Re: feedback for NEW packages: switch to using the BTS?

On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote: > Just to clarify: is this suggesting that packages from NEW would end > up in the archive even with serious bugs? If not, what's the point of > the "eventual removal" above? I'm not following you here... No, the bugs I propose to be filed

Re: feedback for NEW packages: switch to using the BTS?

accept all packages regardless of how defective > > they are and then remove them later if the bugs aren't fixed. If that's > > what is proposed, my thought is absolutely not. > > > > If a package is not suitable for the archive then it should be rejected > > with appr

Re: feedback for NEW packages: switch to using the BTS?

t; proposed, my thought is absolutely not. > > If a package is not suitable for the archive then it should be rejected with > appropriate feedback and re-uploaded. To give some actual examples that IMHO are candidates for accept + bug report: 1. In case versioneer.py (Creative Commo

Re: feedback for NEW packages: switch to using the BTS?

On Wednesday, April 27, 2022 8:54:05 PM EDT Paul Wise wrote: > Hi all, > > During the discussions about NEW on debian-devel in recent times, I had > the idea that instead of the current mechanism of sending REJECT mails, > Debian could switch to using the BTS for most feedback

Re: feedback for NEW packages: switch to using the BTS?

On 2022-04-29 at 08:36, Steve McIntyre wrote: > Paul Wise wrote: > >> During the discussions about NEW on debian-devel in recent times, I >> had the idea that instead of the current mechanism of sending >> REJECT mails, Debian could switch to using the BTS for most >

Re: feedback for NEW packages: switch to using the BTS?

Paul Wise wrote: > >During the discussions about NEW on debian-devel in recent times, I had >the idea that instead of the current mechanism of sending REJECT mails, >Debian could switch to using the BTS for most feedback on NEW packages. > >This means that most discussion about

Re: feedback for NEW packages: switch to using the BTS?

Hi Paul, Am Fri, Apr 29, 2022 at 07:13:42AM +0800 schrieb Paul Wise: > > The packaging work is supposed to start *after* the ITP is filed, Sure. > so > this is a suboptimal order to do things in and doesn't provide much > value, The "packaging work" to create the debian/ dir is a 1min process

Re: feedback for NEW packages: switch to using the BTS?

On Thu, 2022-04-28 at 20:24 +0200, Andreas Tille wrote: > But filing an ITP bug is cheap.  The R-pkg team has a script > itp_from_debian_dir[1] which creates this bug automatically once the > packaging work is done. The packaging work is supposed to start *after* the ITP is filed, so this is a

Re: feedback for NEW packages: switch to using the BTS?

On Thu, 2022-04-28 at 13:48 +0200, Marco d'Itri wrote: > This looks like a good idea to me, but I think that the big problem > which needs to be solved is not discussing REJECTs but the packages > which stay in NEW for many months with no feedback. Thanks. The idea is narro

Re: feedback for NEW packages: switch to using the BTS?

Hi Paul, Am Thu, Apr 28, 2022 at 06:46:43PM +0800 schrieb Paul Wise: > There are two main categories of NEW packages; source and binary. > Packages adding an new source should have an ITP bug, but don't > always, for eg the Rust/Golang teams don't file them for every > library. Packages adding a

Re: feedback for NEW packages: switch to using the BTS?

On Apr 28, Paul Wise wrote: > During the discussions about NEW on debian-devel in recent times, I had > the idea that instead of the current mechanism of sending REJECT mails, > Debian could switch to using the BTS for most feedback on NEW packages. This looks like a good idea to me, bu

Re: feedback for NEW packages: switch to using the BTS?

On Thu, 2022-04-28 at 09:36 +0200, Andreas Tille wrote: > What about WNPP bug?  When I asked ftpmaster to kindly CC their > rejects to the WNPP bug I was told that not all packages in new have WNPP > bugs. If we want to formalise this it could probably be enforced that new > packages really need

Re: feedback for NEW packages: switch to using the BTS?

Hi Paul, Am Thu, Apr 28, 2022 at 08:54:05AM +0800 schrieb Paul Wise: > During the discussions about NEW on debian-devel in recent times, I had > the idea that instead of the current mechanism of sending REJECT mails, > Debian could switch to using the BTS for most feedback on NEW

feedback for NEW packages: switch to using the BTS?

Hi all, During the discussions about NEW on debian-devel in recent times, I had the idea that instead of the current mechanism of sending REJECT mails, Debian could switch to using the BTS for most feedback on NEW packages. This means that most discussion about NEW packages would become public

Re: Seeking feedback on a meta package builder

Hello, On Fri 04 Jun 2021 at 06:39PM +02, Helmut Grohne wrote: > Hi Sean, > > On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote: >> dgit wraps some of the existing tools. While dgit is mainly for humans, >> one role it can have in automated toolchains is producing an ephemeral >>

Re: Seeking feedback on a meta package builder

Hi, On Thu, 10 Jun 2021, Helmut Grohne wrote: > On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote: > > I want to know it precisely in the context of selecting a worker. I don't > > want to schedule a task on a worker and later get back an answer "sorry I > > can't handle your task",

Re: Seeking feedback on a meta package builder

Hi Raphaël, On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote: > I want to know it precisely in the context of selecting a worker. I don't > want to schedule a task on a worker and later get back an answer "sorry I > can't handle your task", and then have to schedule it on some

Re: Seeking feedback on a meta package builder

On Thu, Jun 10, 2021 at 8:01 AM Raphael Hertzog wrote: > > > > PS: I already hate the "mdbp" name after having it typed so many times. > > > > I'm not attached to either. Any suggestions? > > sbp for "standardized build package" is easier to type but not necessarily > nicer. > > "justadeb" or

Re: Seeking feedback on a meta package builder

Hi, On Tue, 08 Jun 2021, Helmut Grohne wrote: > With "look behind the abstraction", I think that you mean that debusine > would have to implement the mdbp api to perform worker selection. While > that would be possible indeed, I don't see this as required though. […] > I do wonder though, in what

Re: Seeking feedback on a meta package builder

On Tue, Jun 08, 2021 at 10:07:50PM +0200, Helmut Grohne wrote: > > PS: I already hate the "mdbp" name after having it typed so many times. > I'm not attached to either. Any suggestions? even medebupa seems better to me. (assuming mdbp is meta debian build package?) or meta-debuild or

Re: Seeking feedback on a meta package builder

Hi Raphaël, On Tue, Jun 08, 2021 at 12:05:44AM +0200, Raphael Hertzog wrote: > The point is that if you have to look behind the abstraction to do some > other related tasks like selecting the worker, then using the abstraction > to actually execute the build doesn't bring you much, just

Re: Seeking feedback on a meta package builder

Hi, On Mon, 07 Jun 2021, Helmut Grohne wrote: > My abstraction says nothing about workers or how to select them. The > idea behind that was that a user should not have to care. Yes, you > (debusine) do need a mapping between workers and available distributions > somewhere. You can implement

Re: Seeking feedback on a meta package builder

Hi Raphaël, Reading your reply makes me think there must be a misunderstanding. Much of what you write only makes sense to me that way. I hope my reply is not too repetitive and clears up some of that. On Sun, Jun 06, 2021 at 06:00:28PM +0200, Raphael Hertzog wrote: > I don't want to sound too

Re: Seeking feedback on a meta package builder

easiest and > > most useful first step for me. > > I doubt this is true. You already learned the hard way that coming up > with an abstraction for just sbuild is difficult. Using an existing > abstraction saves you from a pile of thinking and quite certainly is > easier. Th

Re: Seeking feedback on a meta package builder

Hi Sean, On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote: > dgit wraps some of the existing tools. While dgit is mainly for humans, > one role it can have in automated toolchains is producing an ephemeral > source package for the purpose of performing a build where the real > input

Re: Seeking feedback on a meta package builder

gt; I tried to fix it based on your feedback in the ticket but it looks like > it doesn't match your expectation. When I request a build for the "arm64" > architecture, I want "arm64.deb" as output, that's defined by the "host > architecture" right? Correct

Re: Seeking feedback on a meta package builder

t to choose suitable workers. It is only the > build architecture that affects worker choice. The host architecture is > only a setting to pass down and debusine does not have to care about it > at all. I tried to fix it based on your feedback in the ticket but it looks like it doesn't ma

Re: Seeking feedback on a meta package builder

sing? > * Does the problem scope I've chosen make sense? > * Feedback on the proposed API > * What feature is missing for your tool to use mdbp? > * Which build tools should mdbp support to make it useful to you? dgit wraps some of the existing tools. While dgit is mainly for humans, one ro

Re: Seeking feedback on a meta package builder

Hi Helmut, Quoting Helmut Grohne (2021-06-03 09:34:32) > On Thu, Jun 03, 2021 at 09:22:05AM +0200, Jonas Smedegaard wrote: > > And sure, a frontend wrapper tool may not need to care about some > > options, if possible to configure the backend independently. > > Thank you for putting this so

Re: Seeking feedback on a meta package builder

Hi Jonas, On Thu, Jun 03, 2021 at 09:22:05AM +0200, Jonas Smedegaard wrote: > And sure, a frontend wrapper tool may not need to care about some > options, if possible to configure the backend independently. Thank you for putting this so clearly. For now, I've been focussing on the interface

Re: Seeking feedback on a meta package builder

Quoting Helmut Grohne (2021-06-03 07:41:07) > On Wed, Jun 02, 2021 at 05:07:16PM +0200, Alex Muntada wrote: > > This reminded me of my using of ccache and eatmydata in sbuild. They > > may not be relevant for the context of mdbp depending on the > > resources available for building, indeed. > >

Re: Seeking feedback on a meta package builder

Hi Alex, On Wed, Jun 02, 2021 at 05:07:16PM +0200, Alex Muntada wrote: > This reminded me of my using of ccache and eatmydata in sbuild. > They may not be relevant for the context of mdbp depending on > the resources available for building, indeed. > > I'm pretty fond of them because they speed

Re: Seeking feedback on a meta package builder

Hi Helmut, > On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote: > > > Some aspects that you may want to set for a build are: Paul said: > What to run in the build environment at each stage. This reminded me of my using of ccache and eatmydata in sbuild. They may not be relevant for the

Re: Seeking feedback on a meta package builder

Hi Paul, On Tue, Jun 01, 2021 at 01:00:55AM +, Paul Wise wrote: > > Some aspects that you may want to set for a build are: > > Looking at my pbuilder configs, some more: Note that you are not a computer program. The thing I'm working on is not supposed to be run by humans, but by other

Re: Seeking feedback on a meta package builder

Hi Raphaël, On Wed, Jun 02, 2021 at 09:12:24AM +0200, Raphael Hertzog wrote: > On Mon, 31 May 2021, Helmut Grohne wrote: > > I see this tight coupling as a problem for mainly two reasons. > [...] > > * As tasks grow, there is a desire to distribute builds to multiple > >machines. As such,

Re: Seeking feedback on a meta package builder

Hi, On Mon, 31 May 2021, Helmut Grohne wrote: > I see this tight coupling as a problem for mainly two reasons. [...] > * As tasks grow, there is a desire to distribute builds to multiple >machines. As such, the various tools typically grow their own >strategy for moving build tasks

Re: Seeking feedback on a meta package builder

On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote: > Here are a number of lock-ins I happen to know: This was mentioned on IRC: cowpoke (from devscripts) -> remote cowbuilder -- bye, pabs https://wiki.debian.org/PaulWise

Re: Seeking feedback on a meta package builder

On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote: > When someone writes a tool, that happens to build packages as part of > its job (the earlier list), typically one of the build tools (the second > list) is chosen and fixed. It's not like you can mix and match them. > Here are a number of

Seeking feedback on a meta package builder

pe I've chosen make sense? * Feedback on the proposed API * What feature is missing for your tool to use mdbp? * Which build tools should mdbp support to make it useful to you? Thank you for considering. If you want to discuss on irc, I think both #debian-bootstrap and #debian-qa would be appropriate. Helmut

Bug#956682: ITP: feedbackd -- DBus service for haptic/visual/audio feedback

: DBus service for haptic/visual/audio feedback Feedbackd is a DBus activated daemon that provides haptic/visual/audio feedback based on events. It is a dependency to Phosh, a Wayland shell for mobile devices, which I also plan to package, and as such will be useful for bringing Debian to mobile

Bug#954035: ITP: qtfeedback-opensource-src -- Qt Feedback module

Programming Lang: C++ Description : Qt Feedback module Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. . This package contains Qt Feedback module. . This Qt module will be packaged under the umbrella

Re: Feedback request about the Alba Upstream to Debian packaging effort

On Sat, Jun 2, 2018 at 3:41 PM, PICCA Frederic-Emmanuel wrote: > The next meeting of this community will be held in Prague[4] next > week. During this meeting, Alba will present their plan about > packaging "Collaborative and automated Packaging"[5]. You might be interested in the autodeb GSoC

Re: Feedback request about the Alba Upstream to Debian packaging effort

(Hi. Sorry if you already got this message. There was some problem with my previous attempts to reply, so I am trying again after our email admin changed some settings) Hi, I work at the Alba Synchrotron and I authored the presentation that Frederic sent (thanks to him for initiating this

Re: Feedback request about the Alba Upstream to Debian packaging effort

PICCA Frederic-Emmanuel writes ("Feedback request about the Alba Upstream to Debian packaging effort"): > Since I am not at all a specialist of gitlab-ci, I would like your > advice on the pipeline, and also on the numbering scheme propose by > Alba. In fact all feedback

Feedback request about the Alba Upstream to Debian packaging effort

, and also on the numbering scheme propose by Alba. In fact all feedback which should smooth the upstream to debian flow. Thanks for considering. Frederic Ps: Please keep the CC, they are not yet subscribers of debian-devel [1] https://www.cells.es/en [2] http://www.tango-controls.org/ [3] http:/

Bug#895829: ITP: snore -- sleep with feedback

sleep with feedback This tool is similar to sleep(1), but visual feedback is given by printing the flowing of time in both ascending and descending order. This is useful as a generic countdown timer, or when sleep(1) is used in an interactive script.

Re: Feedback on 3.0 source format problems

On 01/04/2017 06:30 AM, Nikolaus Rath wrote: > But I am not sure if a package structure like > > mypkg/upstream/* > mypkg/debian/* > mypkg/patches/* (?) > > would have any *practical* benefits over the current situation It would have the huge benefit that upstream .git* files would stay in the

Bug#853014: ITP: visual-regexp-el -- in-buffer visual feedback while using Emacs regexps

: GPL-3+ Programming Lang: Emacs Lisp Description : in-buffer visual feedback while using Emacs regexps I intend to maintain this under pkg-emacsen. -- Sean Whitton signature.asc Description: PGP signature

Re: Feedback on 3.0 source format problems

Hi, On Sun, 01 Jan 2017, Guillem Jover wrote: > On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote: > > On Jan 01 2017, Guillem Jover wrote: > > > (I'm not using because > > > TBH it read more like a sales brochure than a

Re: Feedback on 3.0 source format problems

On Tue, Jan 10, 2017 at 10:14:09AM -0800, Nikolaus Rath wrote: > On Jan 10 2017, Guido Günther wrote: > > On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote: > >> On Jan 05 2017, Brian May wrote: > >> > Vincent Bernat writes: > >>

Re: Feedback on 3.0 source format problems

On Jan 10 2017, Guido Günther wrote: > On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote: >> On Jan 05 2017, Brian May wrote: >> > Vincent Bernat writes: >> > >> >> There have been a lot of complaints about it. For me, it is a

Re: Feedback on 3.0 source format problems

On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote: > On Jan 05 2017, Brian May wrote: > > Vincent Bernat writes: > > > >> There have been a lot of complaints about it. For me, it is a pain to > >> use. Its integration with gbp is poor, it produces

Re: Feedback on 3.0 source format problems

On Tue, Jan 03, 2017 at 07:24:18PM -0800, Russ Allbery wrote: > Nikolaus Rath writes: > > > Are there really upstreams that do that? I'd expect that the primary > > consumer of Debian patches are other distributions, downstreams, and > > users. > > > I'd think that anything

Re: Feedback on 3.0 source format problems

On Tue, Jan 10, 2017 at 08:36:13AM +1000, Russell Stuart wrote: > To state the bleeding obvious, it arises because on day 1 Debian > decided to do the builds in the original source tree, then tries to > recover the original source at the end by running "debian/rules clean". > When I moved from

Re: Feedback on 3.0 source format problems

Hi Mattia, Quoting Mattia Rizzolo (2017-01-09 11:27:30) > On Sun, Jan 08, 2017 at 01:05:37PM +0100, Johannes Schauer wrote: > > Mattia, please see below for a pbuilder-specific question. > > Thanks for CCing me; I'm not following this thread anymore (as it > surpassed the threshold above which I

Re: Feedback on 3.0 source format problems

On Mon, 2017-01-09 at 21:01 +0100, Johannes Schauer wrote: > Hi, > > Quoting Ian Jackson (2017-01-09 18:33:51) > > Johannes Schauer writes ("Re: Feedback on 3.0 source format problems"): > > > Sbuild could do this cleanup itself if there was a way to > > &g

Re: Feedback on 3.0 source format problems

On Mon, 2017-01-09 at 17:33 +, Ian Jackson wrote: > All of this applying and unapplying of patches around build > operations is complete madness if you ask me - but I don't see a > better approach given the constraints.  dgit sometimes ends up doing > this (and moans about it), which is even

Re: dput: Call for feedback: What should change? What should stay the same?

Barry Warsaw writes: > Unfortunately, the documentation you find on extending upload > permissions to DMs doesn't tell you that only dput-ng supports the dm > subcommand. Likewise, I'm having no luch finding comprehensive reference documentation for commands accepted by ‘dak’.

Re: dput: Call for feedback: What should change? What should stay the same?

On Dec 28, 2016, at 10:25 AM, Steve Langasek wrote: >Last I looked, the dcut command in dput doesn't support the 'dm' subcommand; >this led me to switching to dput-ng when I needed it. Same here, as I recently needed to `dcut dm` allow for a maintainer of a package I had been sponsoring while he

Re: Feedback on 3.0 source format problems

Hi, Quoting Ian Jackson (2017-01-09 18:33:51) > Johannes Schauer writes ("Re: Feedback on 3.0 source format problems"): > > Sbuild could do this cleanup itself if there was a way to > > automatically determine whether the user would like their tree to be > &g

Re: Feedback on 3.0 source format problems

On Mon, Jan 09, 2017 at 01:25:44PM +, Ian Jackson wrote: > Sean Whitton writes ("Re: Feedback on 3.0 source format problems"): > > My first worry is that pseudomerges are weird. In fact, I've never > > seen them outside of weird Debian git workflows

Re: Feedback on 3.0 source format problems

Johannes Schauer writes ("Re: Feedback on 3.0 source format problems"): > Sbuild could do this cleanup itself if there was a way to > automatically determine whether the user would like their tree to be > patches applied or unapplied. This would have to be some kind of (perha

Re: Feedback on 3.0 source format problems

Sean Whitton writes ("Re: Feedback on 3.0 source format problems"): > I take it that only the maintainer is meant to look at the > merging-baseline, and everyone else looks at the interchange view. Anyone wanting to look at the patch stack can look at the interchange view. git bl

Re: Feedback on 3.0 source format problems

On Sun, Jan 08, 2017 at 01:05:37PM +0100, Johannes Schauer wrote: > Mattia, please see below for a pbuilder-specific question. Thanks for CCing me; I'm not following this thread anymore (as it surpassed the threshold above which I stop to dedicate my time to it), so please CC me if you need my

Re: Feedback on 3.0 source format problems

Hello Ian, On Fri, Jan 06, 2017 at 03:29:38PM +, Ian Jackson wrote: > Sean Whitton writes ("Re: Feedback on 3.0 source format problems"): > > Could you explain in general terms the difference between the > > interchange and packaging-only branches >

Re: Feedback on 3.0 source format problems

On Sun, Jan 8, 2017 at 8:05 PM, Johannes Schauer wrote: > I'm not very familiar with pbuilder. Looking at the man page it seems that > pbuilder itself exclusively accepts a source package .dsc and for building a > source directory one needs the pdebuild wrapper? Right. > If that is the case,

Re: Feedback on 3.0 source format problems

Hi all, Mattia, please see below for a pbuilder-specific question. Quoting James Clarke (2017-01-08 12:14:07) > This turns out to be true. Working in a patches-applied tree: > > $ dpkg-source --before-build . > $ dpkg-source -b . > $ dpkg-source --after-build . > > leaves the

Re: Feedback on 3.0 source format problems

On Sun, Jan 08, 2017 at 01:53:51AM +0100, Johannes Schauer wrote: > Quoting Thibaut Paumard (2017-01-07 07:12:59) > > I manage my patches using quilt. I would really prefer if sbuild et al. > > would revert the patches after building by default, but that's life. I > > respect that other people

Re: Feedback on 3.0 source format problems

On Mon, 2017-01-02 at 12:36 +, Sean Whitton wrote: > Dear Josh, > > On Mon, Jan 02, 2017 at 03:25:29AM -0800, Josh Triplett wrote: > > Currently working on some improvements in that direction, to separate > > repository format from workflow. > > I'd like to encourage you to read my

Re: Feedback on 3.0 source format problems

Hi, Quoting Thibaut Paumard (2017-01-07 07:12:59) > I manage my patches using quilt. I would really prefer if sbuild et al. > would revert the patches after building by default, but that's life. I > respect that other people have other views. you could always file a wishlist bug against sbuild

Re: Feedback on 3.0 source format problems

re not quite happy (or quite unhappy?) with this format, but like often presumably people who *are* happy with the format will not speak up. I would not like the readers of the thread to come to the conclusion that the majority is unhappy with the format, because it's not a poll. My "Feedback

Re: Feedback on 3.0 source format problems

On Jan 07 2017, Thibaut Paumard wrote: > Well, just to say, I'm personally quite happy with '3.0 (quilt)'. I try > to maintain all my packages in git in unapplied state, because in my > opinion this is the sensible thing to do. When I do a > git diff upstream master >

Re: Feedback on 3.0 source format problems

Thibaut Paumard writes ("Re: Feedback on 3.0 source format problems"): > I'm not interested at the moment in dgit or other wrappers because > 1- they seem to me to add complexity to the process; > 2- I prefer to understand what I'm doing. Those are good reasons. (And I'm

Re: Feedback on 3.0 source format problems

Le 06/01/2017 à 16:37, Ian Jackson a écrit : > Sebastian Andrzej Siewior writes ("Re: Feedback on 3.0 source format > problems"): >> On 2017-01-03 16:58:21 [+], Ian Jackson wrote: >>> Looked at another way, it is trying to be a version control system, >>&

Re: Feedback on 3.0 source format problems

On Fri, 06 Jan 2017 15:37:48 +, Ian Jackson wrote: > I think only a minority of people are actually using quilt on > debian/patches. I have a different impression (but no proof either of course). Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer

Re: Feedback on 3.0 source format problems

Ian Jackson writes ("Re: Feedback on 3.0 source format problems"): > ! NMUer's HEAD was here when they said `dgit push'. > Rebase branch launderer turns each ! into an > equivalent *. I mean it turns each % into an equivalent *, but it w

Re: Feedback on 3.0 source format problems

Sebastian Andrzej Siewior writes ("Re: Feedback on 3.0 source format problems"): > On 2017-01-03 16:58:21 [+], Ian Jackson wrote: > > Looked at another way, it is trying to be a version control system, > > layered on top of the Debian archive. But it is only abo

Re: Feedback on 3.0 source format problems

Sean Whitton writes ("Re: Feedback on 3.0 source format problems"): > Could you explain in general terms the difference between the > interchange and packaging-only branches See modified diagram below. Are the annotations I have added (and the name change) any help ? > Does

Re: Feedback on 3.0 source format problems

Hi Sean, On Thu, Jan 05, 2017 at 01:05:54PM -0700, Sean Whitton wrote: > On Wed, Jan 04, 2017 at 03:10:16AM +0100, gregor herrmann wrote: > > https://sources.debian.net/patches/ goes in that direction. AFAIK it > > might not be complete and TTBOMK it hasn't been announced widely but > > it exists

Re: Feedback on 3.0 source format problems

Hello Ian, On Wed, Jan 04, 2017 at 12:08:57PM +, Ian Jackson wrote: > git-dpm sort of does this. I have been experimenting with and > blundering towards another approach, which is closer to raw git. > > Something like this: > >--/--A-/---B3---/--> interchange view >

Re: Feedback on 3.0 source format problems

Hello, On Tue, Jan 03, 2017 at 06:48:10PM -0800, Nikolaus Rath wrote: > I'd think that anything that's relevant for upstream development is > forwarded to upstream by the maintainer in whatever format upstream > prefers. This requires extra time, but I would be surprised to hear if > there are

Re: Feedback on 3.0 source format problems

Hello gregor, On Wed, Jan 04, 2017 at 03:10:16AM +0100, gregor herrmann wrote: > On Tue, 03 Jan 2017 20:15:10 +, Sean Whitton wrote: > > > On Tue, Jan 03, 2017 at 10:54:07AM -0800, Russ Allbery wrote: > > > Well, if we had one more thing: a patches.debian.org service that would > > > show

  1   2   3   >