On Mon, 27 Jun 2022 09:23:25 -0700 Sean Whitton
wrote:
> With three first preference votes for A and five first preference votes
> for C, the outcome is no longer in doubt. Therefore, using its powers
> under constitution 6.1.5, the Technical Committee issues the following
> advice:
>
> 1. It i
With three first preference votes for A and five first preference votes
for C, the outcome is no longer in doubt. Therefore, 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
ve
Hello,
On Tue 29 Mar 2022 at 09:06PM +02, Lucas Nussbaum wrote:
> On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
>>
>> I don't think it's the preferred method. I believe most of the project
>> sees git histories are the preferred tool for achieving the goal you
>> state.
>>
>> If we had only so
On Tue, Mar 15, 2022 at 04:29:17PM +, Ian Jackson wrote:
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
> 2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with
Hi Sean,
On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
> Hello Lucas,
>
> Many thanks for providing this summary of your position. Let me just
> note a point of disagreement:
>
> On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
>
> > A point that I find important is the following: as
Hello Lucas,
Many thanks for providing this summary of your position. Let me just
note a point of disagreement:
On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
> A point that I find important is the following: as a project, I think
> that we care about facilitating the review of change
On 17/03/2022 17:52, Russ Allbery wrote:
Helmut Grohne writes:
Do you think it would be impossible to move forward on this matter in a
consensus-based way?
I don't know. I have some reasons to be dubious, but it's possible that
I'm being excessively pessimistic.
I'm inclined to agree with
Hi Ian,
On 15/03/22 at 16:29 +, Ian Jackson wrote:
> Part I - belss continued use of 1.0 native format, for now at least:
>
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>
> 2. Request that the dpkg maintaine
Hi,
On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery wrote:
>
> source package format
While everyone is receptive to new labels, I prefer "upload format" or
"archive format". Either one helps us to distinguish the intermediate
product from any workflow objects a maintainer may have.
> single tarba
Sam Hartman writes:
>> "Russ" == Russ Allbery writes:
> Russ> Switching terminology to completely leave behind the terms
> Russ> with ambiguous meanings isn't a bad idea, but if so we really
> Russ> need a term that captures "is a packaging of an upstream
> Russ> software pac
> "Russ" == Russ Allbery writes:
Russ> Switching terminology to completely leave behind the terms
Russ> with ambiguous meanings isn't a bad idea, but if so we really
Russ> need a term that captures "is a packaging of an upstream
Russ> software package with a separate existence
Helmut Grohne writes:
> Do you think it would be impossible to move forward on this matter in a
> consensus-based way?
I don't know. I have some reasons to be dubious, but it's possible that
I'm being excessively pessimistic.
> Yes, please. Though as is evidenced in the replies to your mail, I
> "Helmut" == Helmut Grohne writes:
Helmut> Hi Russ,
Helmut> On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote:
>> > Specifically, I'd like to ask the TC to come up with policy on
>> native > packages and debian revisions using its power under
>> 6.1.1.
>>
On 16/03/22 at 23:54 +, Wookey wrote:
> On 2022-03-16 15:29 +, Ian Jackson wrote:
> > In practice, the vast majority of packages are maintained in git on
> > salsa. The maintainers use those git repositories as the PFM.
>
> > but almost everyone is already treating git as primary.
>
> Is
Hi Russ,
On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote:
> > Specifically, I'd like to ask the TC to come up with policy on native
> > packages and debian revisions using its power under 6.1.1.
>
> As a Policy Editor, I support this request.
As a TC member I admit disliking this. W
On 2022-03-16 15:29 +, Ian Jackson wrote:
> In practice, the vast majority of packages are maintained in git on
> salsa. The maintainers use those git repositories as the PFM.
> but almost everyone is already treating git as primary.
Is this definitely true? For example: I know I'm not doing
Felix Lechner writes:
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery wrote:
>> We should define native and non-native packages in terms of version
>> numbers, and allow both native and non-native packages to use
>> single-tarball source package formats.
> I co-maintaintain several Debian-intern
Helmut Grohne writes ("Re: Bug#1007717: Native source package format with
non-native version"):
> Beyond the content of your request, I have a meta-question. Do you see a
> particular urgency with the processing of your request? What is - in
> your opinion - a reasonable time
Hi,
On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery wrote:
>
> We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats.
I co-maintaintain several Debian-internal tools, and that descr
Sam Hartman writes:
> Specifically, I'd like to ask the TC to come up with policy on native
> packages and debian revisions using its power under 6.1.1.
As a Policy Editor, I support this request.
I've been involved in a lot of these discussions over the years, and the
tentative conclusion that
Dear TC,
I cannot speak for what Ian wants,
but I would also like to formally ask the TC to rule on this issue.
My hope is that what Ian and I are asking for is similar enough that the
TC can consider the issues together.
Specifically, I'd like to ask the TC to come up with policy on native
packa
Hi,
First, some context with numbers:
Source packages in testing: 32247
Source packages in testing using 3.0 (native): 690 (2.1%)
Source packages in testing using 3.0 (quilt): 30937 (95.9%)
Source packages in testing using 1.0: 620 (1.9%)
Those 620 packages probably fit in two categories:
A) thos
Hi Ian,
On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson
wrote:
>
> I do remember this coming up
> before, but I don't seem to be able to find a record of it now.
Perhaps you were thinking about this discussion in a bug against Lintian?
Ideally I would like dpkg-source to permit source format
`3.0
Hi Ian,
On Tue, Mar 15, 2022 at 04:29:17PM +, Ian Jackson wrote:
> (Sorry for the resend, this should have gone to the BTS the first
> time; have fixed a slip in the wording.)
Thank you for resubmitting your issue as a bug report.
Beyond the content of your request, I have a meta-question. D
es with Debian revisions. I don't think
there is - at least, I didn't find one. I do remember this coming up
before, but I don't seem to be able to find a record of it now.
Sean Whitton writes ("Re: Bug#1007717: Native source package format with
non-native version"):
> I
> "Ian" == Ian Jackson writes:
Ian> 3. Consequently, declare that the recent MBF on this topic
Ian> ought not to have been filed against packages where simply
Ian> changing the source format does not currently work. That would
Ian> include at least 1.0 native packages with De
Hello,
On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote:
> Please:
>
> Part I - belss continued use of 1.0 native format, for now at least:
>
> 1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>
> 2. Request that t
Package: tech-ctte
(Sorry for the resend, this should have gone to the BTS the first
time; have fixed a slip in the wording.)
Please:
Part I - belss continued use of 1.0 native format, for now at least:
1. Declare explicitly that there is nothing wrong with a package with
a native format,
28 matches
Mail list logo
