This is an incomplete transcript from debconf9 vcs-pkg bof2 and the
post-bof2 informal talk that happened after it.
I just hope that someone can fill the gaps and make some sense of it.
Some ideas might be hidden there and waiting for someone to find them.
I did not write the name of the talkers because I did not think about it
at the moment, and if I have had thought I would have only known
Madduck's name.
The first transcript (BOF2 itself) is incomplete at the beginning
because after seeking the bof at the bof room, upper and lower talkroom
I managed to find them outside sitting to some chairs, and, of course, I
did not manage to wake myself earlier enough to contact people before
the bof start.
Well, just enjoy it!
adrian15
BOF2 TRANSCRIPT - BEGIN
...
...
...
Refreshing the patches from stream.
Importing into stream.
Ideally upstream is not import but update because it uses dvcs.
---
If there is something to release stable.
---
Recreate the tarball thanks to the pristine tar.
---
How to deal with upstream that distributes one thing at dvcs and another
thing into tar.gz.
upstream and upstream-dist difference.
---
There is not a tool to recreate a tar from upstream dvcs.
---
Speculating: Command to get the tar.gz (wget). Or something that uses
step-takeout.
Shell scripting is easy. However with dvcs is not possible to do that.
Deb-checkout.
---
Bsd guys never a stable package. They do stable release. They do not run
dvcs. Is there any value of having an standard way of naming
orig.tar.gz? (It seems that not).
---
Interface. Get org.source upstream version.Or getting from
upstream? Or getting it from the dvcs?
... ...It means getting rid of source uploads... ...
---
We can try to be a driver and try to introduce a policy slowly.
---
---
A way of ___ a package that gonnas to bload the interface a lot.
Drive the change once. And then say: Hey, we need this command also. It
is going to be hard. How much do we want from
this interface?
---
Getting an arbitrary source. Trying ...
First steps... A declarative way that saying what a file is.Using a
dvcs. Debian uscan. Uscan should be able to get orig tarballs.
---
One place where to write all this in a declarative way. (We need knowing
terms)
---
DVCS supporting uscan.
---
What about a changelog? Huge question. Does DVCS follow changelog or
viceversa?
---
Patterns or recipes. Some questions: 1.- Rewriting a history is that a
pattern? 1.A.: Getting rid of stuff that you do not need. 1.B.: Bad.
Don't do it.
1.C.: History: Remove a file. Is it enough to remove the file or do we
have to remove it from ALL the history? If you are using DVCS is going
to suck for you.
---
How much of knowledge the specific dvcs debuild knowledge package?
---
Starting looking at current code instead of having a layer instead of it.
---
I wonder dvcs*-build tools. The stuff that they are doing it it is not
the same thing. Export, commit, merging.
What are the missings from dvcs*-build? VCS Subversion does not let to
track a branch with upstream data.
---
The debian/ branches is too way complicated. It is difficult. However we
can establish recipes. I mean, maybe it is going to be
easy to do another branch for SVN.
---
SVN can be integrated into a new kind of workflow. SVN 1.5 uses SVN
properties tracks kind of merges. And it is kind of horrorific.
---
Putting together all the dvcs developers into a same room during 2 days.
---
Looking at Debian repository that are some dvcs*-debuild tools.
Finally debuild uses git commands.
---
Processus versus interfaces.
---
Cleaning up the code might be a good idea but... ...
---
Tools knows a declarative way of knowing where your repository is. If
there is a compact and declarative way of doing this.
---
If we have a debian source specific rules. So that it needs another
debhelper. The declarative way help us to build that.
You do not have worry about this. Debian's rpm is much declarative. Stay
flexible. The ability to process things automatically.
But... there is a way to be not declarative.
---
If you have a rules file. Standarised way as debhelper. Threee different
packages that implements different workflows.
Accross distribution : So it is not a rule file only but a .spec file.
Debian package build is debian-specific.
---
Currently we only now how to fetch the interface. If your tool is one
bit more of descriptive. You refine the interface. Then you
can try to automatise things.
You can drive automatisation. I.e. Tag format. Tag format standard (A
file of metadata that it is machine readable).
---
It should be a file. sources/file. It should be available. It is
reasonable if you only can do checkout
I am not interested in BTS telling me what the tag format is. ;)
---
debian/vcs folder.
---
Your file... a different format ... or different location ... I can
deal with it.
---
We didn't get to define a roadmap. We can
