Hi folks, I promised I'd keep the list in the loop and share the important stuff from the vcs-pkg BoF discussion that took place on Thursday morning at DebConf9 in Caceres.
Basically, on Thursday we tried to identify "work packages", or entities that we need to work on. The idea is to create webpages for each of them so that it's easier for people to just pick them up, and that each package can be worked on independently. I know I should write those webpages, I am very low on time given my thesis deadline, and so I am just going to share my notes with you all and hope someone picks it up: 1. Add the current set of workflows to our website. It would be great if the currently "accepted" set of workflows were to be summarised directly on the webpage, so that we can "officialise" them and deprecate all the others floating around. The workflows I know currently are: my topgit workflow, Mehdi's quilt workflow, and Guido's git-buildpackage approach. There my be others. At the same time, the website could use some work, reorganisation, and cleanup. 2. Define common recipes/patterns and explain how to do them with different VCS: a. create a series of patches from VCS (feature branches or otherwise) b. refreshing feature branches (when a new upstream comes along) c. how to work on/branch off older releases d. recreate the upstream tarball e. handle auto-generated files in dist tarball but not in VCS f. update changelog g. rewrite history (e.g. in the case we really need to remove content due to licencing) 3. investigate a (machine-readable) metadata file format to store - VCS location - workflow model - branch layout - tag format - etc. and define a first version. 4. implement support in uscan for determining whether a new tag is available in upstream VCS (should probably be based and thus depend on (3.)) 5. implement a helper based on these metadata which can obtain tarballs (even historic, see (2c&d.) and (3.)) etc. I think these are the five work packages we defined thus far. Let me know if you want to turn them into wiki pages. If you have anything to add, please consider creating those wiki pages first. ;) Another interesting aspect of the BoF was the discussion after the official end between James Westby as Canonical representative, Steve Langasek, Raphaël Hertzog, James Vega, and myself. Canonical wants to make package maintenance uniform. The pragmatic approach for them — since vcs-pkg isn't there yet — is to import everything in Bazaar. I think we managed to agree that cross-VCS support (which is n-factorial) isn't feasible, and so the import would have to have an export associated with it. Concretely, rather than them importing my mdadm (in Git) repo and expecting me to access their Bazaar repo to extract patches, it would make sense for Canonical to export commits into a Git repo of their own (presumably the one they mirrored from), which is the one I will then use. Jelmer's bzr-git adapter could greatly facilitate this. James (Westby): correct me if I'm wrong, please. -- .''`. martin f. krafft <madd...@debconf.org> : :' : DebConf orga team; press officer `. `'` `- DebConf10: New York, USA: http://debconf10.debconf.org "with sufficient thrust, pigs fly just fine. however, this is not necessarily a good idea. it is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- rfc 1925
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss