Bug#1007717: Draft resolution for "Native source package format with non-native version"
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 one item.
>
> > 4. 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.
>
> 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.
> Yet, we decide that it is no longer reasonable to continue supporting
> them and remove their support despite the feature being useful to some.
> Quite clearly, there is a trade-off involved here. Continuing to support
> 1.0-with-diff comes with a cost that reduces uniformity inside the
> archive. Evidently, this is what motivated Lucas to file the MBF
> initially. My experience is that lack of uniformity is a significant
> barrier to prospective contributors to Debian.
>
> Exploring different technical approaches does have value as well, but I
> think we've had sufficient time to consider the various advantages and
> disadvantages of various source packages formats. On a whole, it seems
> to me that that the number of packages benefiting from 1.0-with-diff is
> relatively small.
>
> What would you think about adding an alternative option 4?
>
> 4b. We believe that there are indeed circumstances in which
> 1.0-with-diff is the best choice for a particular source package.
> Given that the number of packages for which this is relevant is
> fairly small, we recommend discontinuing use of 1.0-with-diff to
> gain more uniformity.
Hi,
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 package,
including, but not limited to, git-first packaging workflows.
However, we recommend discontinuing use of 1.0-with-diff in other
circumstances to gain more uniformity.
That opens the path to an archive where the only remaining 1.0 packages
are the ones where there's a reason to use 1.0. (as opposed to
currently, where we have a mix of packages using 1.0 for a good reason,
and packages using 1.0 because nobody cared to update them to modern
practices).
Lucas
Reply to: