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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ Debconf-discuss mailing list Debconf-discuss@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-discuss
