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 expe

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. This

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 solutions

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

On May 1, 2022 4:44:21 PM UTC, "Timo Röhling" wrote: >* Scott Kitterman [2022-04-29 23:32]: >> 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. >I thi

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

* Scott Kitterman [2022-04-29 23:32]: 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. I think this is a matter of perspective: for the FTP team, the upload

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 u

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 fil

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 th

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 Descripti

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 t

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 NE

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 r

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, bu

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 that

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 n

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

On Fri, 2022-04-29 at 11:26 -0400, Scott Kitterman wrote: > 1.  Making reject/prod emails more public: > > There are actually two different types of messages we can send while > reviewing > packages in DAK: > > a.  Reject: As indicated by the name, this is an email that accompanies the > pack

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?

On Friday, April 29, 2022 12:08:21 PM EDT Andreas Tille wrote: > Hi Scott, > > thanks a lot for becoming involved into this discussion. > > Am Fri, Apr 29, 2022 at 11:26:33AM -0400 schrieb Scott Kitterman: > > 2. Not rejecting packages with serious defects: > > > > I'm not sure I understand wha

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

Hi Scott, thanks a lot for becoming involved into this discussion. Am Fri, Apr 29, 2022 at 11:26:33AM -0400 schrieb Scott Kitterman: > 2. Not rejecting packages with serious defects: > > I'm not sure I understand what it proposed: > > > The ftpmasters could simply file severity serious bug rep

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 on NEW packages. >

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 >> feedback on NEW packages. >>

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 NEW packages would b

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 su

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 narrowly aimed at improvin

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 n

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, but I think

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 t

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 packages. > > Th

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 20

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 dis

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 which should smooth the up

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 u

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 more neutral page…) > >

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: > >> > > >> >> There have been a lot of complaints about it

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 pain to >> >> use. Its integration with gbp is poor, it p

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 a messy history when > >> you are wor

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 that's relevant for u

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 rpm

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 ma

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 inp

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 > > See m

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, the

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 patche

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 have

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 dgit-maint

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 wi

Re: Feedback on 3.0 source format problems

Le 07/01/2017 à 22:10, Nikolaus Rath a écrit : > 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 >> g

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 > I want to see only debian/

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. (

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 https://www.debian.

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 *

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 mai

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 the

Re: Feedback on 3.0 source format problems

On Wed, Jan 04, 2017 at 10:28:10PM +0100, Sebastian Andrzej Siewior wrote: > 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 about a quarter > > of a VCS. There are

Re: Feedback on 3.0 source format problems

Nikolaus Rath writes: >> I have had to sort out the mess when the Debian package upload >> did not match my git tree because another maintainer didn't correctly >> merge in my changes. > > I don't understand... how does a Debian package upload affect any of the > work on your git-dpm tree? I can

Re: Feedback on 3.0 source format problems

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 a messy history when >> you are working on your patches and I often run into problems with >> .debian/.git-dpm

Re: Feedback on 3.0 source format problems

Brian May writes: > No, my understanding that is git pq is something quite different, and > does not maintain the history of changes in git - except by commiting > the debian/patches/* files. It is a while since I looked at this in > depth however. That's correct. gbp pq is equivalent to mainta

Re: Feedback on 3.0 source format problems

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 a messy history when > you are working on your patches and I often run into problems with > .debian/.git-dpm file it maintains (import a new upstream

Re: Feedback on 3.0 source format problems

On Jan 04 2017, Vincent Bernat wrote: > ❦ 4 janvier 2017 09:47 -0800, Nikolaus Rath  : > >> It's surprisingly awkward, and, at least for me, it turns out that >> externalizing my rebased branch as a patch series solves many of >> problems surprisingly well. All the other solutions I

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 about a quarter > of a VCS. There are no formal interfaces to do proper VCS operations. > If there is a formal interface,

Re: Feedback on 3.0 source format problems

❦ 4 janvier 2017 09:47 -0800, Nikolaus Rath  : > It's surprisingly awkward, and, at least for me, it turns out that > externalizing my rebased branch as a patch series solves many of > problems surprisingly well. All the other solutions I can think of > require one or more thing

Re: Feedback on 3.0 source format problems

On Jan 04 2017, Vincent Bernat wrote: > ❦ 4 janvier 2017 04:52 GMT, Scott Kitterman  : > It's surprisingly awkward, and, at least for me, it turns out that externalizing my rebased branch as a patch series solves many of problems surprisingly well. All the other solutions I can t

Re: Feedback on 3.0 source format problems

On Wed, Jan 04, 2017 at 12:53:12PM +, Simon McVittie wrote: > Joking aside, the attempts I've seen at managing SRPMs in a version > control system have either not tracked upstream source at all (Fedora), or > invented a layout that is actually a lot like Debian's but with packaging/ > instead

Re: Feedback on 3.0 source format problems

On Wed, 04 Jan 2017 at 13:59:26 +0800, Paul Wise wrote: > On Wed, Jan 4, 2017 at 1:30 PM, 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

Re: Feedback on 3.0 source format problems

On January 4, 2017 6:23:23 AM EST, Jonas Smedegaard wrote: >Quoting Vincent Bernat (2017-01-04 08:12:08) >> ❦ 4 janvier 2017 04:52 GMT, Scott Kitterman > : >> >> >>> It's surprisingly awkward, and, at least for me, it turns out >that >> >>> externalizing my rebased branch as a patch series so

Re: Feedback on 3.0 source format problems

Russ Allbery writes ("Re: Feedback on 3.0 source format problems"): > Even if we never used tarballs, and instead our unit of operation was the > upstream Git repository plus Debian branches, I would maintain a rebased > branch of Debian changes to upstream I think this is d

Re: Feedback on 3.0 source format problems

Quoting Vincent Bernat (2017-01-04 08:12:08) > ❦ 4 janvier 2017 04:52 GMT, Scott Kitterman  : > > >>> It's surprisingly awkward, and, at least for me, it turns out that > >>> externalizing my rebased branch as a patch series solves many of > >>> problems surprisingly well. All the other solutio

Re: Feedback on 3.0 source format problems

❦ 4 janvier 2017 04:52 GMT, Scott Kitterman  : >>> It's surprisingly awkward, and, at least for me, it turns out that >>> externalizing my rebased branch as a patch series solves many of >>> problems surprisingly well. All the other solutions I can think of >>> require one or more things I don'

Re: Feedback on 3.0 source format problems

On Wed, Jan 4, 2017 at 1:30 PM, 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, because > this transformation could be trivially automated in either

Re: Feedback on 3.0 source format problems

On Jan 04 2017, Paul Wise wrote: > On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote: > >> I'm interested in what things people still find so off-putting to the >> point of not wanting to use the new 3.0 source formats. > > I've been reading this thread and keep being reminded of our > discussio

Re: Feedback on 3.0 source format problems

On January 3, 2017 10:22:22 PM EST, Nikolaus Rath wrote: >On Jan 03 2017, Russ Allbery wrote: >> It's surprisingly awkward, and, at least for me, it turns out that >> externalizing my rebased branch as a patch series solves many of >these >> problems surprisingly well. All the other solutions

Re: Feedback on 3.0 source format problems

On Tue, 2017-01-03 at 18:37 -0800, Russ Allbery wrote: > Even if we never used tarballs, and instead our unit of operation was > the upstream Git repository plus Debian branches, I would maintain a > rebased branch of Debian changes to upstream This is not a novel requirement. Most projects I've

Re: Feedback on 3.0 source format problems

On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote: > I'm interested in what things people still find so off-putting to the > point of not wanting to use the new 3.0 source formats. I've been reading this thread and keep being reminded of our discussion on #debian-dpkg a while ago. I think most

Re: Feedback on 3.0 source format problems

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 that's relevant for upstream development is > forwarded to upstream by the maintainer in whatever

Re: Feedback on 3.0 source format problems

On Jan 03 2017, Russ Allbery wrote: > It's surprisingly awkward, and, at least for me, it turns out that > externalizing my rebased branch as a patch series solves many of these > problems surprisingly well. All the other solutions I can think of > require one or more things I don't really want t

Re: Feedback on 3.0 source format problems

On Wed, Jan 4, 2017 at 2:54 AM, Russ Allbery wrote: > Well, if we had one more thing: a patches.debian.org service that would > show the git-debcherry-extracted patches against upstream. I really like > being able to just point upstream at all the patches relevant to them that > Debian has applie

Re: Feedback on 3.0 source format problems

On Jan 03 2017, Sean Whitton wrote: > Hello, > > On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote: >> > >> > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian' >> >> Yes, but that's not as useful as what git-debcherry produces. >> >> For example, if you get a merge conflict

Re: Feedback on 3.0 source format problems

gregor herrmann writes: > Personally I have the feeling that lots of these discussions and also > the creation of new tools (git-dpm, git-pq, git-debcherry, dgit) are > just workarounds for the actual problem: Many of us would like to work > in and with git but the whole infrastructure still revo

Re: Feedback on 3.0 source format problems

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 the git-debcherry-extracted patches against upstream. I really like > > being able to just p

Re: Feedback on 3.0 source format problems

On Mon, Jan 02, 2017 at 01:09:35PM -0800, Nikolaus Rath wrote: > On Jan 02 2017, Russ Allbery wrote: > > Furthermore, it forces a rebased, clean representation of the patches, > > which I for one hugely prefer to the mess that you get if someone was > > packaging in Git and just randomly commits t

Re: Feedback on 3.0 source format problems

Hello, On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote: > > > > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian' > > Yes, but that's not as useful as what git-debcherry produces. > > For example, if you get a merge conflict when rebasing, the above > incantation will lis

Re: Feedback on 3.0 source format problems

On Jan 03 2017, Nikolaus Rath wrote: > On Jan 03 2017, Sean Whitton wrote: >> Hello Russ, >> >> On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote: >>> Furthermore, it forces a rebased, clean representation of the patches, >>> which I for one hugely prefer to the mess that you get if so

Re: Feedback on 3.0 source format problems

On Jan 03 2017, Russ Allbery wrote: > Nikolaus Rath writes: > >> For example, if you get a merge conflict when rebasing, the above >> incantation will list two commits: the original debian commit and the >> merge commit. git-debcherry, on the other hand, will synthesize one >> patch, consisting o

Re: Feedback on 3.0 source format problems

Nikolaus Rath writes: > For example, if you get a merge conflict when rebasing, the above > incantation will list two commits: the original debian commit and the > merge commit. git-debcherry, on the other hand, will synthesize one > patch, consisting of the original Debian commit, but modified t

Re: Feedback on 3.0 source format problems

On Jan 03 2017, Sean Whitton wrote: > Hello Russ, > > On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote: >> Furthermore, it forces a rebased, clean representation of the patches, >> which I for one hugely prefer to the mess that you get if someone was >> packaging in Git and just random

Re: Feedback on 3.0 source format problems

Vincent Bernat writes ("Re: Feedback on 3.0 source format problems"): > 2 janvier 2017 01:45 -0800, Josh Triplett  : > > Personally, when I want to patch a random package, I run "debcheckout > > package-name", make changes, commit them, format-patch, [...] Re

  1   2   >