I think this discussion has conflated two separate needs that should be kept distinct. The current source package provides a record of how the binary packages were built from source. This includes signatures and verifiability of source, and, more recently, reproducibility. It provides the ability to build the binary packages on a user's own machine, and can be a starting point for building them in an environment not supported by Debian (in simple cases this might be exactly the same as building on a current Debian architecture).
The source package has historically (prior to the widespread use of VCS) also provided the basis for future development. Since most development these days is done using VCS, it's natural to try to adapt the source package to contain the VCS. I believe this is a mistake. I think the source package should remain a succinct encapsulation of the source required to build a specific version of the binary packages. It should also identify the canonical VCS location where new development occurs (and from which this snapshot was taken), but it does not need, and should not have, the complete VCS history. I do believe that Debian should strongly encourage use of a publicly accessible VCS for packaging, and should define some VCS-agnostic standards that the repositories SHOULD (RFC implications) follow, e.g. basic branch structures, tag naming conventions, etc. Separating the source package from the VCS repository, but having both, allows both Russ' and Russell's goals to be met easily. One important aspect of this separation is that the VCS can include the original, unmodified upstream source, as long as it is redistributable in that fashion. It has always bothered me that the modifications needed to convert the upstream source to a DFSG-compatible source are lost in the Debian source package. Keeping the VCS separate allows it to contain the original, non-DFSG source and show what was done to make it DFSG and why. It will also help to facilitate using a single repository to build both a source package for main and a corresponding source package for non-free, when that is appropriate. [Perhaps the following should be moved to the Git Packaging thread, but I think much of this sub-thread could also be said to belong there.] I think the VCS-agnostic aspect of this has not been brought up in the related "Git Packaging" thread, but I think this is important. While git is overwhelmingly the most popular VCS, it is not the only one (it's also not my preferred VCS for usability reasons). I think it is short-sighted for Debian policy to mandate or even to strongly encourage a specific VCS. This effectively shuts down the use of any other VCS, and extremely hinders attempts to get a new or better VCS to be used for Debian development. Debian should separate everyday development with the VCS from interaction between the VCS and the Debian archive. The tools provided for the former can be very VCS-specific, and can make full use of that VCS' features. The tools for interacting with the archive, e.g. making it trivial to upload a signed commit to be built on official Debian hardware, should define a very small set of standard features necessary to accomplish that, such as clone, commit, checkout, push, pull, and tag (with signature). This API should have a minimum of options, and it should be easy for someone to implement a shim from that API to a specific VCS. This separation would allow much greater freedom of choice, but still allow the developer to take full advantage of the chosen VCS. ...Marvin
