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:
> 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
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?
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 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
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
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
24 matches
Mail list logo
