debconf9 vcs-pkg bof2 and post-bof2 transcript

[adrian15]

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 turn thoses into packages work.
Debian-specific. All the recipes. Every distribution has to deal with that.
Recipes for GIT in Debian. Then Fedora comes and says how they deal with
GIT, what it is their recipe.

If we make it as small as possible... so that everyone is ok with that.

---

Uscan (maybe Debian specific) adds the ability so that it takes
orig.tar.gz.

...

1.- Recipes
2.- Uscan
3.- Standarise the package build process
4.- Control field file.

---

What can we do into a year?
-Improve the webpage.
-Formalise the recipes soon.
-Maybe defining control file is not going to be possible.

Step 0 - We want to work on something. (Roadmap).
It really depends on who it is going to volunteer it.

---
Beginning of next year begin to push all of this.

BOF2 TRANSCRIPT - END

BOF2 - POST TALK - TRANSCRIPT - BEGIN
What's wrong on patch metadata.

Some mandatory fields. So you are trying to do a new
package-version-control.


What DVCS-Independent is? You can take a git package and work on bazaar?
Is the patch ...... ?

Git-pane. Parent. ... You can serialise this into patches. But to
actually to recreate it. With GIT you
can say I am not doing a merge. I want two parents. You can do it manually
I do not know if we can do it with bazaar.

---

Dpackage-deb commands that Dpackage-deb/version3.0/git. I do not know if
this is what we want, what we need.

Stephan... uses patches... something very Git related.

Throw-away branch. Each branch is patch. Unrolls the stacks.. and ...
pushes the thing back... rebuild this into the process... this
is how to use... they export ... and they build a package

There is no reason why you couldn't keep a feature branch. There is some
beauty of it.

1st step: Generate patches and then using it. So they are using DVCS to
do it. It is kind of cooperation tool.
We don't have to bother about patches. Patches are legacy.

---

Bi-directional. (Why we started talking about that).

Metadata is not in branches but in commitment!

---

How... every package so that it uses this workflow? Whatever this
workflow it is? We do not know if there is going to be only one workflow.

---

We can try to force maintainers way of working by ...

Feature branches... patches.

---

If you import everything into source package. Is it that part of... Is
it like a need that we need to address? Import into VCS?
Regular need of the work?

---

Happen to track a file for ever. Patch ... branch name (similar to
quitch). If the patch changes. ....

The solution that allows to do this are the first ones...


---

1.- Importing into a new DVCS
2.- Working into an existing DVCS

If you actually import into a bazaar you are giving me a change to track
your development.
The main idea seems to be ... foil? ... streets... It is going to be
harder to me. ...

Wasn't this why we wanted to define interfaces? This way we can be
cross-dvcs.

---

Since you are importing from git to ubuntu's bazaar. Your tool already
knows how to deal with git.
How would we to maintain your own git-clone. Bazaar import so that it
comes back to git.

If you import git into bazaar. You need to know what to know what the
git command it is.
If you export git you  need it...  You cannot do something?????? You
need that Git will have something like: "This is the bazaar release name."

---

You see the point of ... canonical maintaning... Ubuntu having a
git-clone so that Debian's git's guys can use this git clone directly
and keep of tracks.

---


Some one is working on that ? Is it Hammer? So that you can actually
start a git server in bazaar.

So this is I want to use git to maintain this package. Not thinking
about any...

---

Distro-cross development. Ideal world, upstream, fedora, git and we sync
all. If Fedora uses Mercurial, Debian Git,... actually it is unmaintaneable.
Because DVCS are not currently be able to cooperate between each other.

Per Package-base you should decide to work only with the same DVCS.

---

There are some questions such as cross-dvcs. I think this is going to be
too hard to do.

---

VCS-Agnostic first idea... we do not require git.

I can't see any time in the future a cross-dvcs that it is reliable.

I only know git-svn. It just blows up in your face.

---

If you actually want to have cross dvcs, you will have to agree on some
kind of base format.

Allow GIT to store more information than it does.

Svn is maybe a stupid example.

Git-Bazaar interface. It will be easy to to push and pull.

Git server for bazaar.

We are going to have a new tool and then an explosion of new DVCS
programs ocurred.

----

Bazaar does _________. But Mercurial might not do it.

----

A workflow that works with all dvcs. That makes sense at this point.

----

I would have my Bazaar, Git supermirror.

DVCS-pkg trying to find a differnt solution to the same problem.
Defining interfaces should be able to track each package as a new one.

----

Because a newbie faces into packages, distros, patch system, ...

----
One the interface is defined then you have a tool that works that with
this interface.
So that the tool works with bazaar.

----

Canonical plans. Bazaar-import is it priority. Or is it seems to be the
optimal solution to the problem ??

- I do not know. To develop a distribution from DVCS. So we need to put
be able everything into Bazaar.
- I would like to make Debian using only a DVCS. ;)

Launchpad already has already some different bug formats. It only
imports the status. For the full text you have to go to bugzilla.
There is a kind of communication.

What a gather it is a pragmatic decision. To use bazaar. Well, it is not
pragmatic because you force the developer to use only one DVCS.

---

.........  implement a mirror ...........


Unless we define standards things are going to take a bit longer.
BOF2 - POST TALK - TRANSCRIPT - END

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/index.php?pid=10