Your message dated Mon, 27 Jun 2022 09:23:25 -0700
with message-id <87v8smkrcy@athena.silentflame.com>
and subject line Bug#1007717: Native source package format with non-native
version
has caused the Debian Bug report #1007717,
regarding Native source package format with non-native v
Hello,
On Wed 08 Jun 2022 at 09:07pm +02, Helmut Grohne wrote:
> I find it interesting that you seem to equate git-first with dgit. My
> mental model separated those concepts and considered git-first workflows
> on salsa as well. And once you equate them, you can derive a lot of
> conclusions. In
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> I think I take more issue with non-dgit git-first workflows than with
> dgit ones, because dgit is so well documented and is a workflow that is
> already shared by a noticeable fraction of the archive.
I'm curious: how do you measure dgit usage?
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> Now we've turned a discussion about source package formats into a
> discussion about workflows and git. So when I reason about uniformity, I
> effectively want those idiosyncratic workflows to go away. If dgit
> requires 1.0-with-diff for now, then
Hi Sean,
On Tue, Jun 07, 2022 at 04:35:24PM -0700, Sean Whitton wrote:
> I disagree with you that this is primarily about package ownership, and
> I think that we agree on more than you realise we do :)
Hmm. It's not that obvious. While it would be possible to remove the
choice of workflow from s
Hello,
On Wed 08 Jun 2022 at 12:06pm +02, Julian Andres Klode wrote:
> On Tue, Jun 07, 2022 at 08:19:29PM +0200, Helmut Grohne wrote:
>> Please keep in mind that this is about trade-offs. It is a question of
>> how we value "package ownership". If we favour the strong ownership
>> approach that D
On Tue, Jun 07, 2022 at 08:19:29PM +0200, Helmut Grohne wrote:
> Please keep in mind that this is about trade-offs. It is a question of
> how we value "package ownership". If we favour the strong ownership
> approach that Debian used for a long time, then yes accommodating the
> needs of maintainer
Hello,
On Tue 07 Jun 2022 at 11:26am +01, Ian Jackson wrote:
> In this case I would like to suggest that progress would be better
> served by trying to unblock a better source format that (i) has some
> kind of delta representation (ii) does not put a
> needing-to-be-maintained copy of the delta
Hello,
On Tue 07 Jun 2022 at 08:19pm +02, Helmut Grohne wrote:
> Please keep in mind that this is about trade-offs. It is a question of
> how we value "package ownership". If we favour the strong ownership
> approach that Debian used for a long time, then yes accommodating the
> needs of maintain
Hello,
On Tue 07 Jun 2022 at 09:31am +02, Lucas Nussbaum wrote:
> A middle ground between (4) and (4b) could be to discourage the use of
> 1.0-with-diff in circumstances where it is not justified. Something
> like:
>
> 4c. We believe that there are indeed circumstances in which
> 1.0-with-dif
Hi Sean,
On Mon, Jun 06, 2022 at 11:08:48PM -0700, Sean Whitton wrote:
> I think this argument needs to be made more precise -- we should be
> clearer about why this particular un-uniformity is bad. I don't think
> the issue for new contributors is persuasive enough, as new contributors
> can mos
Christoph Berg writes ("Re: Bug#1007717: Draft resolution for "Native source
package format with non-native version""):
> Re: Lucas Nussbaum
> > 4c. We believe that there are indeed circumstances in which
> > 1.0-with-diff is the best choice for a particula
On 07/06/2022 07:08, Sean Whitton wrote:
I agree, it's not about the benefits of the source format, we do indeed
understand all the trade-offs by now. It's that certain ideas and
workflows *which are not really about source packages* are made
inconvenient or impossible if we remove this option.
Helmut Grohne writes ("Re: Bug#1007717: Draft resolution for "Native source
package format with non-native version""):
> What would you think about adding an alternative option 4?
>
> 4b. We believe that there are indeed circumstances in which
> 1.0-wi
Re: Lucas Nussbaum
> A middle ground between (4) and (4b) could be to discourage the use of
> 1.0-with-diff in circumstances where it is not justified. Something
> like:
>
> 4c. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source p
On 07/06/22 at 07:43 +0200, Helmut Grohne wrote:
> Hallo,
>
> On Tue, May 10, 2022 at 05:29:57PM -0700, Sean Whitton wrote:
> > DRAFT
> >
> > Using its powers under constitution 6.1.5, the Technical Committee
> > issues the following advice:
>
> I've given this some thought and feel uneasy about
Hello,
On Tue 07 Jun 2022 at 07:43am +02, Helmut Grohne wrote:
> While I can agree with this item on a technical level, I think there is
> more to it than that and I am wondering whether it sends the "right"
> message.
>
> Sometimes, things we do are technically possible and fill a niche well.
>
Hallo,
On Tue, May 10, 2022 at 05:29:57PM -0700, Sean Whitton wrote:
> DRAFT
>
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
I've given this some thought and feel uneasy about one item.
> 4. We believe that there are indeed circumstances i
Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source
package format with non-native version""):
> On 11/05/22 at 17:29 +0100, Ian Jackson wrote:
> > But I think that might not meet ftpmaster's review needs. AIUI
> > ftpmaster
On 11/05/22 at 17:29 +0100, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source
> package format with non-native version""):
> > Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
> &g
Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source
package format with non-native version""):
> Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
> it be a good solution?
Oh, I hadn't thought of that.
> The
Thanks for your answer.
On 11/05/22 at 12:38 +0100, Ian Jackson wrote:
> I would love for there to be something like 3.0-with-git-diff. Indeed,
> I filed this wishlist bug to ask if contribution would be welcome:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
> but have not had any
Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source
package format with non-native version""):
> If it was possible to use 3.0 (native) with non-native revisions, would
> there be remaining circumstances where 1.0-with-diff is the best choice?
Y
On 10/05/22 at 17:29 -0700, Sean Whitton wrote:
> Hello,
>
> At today's ctte meeting we considered whether we can start a vote on
> this, but two committee members were missing, and someone else at the
> meeting reported that they hadn't yet been able to spend enough time
> thinking through the is
Hello,
At today's ctte meeting we considered whether we can start a vote on
this, but two committee members were missing, and someone else at the
meeting reported that they hadn't yet been able to spend enough time
thinking through the issue to be ready to vote.
We came up with the following plan
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,
Package: tech-ctte
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 the dpkg maintainer relax the restriction which
preve
52 matches
Mail list logo
