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.
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,
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
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
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
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 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
>
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
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
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
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
>
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
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
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
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
> > ftpmast
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
> > it
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 main limi
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
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
22 matches
Mail list logo
