Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: Bug#970651: rollup: Unable to build with current tsc
On Tue, Sep 22, 2020 at 13:21, Xavier wrote: Looks good to me too. We could perhaps list the "bigger transitions" (nodejs, babel, bubble, rollup) Included a link to that page already :)
Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
Le 22/09/2020 à 13:10, Jonas Smedegaard a écrit : > Quoting Pirate Praveen (2020-09-22 13:03:53) >> >> >> On Mon, Sep 21, 2020 at 11:53, Jonas Smedegaard wrote: >>> If you simply mean a loose "don't break reverse dependencies!" and >>> write some suggestions down on a wiki page, then I fully agree: That >>> is common for Debian in general. What might be notable about >>> node.js is the likelyhood of complying with semantic versioning, and >>> it might be helpful to emphasize that in this team. >> >> I have started a wiki page by copying from ruby teams policy at >> https://wiki.debian.org/Javascript/Transitions/Policy >> >> Please go through and suggest if we need to change anything. >> >>> If you propose a formal screening process, then I am sceptical both >>> how to practically enforce that and whether it is the right >>> approach. >> >> ok, lets start with documenting our expectation and forget this option >> for now. If we see a lot of uploads not following the policy, we can >> think about this or other options later. > > Current wiki text looks fine to me. > > Thanks for driving this! > > - Jonas Looks good to me too. We could perhaps list the "bigger transitions" (nodejs, babel, bubble, rollup) Thanks !
Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
Quoting Pirate Praveen (2020-09-22 13:03:53) > > > On Mon, Sep 21, 2020 at 11:53, Jonas Smedegaard wrote: > > If you simply mean a loose "don't break reverse dependencies!" and > > write some suggestions down on a wiki page, then I fully agree: That > > is common for Debian in general. What might be notable about > > node.js is the likelyhood of complying with semantic versioning, and > > it might be helpful to emphasize that in this team. > > I have started a wiki page by copying from ruby teams policy at > https://wiki.debian.org/Javascript/Transitions/Policy > > Please go through and suggest if we need to change anything. > > > If you propose a formal screening process, then I am sceptical both > > how to practically enforce that and whether it is the right > > approach. > > ok, lets start with documenting our expectation and forget this option > for now. If we see a lot of uploads not following the policy, we can > think about this or other options later. Current wiki text looks fine to me. Thanks for driving this! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
On Mon, Sep 21, 2020 at 11:53, Jonas Smedegaard wrote: Quoting Pirate Praveen (2020-09-21 09:15:46) If you simply mean a loose "don't break reverse dependencies!" and write some suggestions down on a wiki page, then I fully agree: That is common for Debian in general. What might be notable about node.js is the likelyhood of complying with semantic versioning, and it might be helpful to emphasize that in this team. I have started a wiki page by copying from ruby teams policy at https://wiki.debian.org/Javascript/Transitions/Policy Please go through and suggest if we need to change anything. If you propose a formal screening process, then I am sceptical both how to practically enforce that and whether it is the right approach. ok, lets start with documenting our expectation and forget this option for now. If we see a lot of uploads not following the policy, we can think about this or other options later.
Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
Quoting Pirate Praveen (2020-09-21 09:15:46) > > > On 2020, സെപ്റ്റംബർ 21 3:37:01 AM IST, Jonas Smedegaard > wrote: > >> I think we should create a release team within js team to handle it > >> like how release team works for transitions. > > > >What do you mean more concretely? > > > >That only a smaller elite group should (approve) upload to unstable, > >and everyone else should upload only to experimental, or...? > > For major updates that has reverse dependencies, some one should > approve. It can even be anyone in the team and not just a fixed > smaller group. At least one other person should approve. > > The request should include if they ran autopkgtests and rebuilds of > affected packages and list any failed packages. > > It can even be auto approval in case no one objects in a week's time. > > The more important part is asking before upload, than who gets to > approve. We can document this in js team policy. > > Ruby team already documented it (expectations from people uploading > breaking changes) > https://wiki.debian.org/Teams/Ruby/Packaging#Updating_packages_with_API_breaking_changes If you simply mean a loose "don't break reverse dependencies!" and write some suggestions down on a wiki page, then I fully agree: That is common for Debian in general. What might be notable about node.js is the likelyhood of complying with semantic versioning, and it might be helpful to emphasize that in this team. If you propose a formal screening process, then I am sceptical both how to practically enforce that and whether it is the right approach. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
On 2020, സെപ്റ്റംബർ 21 3:37:01 AM IST, Jonas Smedegaard wrote: >> I think we should create a release team within js team to handle it >> like how release team works for transitions. > >What do you mean more concretely? > >That only a smaller elite group should (approve) upload to unstable, and >everyone else should upload only to experimental, or...? For major updates that has reverse dependencies, some one should approve. It can even be anyone in the team and not just a fixed smaller group. At least one other person should approve. The request should include if they ran autopkgtests and rebuilds of affected packages and list any failed packages. It can even be auto approval in case no one objects in a week's time. The more important part is asking before upload, than who gets to approve. We can document this in js team policy. Ruby team already documented it (expectations from people uploading breaking changes) https://wiki.debian.org/Teams/Ruby/Packaging#Updating_packages_with_API_breaking_changes > - Jonas > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
Quoting Pirate Praveen (2020-09-20 22:08:24) > > > On 2020, സെപ്റ്റംബർ 21 12:38:37 AM IST, Xavier Guimard > wrote: > >Package: rollup > >Version: 1.12.0-2 > >Severity: serious > >Tags: ftbfs > >Justification: Policy 7.7.7 > > > >node-rollup 1.12.0 can't be build with current typescript (4.0.2). It > >requires tsc 3.4.5 (tested with success). Output: > > I think the root cause is uploading major versions without > coordination. It should have been easily found out if all packages > using typescript was rebuilt before it was uploaded to unstable. I agree with the above. > I think we should create a release team within js team to handle it > like how release team works for transitions. What do you mean more concretely? That only a smaller elite group should (approve) upload to unstable, and everyone else should upload only to experimental, or...? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#970651: [Pkg-javascript-devel] Bug#970651: rollup: Unable to build with current tsc
Le 20/09/2020 à 22:08, Pirate Praveen a écrit : > > > On 2020, സെപ്റ്റംബർ 21 12:38:37 AM IST, Xavier Guimard > wrote: >> Package: rollup >> Version: 1.12.0-2 >> Severity: serious >> Tags: ftbfs >> Justification: Policy 7.7.7 >> >> node-rollup 1.12.0 can't be build with current typescript (4.0.2). It >> requires tsc 3.4.5 (tested with success). Output: > > I think the root cause is uploading major versions without coordination. It > should have been easily found out if all packages using typescript was > rebuilt before it was uploaded to unstable. > > I think we should create a release team within js team to handle it like how > release team works for transitions. +1
Bug#970651: [Pkg-javascript-devel] Bug#970651: rollup: Unable to build with current tsc
On 2020, സെപ്റ്റംബർ 21 12:38:37 AM IST, Xavier Guimard wrote: >Package: rollup >Version: 1.12.0-2 >Severity: serious >Tags: ftbfs >Justification: Policy 7.7.7 > >node-rollup 1.12.0 can't be build with current typescript (4.0.2). It >requires tsc 3.4.5 (tested with success). Output: I think the root cause is uploading major versions without coordination. It should have been easily found out if all packages using typescript was rebuilt before it was uploaded to unstable. I think we should create a release team within js team to handle it like how release team works for transitions. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#970651: rollup: Unable to build with current tsc
Package: rollup Version: 1.12.0-2 Severity: serious Tags: ftbfs Justification: Policy 7.7.7 node-rollup 1.12.0 can't be build with current typescript (4.0.2). It requires tsc 3.4.5 (tested with success). Output: $ tsc --esModuleInterop src/ModuleLoader.ts:59:3 - error TS2322: Type '(id: string) => boolean' is not assignable to type '(id: string, ...args: T) => boolean'. Types of parameters 'id' and 'id' are incompatible. Type '[id: string, ...args: T]' is not assignable to type '[id: string]'. Source has 2 element(s) but target allows only 1. 59 return id => ids.has(id); ~
