Hi! > I have three feelings. > > > 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. > > > Number 3 is why I haven’t previously commented. In regards to DEP-18, I > don’t know if it is the correct way to go for many of the criticisms that > have already been expressed. But, if it isn’t DEP-18, I think it will > eventually be something. And, although this might not be a popular opinion > among some, I think Debian should get to the point that there is one workflow > (or a very small number of workflows) that all packages are expected to > follow, both for packaging and for collaboration.
Thanks for voicing this! I think a lot of people have the same feeling that if there were a bit more common principles and practices across all packages and maintainers, contributing to multiple different packages would be easier for old maintainers, and learning how to contribute efficiently in the first place would be easier for new maintainers. Also I fully agree that suddenly forcing everybody to do something unpractical would be detrimental to Debian. Therefore the DEP-18 proposal is based on the principles most packages and teams already follow based on trends.debian.net and what I know about e.g. Python, Golang and kernel team policies. There is also no way a volunteer project such as Debian could mandate a two-person-rule as it would instantly grind all single-maintainer packages to a halt. It is and will be OK to have single maintainer packages now and going forward if there is just one person interested in the package. DEP-18 hopefully helps to unify some things and allow for more people to step up and help with packages they have not worked on before, but I intentionally want it to be a fairly soft mechanism, and not overly prescriptive in the details. I also object to having any votes or mandatory rules on this. This is just a DEP on purpose and not a GR. Who knows if a superior alternative to for example git surfaces in the next 15 years. If at that time people *really* want to move away from git they should be allowed to do so and not be prohibited by too strict rules. For the reasons 2 and 3 in Soren's list, let's continue to discuss what are the best practices and principles. I am sure we can eventually get a consensus that suits most people and creates the best environment for easier collaboration.
