Hello, On Sat 03 Aug 2024 at 11:29am -07, Soren Stoutner wrote:
> 1. Debian workflows are too fractured. The project would be better if we > asked people > to standardize around a single (or a small number) of workflows. To do so, > the workflow > would need to be flexible enough to handle the wide range of technical needs > of all the > packages and upstream configurations. > > 2. Standardizing around a single (or small number of) workflows will make > some people > unhappy. But that is an acceptable price to pay because of the general > benefit to the > project as long as the correct solution is adopted. Unity is more important > than minority > opinions on this particular issue. > > 3. I do not yet have the wisdom to ascertain what the correct solution is. > Until I do, I > applaud those who attempt to push this discussion forward, and I follow it > closely, but I > haven’t commented. I think adopting an incorrect mandated (or maybe even > recommended) workflow is worse than the fractured status quo. We need to distinguish different workflows or workflow stages. There is the git hosting workflow -- gitlab vs. github vs. personal server. This seems solely about what people like to use. I agree with you that we should probably pick just one of these -- not even a small number. But there is also the git->dsc workflow -- gbp vs. dpm vs. debrebase vs. debcherry. The crucial difference is that in this area it's not just personal preferences, but that different packages have different needs. A small Python library is vastly different to, say, SBCL or Xen. My two favourite git->dsc workflows are documented in dgit-maint-merge(7) and dgit-maint-rebase(7). These manpages include some explanations as to what sort of packages are best suited to each of them. -- Sean Whitton
signature.asc
Description: PGP signature
