output from the vcs-pkg BoF @DebConf9

[martin f krafft]

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 <madduck at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20090804/a998c9cd/attachment.pgp>