Bug#1007717: Ballot and call for votes

2022-06-20 Thread Sean Whitton
Hello,

I hereby call for votes on the following resolution:

BEGIN BALLOT

Using its powers under constitution 6.1.5, the Technical Committee
issues the following advice:

  1. It is not a bug of any severity for a package with a non-native
 version number to use a native source package format.

  2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
 complain, when a non-native version number is used w/ 3.0 (native).

  3. We suggest that the wontfix tag on #737634 be reconsidered.

  4a. We believe that there are indeed circumstances in which
  1.0-with-diff is the best choice for a particular source package,
  including, but not limited to, git-first packaging workflows.

  This is because there is currently no other source format which is
  such that avoid both (i) uploading the whole source, including
  upstream, for every upload; and (ii) having to maintain
  debian/patches/ inside the package tree.

  4c. We believe that there are indeed circumstances in which
  1.0-with-diff is the best choice for a particular source package,
  including, but not limited to, git-first packaging workflows.
  However, we recommend discontinuing use of 1.0-with-diff in other
  circumstances, to simplify the contents of the archive.

  This is because ... [second paragraph as in 4a].

  5. We decline to comment on the recent source package format MBF.

Option A -- issue items 1-3, 4a and 5

Option C -- issue items 1-3, 4c and 5

Option X -- issue only items 1, 2, 3 and 5

Option N -- none of the above.

END BALLOT

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1007717: Ballot and call for votes

2022-06-20 Thread Sean Whitton
Hello,

On Mon 20 Jun 2022 at 05:31PM -07, Sean Whitton wrote:

> BEGIN BALLOT
>
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
>
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
>
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
>
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
>
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
>
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
>
>   This is because ... [second paragraph as in 4a].
>
>   5. We decline to comment on the recent source package format MBF.
>
> Option A -- issue items 1-3, 4a and 5
>
> Option C -- issue items 1-3, 4c and 5
>
> Option X -- issue only items 1, 2, 3 and 5
>
> Option N -- none of the above.
>
> END BALLOT

I vote

A > C > X > N

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1007717: Ballot and call for votes

2022-06-21 Thread Matthew Vernon

Hi,

On 21/06/2022 01:31, Sean Whitton wrote:

Hello,

I hereby call for votes on the following resolution:

BEGIN BALLOT

Using its powers under constitution 6.1.5, the Technical Committee
issues the following advice:

   1. It is not a bug of any severity for a package with a non-native
  version number to use a native source package format.

   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
  complain, when a non-native version number is used w/ 3.0 (native).

   3. We suggest that the wontfix tag on #737634 be reconsidered.

   4a. We believe that there are indeed circumstances in which
   1.0-with-diff is the best choice for a particular source package,
   including, but not limited to, git-first packaging workflows.

   This is because there is currently no other source format which is
   such that avoid both (i) uploading the whole source, including
   upstream, for every upload; and (ii) having to maintain
   debian/patches/ inside the package tree.

   4c. We believe that there are indeed circumstances in which
   1.0-with-diff is the best choice for a particular source package,
   including, but not limited to, git-first packaging workflows.
   However, we recommend discontinuing use of 1.0-with-diff in other
   circumstances, to simplify the contents of the archive.

   This is because ... [second paragraph as in 4a].

   5. We decline to comment on the recent source package format MBF.

Option A -- issue items 1-3, 4a and 5

Option C -- issue items 1-3, 4c and 5

Option X -- issue only items 1, 2, 3 and 5

Option N -- none of the above.

END BALLOT



I vote:

A > C > X > N

Thanks,

Matthew


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1007717: Ballot and call for votes

2022-06-22 Thread Gunnar Wolf
Hello,

Sean Whitton dijo [Mon, Jun 20, 2022 at 05:31:16PM -0700]:
> Hello,
> 
> I hereby call for votes on the following resolution:
> 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

My vote is:

A > C > X > N

Thanks!


signature.asc
Description: PGP signature


Bug#1007717: Ballot and call for votes

2022-06-22 Thread Simon McVittie
On Mon, 20 Jun 2022 at 17:31:16 -0700, Sean Whitton wrote:
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.

I vote C > A > X > N.

smcv


signature.asc
Description: PGP signature


Bug#1007717: Ballot and call for votes

2022-06-23 Thread Helmut Grohne
On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote:
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

I vote C > X > A > N.

Rationale

A key issue on this ballot to me is consistency of the archive. Given
that 1.0 source formats have mostly vanished, deprecating the remainder
is reasonable. While I would have liked a deprecation decision for all
1.0 formats in all cases, this is not project consensus yet and we're
taking a smaller step here. Meanwhile, this recommendation enables work
to continue getting rid of 1.0 formats. Since 4a can be read as an
endorsement, I prefer excluding it. The longer version is to be found in
the discussion mails.

Helmut


signature.asc
Description: PGP signature


Bug#1007717: Ballot and call for votes

2022-06-26 Thread Niko Tyni
On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote:
 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

I vote: C > A > X > N

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature


Bug#1007717: Ballot and call for votes

2022-06-26 Thread Elana Hashman
On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote:
> Hello,
> 
> I hereby call for votes on the following resolution:
> 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

I vote:

C > A > X > N

- e


signature.asc
Description: PGP signature


Bug#1007717: Ballot and call for votes

2022-06-27 Thread Christoph Berg
Re: Sean Whitton
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.

I vote: C > A > X > N

Christoph


signature.asc
Description: PGP signature