headers
Stéphane Glondu | 25 Sep 15:37

Introductory mail

Hello,

My name is Stéphane Glondu. I've been using Debian for many years, and 
I've been contributing to Debian for one year now. I am DM (and in NM 
process). I work mainly in the Debian OCaml Team¹.

I am interested in this list because I am interested in issues raised by 
packaging, and, more generally, in VCSs. I am familiar with packaging 
with subversion (as member of the OCaml Team) and git. Our team is 
slowly migrating to git packaging². In this context, I've migrated many 
repositories of Debian packages from svn to git with the help of a 
(quite dirty, I must admit) script of my own (I wasn't satisfied enough 
with existing ones). This was also a way to get more acquainted with svn 
and git. I still haven't adopted a clear workflow for my git packaging, 
as I am trying/using several ones.

I am also familiar with cvs (but forgetting :-) and darcs (neither of 
them for packaging). I still tend to push people into using darcs (if 
they don't use any DVCS). I am a big fan of darcs and git.

¹ http://wiki.debian.org/Teams/OCamlTaskForce
² http://wiki.debian.org/Teams/OCamlTaskForce/GitMigration

Cheers,

--

-- 
Stéphane Glondu
Permalink | Reply |
headers
martin f krafft | 26 Sep 19:33
Favicon

Re: Introductory mail

also sprach Stéphane Glondu <steph <at> glondu.net> [2008.09.25.1538 +0200]:
> I am interested in this list because I am interested in issues
> raised by packaging, and, more generally, in VCSs. I am familiar
> with packaging with subversion (as member of the OCaml Team) and
> git. Our team is slowly migrating to git packaging². In this
> context, I've migrated many repositories of Debian packages from
> svn to git with the help of a (quite dirty, I must admit) script
> of my own (I wasn't satisfied enough with existing ones). This was
> also a way to get more acquainted with svn and git. I still
> haven't adopted a clear workflow for my git packaging, as I am
> trying/using several ones.

Welcome, Stéphane! Thanks for your introduction, and I am looking
forward to learning from your experience.

I am currently all crazy about topgit (0.4 to be uploaded ASAP), and
maybe you want to check it out. The topgit source package contains
a debian/README.source file to explain what I am doing there. There
are still rough edges, but I think it's a pretty nice way of doing
things...

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"of course the music is a great difficulty.
 you see, if one plays good music, people don't listen,
 and if one plays bad music people don't talk."
(Continue reading)

Permalink | Reply |
headers
Stéphane Glondu | 28 Sep 11:58

Re: Introductory mail

martin f krafft wrote:
> I am currently all crazy about topgit (0.4 to be uploaded ASAP), and
> maybe you want to check it out. The topgit source package contains
> a debian/README.source file to explain what I am doing there. There
> are still rough edges, but I think it's a pretty nice way of doing
> things...

I've read topgit's README.source. I am currently experimenting with it.
Is there any other source package using topgit?

A more technical question: what is the difference between "build" and
"master" branches? IIUC, build is master + serialized patches, right? If
so, is there any benefit in keeping master?

Cheers,

--

-- 
Stéphane


_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
martin f krafft | 28 Sep 14:07
Favicon

Re: Introductory mail

also sprach Stéphane Glondu <steph <at> glondu.net> [2008.09.28.1158 +0200]:
> I've read topgit's README.source. I am currently experimenting with it.
> Is there any other source package using topgit?

None that I know of. It'll be hard to come up with statistics here,
since topgit is neither a build-dependency, nor a special Vcs-*
class.

> A more technical question: what is the difference between "build"
> and "master" branches? IIUC, build is master + serialized patches,
> right? If so, is there any benefit in keeping master?

master is the Debianisation branch which provides ./debian/. All
changes to ./debian/ are done there. It is not serialised,
obviously, but serves as the base for build (it's merged into build
for each new release) and then the patches are modified and
committed.

build holds the actual source from which the package was built.
master holds the development line for ./debian/

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"... alle sätze der logik sagen aber dasselbe. nämlich nichts."
                                                       -- wittgenstein
(Continue reading)

Permalink | Reply |
headers
Stéphane Glondu | 28 Sep 15:24

Re: Introductory mail

martin f krafft wrote:
> master is the Debianisation branch which provides ./debian/. All
> changes to ./debian/ are done there. It is not serialised,
> obviously, but serves as the base for build (it's merged into build
> for each new release) and then the patches are modified and
> committed.

I understood this, but I wonder why you use two distinct branches for
this. IIUC, your build branch will consist only on merges with the
master branch and updates of patches, right? What benefits do you get by
cluttering the history with those merge commits? There must be something
I'm missing...

> build holds the actual source from which the package was built.
> master holds the development line for ./debian/

Imagine I agree on the purpose of the two branches "build" and "master".
Shouldn't "build" be "master"? And "master" something else (e.g.
"debian")? In most git repositories, the package is built from the
"master" branch, and it seems to me that this is what git-buildpackage
expects. BTW, have you considered collaborating with Guido Günther to
make git-buildpackage work better with topgit?

--

-- 
Stéphane


_______________________________________________
vcs-pkg-discuss mailing list
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 29 Sep 08:43
Favicon

Re: Introductory mail

also sprach Stéphane Glondu <steph@...> [2008.09.28.1524 +0200]:
> I understood this, but I wonder why you use two distinct branches for
> this. IIUC, your build branch will consist only on merges with the
> master branch and updates of patches, right? What benefits do you get by
> cluttering the history with those merge commits? There must be something
> I'm missing...

As far as I know, there is no way with topgit to extract/flatten the
patch series as it was at some point in history. Therefore, it is
impossible to extract debian/patches/* files from the feature
branches for an earlier version, which is why I keep them in files
in the build branch.

> > build holds the actual source from which the package was built.
> > master holds the development line for ./debian/
> 
> Imagine I agree on the purpose of the two branches "build" and
> "master". Shouldn't "build" be "master"? And "master" something
> else (e.g. "debian")? In most git repositories, the package is
> built from the "master" branch, and it seems to me that this is
> what git-buildpackage expects.

If git-buildpackage expects master, then it is inflexible; you
should be able to tell it to build from build.

Anyway, I can see arguments for your proposal, mainly that the
default gitweb branch shown is master, and that's what makes sense
to have on git.debian.org, right? Anyway, this is really just
cosmetic...
(Continue reading)

Permalink | Reply |
headers
Guido Günther | 29 Sep 10:53

Re: Introductory mail

On Mon, Sep 29, 2008 at 08:43:18AM +0200, martin f krafft wrote:
[..snip..] 
> If git-buildpackage expects master, then it is inflexible; you
> should be able to tell it to build from build.
git-buildpackage builds from any branch you tell it to.
 -- Guido
Permalink | Reply |
headers
martin f krafft | 29 Sep 12:01
Favicon

git-buildpackage and topgit (was: Introductory mail)

also sprach Guido Günther <agx@...> [2008.09.29.1053 +0200]:
> > If git-buildpackage expects master, then it is inflexible; you
> > should be able to tell it to build from build.
> git-buildpackage builds from any branch you tell it to.

I will have to look at git-buildpackage one of these days.

Have you looked at topgit:debian/README.source? Do you think
git-buildpackage could help automate this process?

Can git-buildpackage use information stored in the repository, such
as which branch to build from? It would be handy to be able to tell
people just to use git-buildpackage without expecting them to pass
the right branch name.

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"the 'volatile' keyword
 is implemented syntactically
 but not semantically"
                          -- documentation of m$ visual c, around 1992

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 29 Sep 14:01
Favicon

Re: git-buildpackage and topgit (was: Introductory mail)

On Mon, Sep 29, 2008 at 12:01:25PM +0200, martin f krafft wrote:
> Can git-buildpackage use information stored in the repository, such
> as which branch to build from? It would be handy to be able to tell
> people just to use git-buildpackage without expecting them to pass
> the right branch name.

Nope, it uses two branches which default to "master" and
"debian". They can be overridden via cmdline switch or
conffile. Still, upstream of git-buildpackage is quite active, if we
see a clear benefit in adding the "proverbial extra level of
indirection" I'm sure we can have him accept a patch implementing
that.

Cheers

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
Guido Günther | 30 Sep 09:02

Re: git-buildpackage and topgit (was: Introductory mail)

On Mon, Sep 29, 2008 at 12:01:25PM +0200, martin f krafft wrote:
[..snip..] 
> Have you looked at topgit:debian/README.source? Do you think
> git-buildpackage could help automate this process?
We can certainly (at least) add another hook that calls a script that
does what's described under 4.) and git-import-orig could help with
importing new upstream but I think Manoj has some valid points about the
current workflow that should be resolved first.

> Can git-buildpackage use information stored in the repository, such
> as which branch to build from? It would be handy to be able to tell
> people just to use git-buildpackage without expecting them to pass
> the right branch name.
Sure. Just put in in $GITREPO/.gbp.conf.
 -- Guido
Permalink | Reply |
headers
Stefano Zacchiroli | 30 Sep 09:24
Favicon

Re: git-buildpackage and topgit (was: Introductory mail)

On Tue, Sep 30, 2008 at 09:02:31AM +0200, Guido Günther wrote:
> > Can git-buildpackage use information stored in the repository, such
> > as which branch to build from? It would be handy to be able to tell
> > people just to use git-buildpackage without expecting them to pass
> > the right branch name.
> Sure. Just put in in $GITREPO/.gbp.conf.

Wow, super-cool, I was missing this, thanks!

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time

On Tue, Sep 30, 2008 at 09:02:31AM +0200, Guido Günther wrote:
> > Can git-buildpackage use information stored in the repository, such
> > as which branch to build from? It would be handy to be able to tell
> > people just to use git-buildpackage without expecting them to pass
> > the right branch name.
> Sure. Just put in in $GITREPO/.gbp.conf.

Wow, super-cool, I was missing this, thanks!

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 30 Sep 10:09
Favicon

Re: git-buildpackage and topgit (was: Introductory mail)

also sprach Guido Günther <agx <at> sigxcpu.org> [2008.09.30.0902 +0200]:
> We can certainly (at least) add another hook that calls a script
> that does what's described under 4.) and git-import-orig could
> help with importing new upstream but I think Manoj has some valid
> points about the current workflow that should be resolved first.

Agreed. But in any case, topgit 0.5 will provide (a working)
tg-export -b, which will make the whole stage branch stuff obsolete,
so #4 should be a lot simpler with tg 0.5.

> Sure. Just put in in $GITREPO/.gbp.conf.

Awesome.

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

a farmer is a man outstanding in his field.

also sprach Guido Günther <agx <at> sigxcpu.org> [2008.09.30.0902 +0200]:
> We can certainly (at least) add another hook that calls a script
> that does what's described under 4.) and git-import-orig could
> help with importing new upstream but I think Manoj has some valid
> points about the current workflow that should be resolved first.

Agreed. But in any case, topgit 0.5 will provide (a working)
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 28 Sep 17:56
Favicon

Bug#499264: Introductory mail

On Sun, Sep 28, 2008 at 02:07:36PM +0200, martin f krafft wrote:
> also sprach Stéphane Glondu <steph <at> glondu.net> [2008.09.28.1158 +0200]:
> > I've read topgit's README.source. I am currently experimenting with it.
> > Is there any other source package using topgit?
> None that I know of. It'll be hard to come up with statistics here,
> since topgit is neither a build-dependency, nor a special Vcs-*
> class.

Thinking out loud: remember the bug you (or me, doesn't matter)
reported against debcheckout in Debian to better support, via
heuristics, topgit? Well, once I have time to fix it :), we can ask
debcheckout if some package using Vcs-Git is actually topgit or not,
how does that sound?

It would be better to avoid adding that behavior to "debcheckout -p"
though, as currently that flag is able to work offline, while the new
query behavior would require network connection ...

Cheers.

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time
Permalink | Reply |
headers
martin f krafft | 29 Sep 07:50
Favicon

Re: Introductory mail

also sprach Stefano Zacchiroli <zack@...> [2008.09.28.1756 +0200]:
> Thinking out loud: remember the bug you (or me, doesn't matter)
> reported against debcheckout in Debian to better support, via
> heuristics, topgit? Well, once I have time to fix it :), we can
> ask debcheckout if some package using Vcs-Git is actually topgit
> or not, how does that sound?

In a way that we could run this over the entire archive to produce
statistics? Well, all Vcs-Git packages anyway...?

> It would be better to avoid adding that behavior to "debcheckout -p"
> though, as currently that flag is able to work offline, while the new
> query behavior would require network connection ...

... remind me again why we shouldn't just introduce Vcs-TopGit?

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"first get your facts; then you can distort them at your leisure."
                                                       -- mark twain

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 29 Sep 09:23
Favicon

Re: Introductory mail

On Mon, Sep 29, 2008 at 07:50:17AM +0200, martin f krafft wrote:
> In a way that we could run this over the entire archive to produce
> statistics? Well, all Vcs-Git packages anyway...?

Yes.

> > It would be better to avoid adding that behavior to "debcheckout -p"
> > though, as currently that flag is able to work offline, while the new
> > query behavior would require network connection ...
> ... remind me again why we shouldn't just introduce Vcs-TopGit?

Nobody said we shouldn't. Still, the concern was that TopGit is not
really a new Version Control System, and it is not necessarily true
that a user should be able to appreaciate the difference between a
plain git and a TopGit repository to benefit from the Vcs-*
information.

Cheers.

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time
Permalink | Reply |
headers
Manoj Srivastava | 29 Sep 17:45
X-Face
Face
Favicon

Re: Introductory mail

On Sun, Sep 28 2008, martin f krafft wrote:

> also sprach Stéphane Glondu <steph@...> [2008.09.28.1158 +0200]:
>> I've read topgit's README.source. I am currently experimenting with it.
>> Is there any other source package using topgit?
>
> None that I know of. It'll be hard to come up with statistics here,
> since topgit is neither a build-dependency, nor a special Vcs-*
> class.

        I am playing with topgit for my pakcages. I, however, am doing
        things differently:
 upstream             <-- non-topgit branch that tracks upstream
 topic--{foo,bar.baz} <-- tg topic branches
 master               <-- used to be integration, and now is the build
                          branch

        ./debian is a git sub-module in master, and is a separate git
 project.  The ./debian directories in my package are different branches
 of the debian-dir git project (and each has a debiandir-common
 sub-module).

        I don't really want to add ./debian/patches directory to keep
 track of previous patch series; and I think we should perhaps add a
 possibility for topgit to generate patch series based on a tag. Then,
 you tag all topic-- branches when releasing, and then would be able to
 extract the patches corresponding to the tag(s) at any time in the
 future.

        I'll keep the list posted about the intersection of sub-modules
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 29 Sep 18:05
Favicon

Re: Introductory mail

also sprach Manoj Srivastava <srivasta <at> acm.org> [2008.09.29.1745 +0200]:
>         I don't really want to add ./debian/patches directory to keep
>  track of previous patch series;

Well, it is the only truly-accepted, VCS-agnostic way to have
a patch series in a Debian package, so why not?

> and I think we should perhaps add a possibility for topgit to
> generate patch series based on a tag. Then, you tag all topic--
> branches when releasing, and then would be able to extract the
> patches corresponding to the tag(s) at any time in the future.

This is going to get ugly, since for every tag on the build branch,
you need to create two tags on each topgit branch, denoting the
begin and end of the feature branch (which is done with
refs/top-bases/$name and refs/heads/$name (the tip) right now).

You might be able to determine either of these from the DAG, but
I somehow doubt it. I'd love to be proven wrong.

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"by accepting this brick through your window, you accept it as is
 and agree to my disclaimer of all warranties, express or implied,
 as well as disclaimers of all liability, direct, indirect,
 consequential or incidental, that may arise from the installation
(Continue reading)

Permalink | Reply |
headers
Manoj Srivastava | 29 Sep 19:08
X-Face
Face
Favicon

Re: Introductory mail

On Mon, Sep 29 2008, martin f krafft wrote:

> also sprach Manoj Srivastava <srivasta@...> [2008.09.29.1745 +0200]:
>>         I don't really want to add ./debian/patches directory to keep
>>  track of previous patch series;
>
> Well, it is the only truly-accepted, VCS-agnostic way to have
> a patch series in a Debian package, so why not?

        My goal is not to have a patch series in a Debian package. My
 goal is to be able to develop software that is packaged for Debian --
 and I mean develop, not just be a glorified packager for Debian.

        I guess I am balking duplicating the changes made in the
 source -- firstly, as the git level, then in a _different_ git repo in
 the patches directory. I can do it, but this is ugly.

        I will probably not be using any of the 3.0 formats any time
 soon for Debian -- unless I can make topgit wotk with an on-the-fly
 generation of the quilt series (and remove the series in the clean
 command). The git format does not handle submodules, so it is not a
 contender.

>> and I think we should perhaps add a possibility for topgit to
>> generate patch series based on a tag. Then, you tag all topic--
>> branches when releasing, and then would be able to extract the
>> patches corresponding to the tag(s) at any time in the future.

> This is going to get ugly, since for every tag on the build branch,
> you need to create two tags on each topgit branch, denoting the
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 29 Sep 19:21
Favicon

Re: Introductory mail

also sprach Manoj Srivastava <srivasta@...> [2008.09.29.1908 +0200]:
> My goal is not to have a patch series in a Debian package. My goal
> is to be able to develop software that is packaged for Debian --

This argument has been taken ad infinitum on debian-devel. The idea
of a patch series in the Debian source package is simply to make it
easier for others to work on your packages. This sounds like
a worthwhile goal to me, especially if we want to untie some of the
knots in Debian and open up those bottlenecks (I am not saying you
are one of them).

Anyway, I am not saying that this is the way to go, only time will
tell which approach(es) are the successful ones. I'd love to see
some standardisation across distros at some point. If we want to
continue to scale, I think that's the way forward...

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"i don't think so," said rene descartes. just then, he vanished.

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
(Continue reading)

Permalink | Reply |
headers
Manoj Srivastava | 29 Sep 19:44
X-Face
Face
Favicon

Re: Introductory mail

On Mon, Sep 29 2008, martin f krafft wrote:

> also sprach Manoj Srivastava <srivasta <at> acm.org> [2008.09.29.1908 +0200]:
>> My goal is not to have a patch series in a Debian package. My goal
>> is to be able to develop software that is packaged for Debian --
>
> This argument has been taken ad infinitum on debian-devel. The idea
> of a patch series in the Debian source package is simply to make it
> easier for others to work on your packages. This sounds like
> a worthwhile goal to me, especially if we want to untie some of the
> knots in Debian and open up those bottlenecks (I am not saying you
> are one of them).

        Arguably, we should all use debhelper and use quilt+subversion,
 to make it easier for more people to follow the package. And, really,
 we should all be using rpm or tar.gz. (More people use subversion than
 do understand git).

        At some point we draw a line at popularity, and making things
 easier for everyone else part from the ones currently doing the work).
 I have a line where my productivity and motivation are sufficiently
 negatively impacted that changing to goals to make things easy for
 (potential) contributors at the expense of my workflow results in a
 regression.

> Anyway, I am not saying that this is the way to go, only time will
> tell which approach(es) are the successful ones. I'd love to see
> some standardisation across distros at some point. If we want to
> continue to scale, I think that's the way forward...
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 29 Sep 21:17
Favicon

Re: Introductory mail

On Mon, Sep 29, 2008 at 12:44:57PM -0500, Manoj Srivastava wrote:
>         Arguably, we should all use debhelper and use quilt+subversion,
>  to make it easier for more people to follow the package. And, really,
>  we should all be using rpm or tar.gz. (More people use subversion than
>  do understand git).

Eh :)

>         At some point we draw a line at popularity, and making things
>  easier for everyone else part from the ones currently doing the work).
>  I have a line where my productivity and motivation are sufficiently
>  negatively impacted that changing to goals to make things easy for
>  (potential) contributors at the expense of my workflow results in a
>  regression.

It looks to me you are implicitly assuming that there is an exclusive
choice between patch series and Vcs. If that were true your argument
would stand, but it is not true, and TopGit is there exactly to show
that (if it is up to the task).

The fact is that among Debian developers and maintainers not everyone
is familiar with all Vcs we have, but we do want people to be able to
work on whatever package to help out with bug fixing (and possibly
with NMU). The idea of providing *also* a patch series is to diminish
barrier in contributing to a package.

Of course that should not be done augmenting the burden on top of the
usual maintainer and that, again, is something that TopGit should show
to be considered the right™ tool.
(Continue reading)

Permalink | Reply |
headers
Manoj Srivastava | 29 Sep 22:42
X-Face
Face
Favicon

Re: Introductory mail

On Mon, Sep 29 2008, Stefano Zacchiroli wrote:

> On Mon, Sep 29, 2008 at 12:44:57PM -0500, Manoj Srivastava wrote:
>>         Arguably, we should all use debhelper and use quilt+subversion,
>>  to make it easier for more people to follow the package. And, really,
>>  we should all be using rpm or tar.gz. (More people use subversion than
>>  do understand git).
>
> Eh :)
>
>>         At some point we draw a line at popularity, and making things
>>  easier for everyone else part from the ones currently doing the work).
>>  I have a line where my productivity and motivation are sufficiently
>>  negatively impacted that changing to goals to make things easy for
>>  (potential) contributors at the expense of my workflow results in a
>>  regression.
>
> It looks to me you are implicitly assuming that there is an exclusive
> choice between patch series and Vcs. If that were true your argument
> would stand, but it is not true, and TopGit is there exactly to show
> that (if it is up to the task).

        *Sigh*. You are missing context. And the point.

        Let me see if I can recap.

 a) Topgit can be used to generate quilt series on the fly, but only for
    the current state of the package.
 b) For previous  releases of the package, just the git branches are not
    enough, since we can not recreate previous patches.
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 30 Sep 09:17
Favicon

topgit patches from tags (was: Introductory mail)

I wish people would change subject lines more often...

also sprach Manoj Srivastava <srivasta@...> [2008.09.29.2242 +0200]:
>         Of course, it would be great that with some tagging topgit could
>  keep track of the history itself (as VCS' are supposed to be doing),
>  and not make me store the serialization of git branches in yet another
>  git branch, but hey. I did not write topgit, and I am gratefil for what
>  has been  given me to complain too loudly.

See #500656.

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

oxymoron: micro$oft works

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
Stéphane Glondu | 30 Sep 10:19

Re: topgit patches from tags

martin f krafft wrote:
> I wish people would change subject lines more often...

Yes, it was time :-)

> See #500656.

Interesting... With Manoj's arguments and this bugreport, I now
paradoxically understand the point in having two separate build/master
branches.

IIUC, the problem is being able to recreate the patch series of an
earlier release: Manoj doesn't care and Martin keeps it in a branch, but
this branch is more an artifact than a "real" working branch. Please
correct me if I'm wrong.

Concerning #500656, and Martin's suggestion:
> It seems like the solution is a tg-tag command, which, when called
> like
> 
>   tg-tag debian/1.0-1 tgbranch[, tgbranch, ...]
> 
> tags the top-bases and tips of all specified tg-branches, e.g. like
> this:
> 
>   refs/top-tags/debian/1.0-1/base and
>   refs/top-tags/debian/1.0-1/tip

Doing it that way would pollute the tag namespace, IMO.
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 30 Sep 10:38
Favicon

Re: topgit patches from tags

also sprach Stéphane Glondu <steph@...> [2008.09.30.1019 +0200]:
> >   refs/top-tags/debian/1.0-1/base and
> >   refs/top-tags/debian/1.0-1/tip
> 
> Doing it that way would pollute the tag namespace, IMO.

Yes and no. Normal tags are in refs/tags. I am proposing the
refs/top-tags namespace, which is reserved for topgit anyway (topgit
reserved refs/top-*).

Sure, gitk and the like would still show those refs (as grey refs,
not yellow tags or green branches), but git-tag wouldn't.

> What about keeping this data in a dedicated, special branch, like
> pristine-tar does?

You want to keep files with SHA-1 refs in a branch? I am not sure
I like that at all. First of all, this clearly seems like a feature
for upstream, and second, Git is all about keeping track of refs,
storing them as payload in a branch seems like patching patch files
:)

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

an avocado-tone refrigerator would look good on your resume.
(Continue reading)

Permalink | Reply |
headers
Stéphane Glondu | 30 Sep 11:59

Bug#500656: topgit patches from tags

martin f krafft wrote:
> Yes and no. Normal tags are in refs/tags. I am proposing the
> refs/top-tags namespace, which is reserved for topgit anyway (topgit
> reserved refs/top-*).

Sorry, I didn't pay attention to this. I guess this needs a special
cloning/pushing/pulling procedure, then? BTW, you don't talk about
pushing/pulling/sharing with others in your quick tuto (but you do talk
about cloning).

> You want to keep files with SHA-1 refs in a branch? I am not sure
> I like that at all. [...]

Yes.

> [...] First of all, this clearly seems like a feature
> for upstream, [...] 

What do you mean by "a feature for upstream"?

> [...] and second, Git is all about keeping track of refs,
> storing them as payload in a branch seems like patching patch files
> :)

Indeed, it seems so. But I was getting inspiration from pristine-tar. I
guess *.id files that are committed there are not meant to be used
(and/or alterable) by human beings. Do we want this for "historical"
bases and tips of tg branches? I am not really at ease with mixing
"live" and "dead" script-manipulated references in the same place.
Anyway, as long as my tag namespace is not polluted, I guess I could
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 30 Sep 12:43
Favicon

Bug#500656: topgit patches from tags

also sprach Stéphane Glondu <steph <at> glondu.net> [2008.09.30.1159 +0200]:
> Sorry, I didn't pay attention to this. I guess this needs a special
> cloning/pushing/pulling procedure, then?

Yes, and that would be setup by tg-remote, which already sets this
up for refs/top-bases/*.

> BTW, you don't talk about pushing/pulling/sharing with others in
> your quick tuto (but you do talk about cloning).

tg-export should make this all transparent, i.e. you should be able
to push your branches like before, and top-bases will also be
pushed.

The nice thing about topgit is that it's really just a thin layer on
top of Git, so everything Git also works with TopGit.

> > [...] First of all, this clearly seems like a feature
> > for upstream, [...] 
> 
> What do you mean by "a feature for upstream"?

Tagging previous version of topic branches/patches.

> > [...] and second, Git is all about keeping track of refs,
> > storing them as payload in a branch seems like patching patch files
> > :)
> 
> Indeed, it seems so. But I was getting inspiration from
> pristine-tar. I guess *.id files that are committed there are not
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 30 Sep 09:32
Favicon

Re: Introductory mail

On Mon, Sep 29, 2008 at 03:42:46PM -0500, Manoj Srivastava wrote:
>         *Sigh*. You are missing context. And the point.

I was in fact missing some context, but still I think you don't see my
big picture.

>  c) Therefore, we need to additionally store the patch series generated
>     from git branches into yet another git branch (presumably not one
>     the patch series are generated from).
> 
>         Me, I hate c, and I think this is not something I am going to be
>  doing, even if that schema is popular.

In my vision, the patch series is just an interface for who, beside
the usual maintainer, have to interact with the package without having
to know the gory details of the user VCS or its branch layout. It is
not something to be used routinely: if I care enough about a package I
can take the time to learn the details of its maintenance. If I just
want to make a quick bugfix I don't.

Hence, I see no need of versioning the patch series. Having just the
last series, most likely in the Debian source package, would be
enough.

>         I have rarely seen people do ongoing development of my packages
>  (and I have _some_ experience here: I've had some 30+ packages in
>  Debian for nearly 13 years now).  Most people look at he unpacked
>  source, and send me a patch via mail, and I figure out where the patch
>  belongs (or whether the patch needs to be split up). That is fine by
>  me; you do not have to understand  topgit et al to contribute.
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 30 Sep 10:02
Favicon

recreating historic packages (was: Introductory mail)

also sprach Stefano Zacchiroli <zack@...> [2008.09.30.0932 +0200]:
> Hence, I see no need of versioning the patch series. Having just
> the last series, most likely in the Debian source package, would
> be enough.

I always thought the point of tagging commits in the VCS was to be
able to recreate pristine Debian source packages, no? Why do we
bother tagging packages debian/1.0-1 if the tag cannot be used to
actually obtain the tree that was used to build the package?

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"micro$oft productivity software"
                              - see reductio ad absurdum, conclusions.

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
Stefano Zacchiroli | 30 Sep 10:36
Favicon

Re: recreating historic packages (was: Introductory mail)

[ unrelated: is the list configured to not deliver a message Cc-ed to
a subscriber also via the list? Please avoid Cc-ing me, since the
result is that I receive the message only in my INBOX and (I guess due
to the setting above) without a List-Id header ... ]

On Tue, Sep 30, 2008 at 10:02:34AM +0200, martin f krafft wrote:
> also sprach Stefano Zacchiroli <zack@...> [2008.09.30.0932 +0200]:
> > Hence, I see no need of versioning the patch series. Having just
> > the last series, most likely in the Debian source package, would
> > be enough.
> 
> I always thought the point of tagging commits in the VCS was to be
> able to recreate pristine Debian source packages, no? Why do we
> bother tagging packages debian/1.0-1 if the tag cannot be used to
> actually obtain the tree that was used to build the package?

The point of tagging commits is to be able to go back to a particular
moment in the development history; this is unrelated with the ability
of recreating _pristine_ Debian source package IMO. Without versioning
patch series you can go back to any previously tagged moment in time,
full stop.

Yet you won't be able to recreate the pristine source package, I
agree, but is that even a requirement? The tagging need we have for
debian/x.y.z tags is to be able to go back to, say, the version in
stable of a package and develop on top of it, who cares if you won't
be able to recreate the exactly same package? Also, that package is
available in the Debian archive (or on snapshot.d.o, when we will have
one ...).
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 30 Sep 10:42
Favicon

Re: recreating historic packages (was: Introductory mail)

also sprach Stefano Zacchiroli <zack <at> debian.org> [2008.09.30.1036 +0200]:
> [ unrelated: is the list configured to not deliver a message Cc-ed
> to a subscriber also via the list?

This is a per-user setting in Mailman.

> Please avoid Cc-ing me, since the result is that I receive the
> message only in my INBOX and (I guess due to the setting above)
> without a List-Id header ... ]

Sorry.

> Yet you won't be able to recreate the pristine source package,
> I agree, but is that even a requirement? The tagging need we have
> for debian/x.y.z tags is to be able to go back to, say, the
> version in stable of a package and develop on top of it, who cares
> if you won't be able to recreate the exactly same package?

Because the topgit branches you used to create the stable package
cannot be used anymore to create the patches that went into the
stable package. You can return to the stable version of ./debian and
probably upstream, but with the current topgit, you can then only
apply the most recent topic branch patches, which may or may not
apply or be applicable.

If you don't see what I mean, recreate topgit 0.2, which was in the
archive but isn't anymore, without using the build branch.

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 30 Sep 21:04
Favicon

Re: recreating historic packages (was: Introductory mail)

On Tue, Sep 30, 2008 at 10:42:37AM +0200, martin f krafft wrote:
> > who cares if you won't be able to recreate the exactly same
> > package?
> Because the topgit branches you used to create the stable package
> cannot be used anymore to create the patches that went into the
> stable package.

OK, my bad than, I didn't know this (rather gory) detail. I thought it
was just a problem of not being able to create the exact
representation (e.g., to preserve checksums of the source package), I
didn't get that there were situations in which it wasn't possible to
serialize to patch series at all.

Cheers.

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
martin f krafft | 30 Sep 22:01
Favicon

Re: recreating historic packages (was: Introductory mail)

also sprach Stefano Zacchiroli <zack@...> [2008.09.30.2104 +0200]:
> OK, my bad than, I didn't know this (rather gory) detail. I thought it
> was just a problem of not being able to create the exact
> representation (e.g., to preserve checksums of the source package), I
> didn't get that there were situations in which it wasn't possible to
> serialize to patch series at all.

Not yet at least. See Teemu's algorithm, which I have yet to check
out.

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"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

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
Teemu Ikonen | 30 Sep 12:22

Re: recreating historic packages (was: Introductory mail)

On Tue, Sep 30, 2008 at 10:02 AM, martin f krafft <madduck@...> wrote:
> I always thought the point of tagging commits in the VCS was to be
> able to recreate pristine Debian source packages, no? Why do we
> bother tagging packages debian/1.0-1 if the tag cannot be used to
> actually obtain the tree that was used to build the package?

The obvious, although perhaps inelegant way to solve the storage of
the released debian source would be to modify pristine-tar to work
with deb-source packages and store them in a branch of their own,
maybe called "released-deb" or similar. The storage overhead for this
would be minimal, just the size of the compressed patches.

On the other hand, if all the topgit branches are merged into master
(or build) branch before release, it should be possible to walk the
history graph to recreate the patch without any other information.
Would this algorithm work:

First, find a path from tagged release commit in master to the commit
in topgit branch patch/x preceding the commit in master where patch/x
was last merged in. Let's call this commit Px. Next, starting from Px,
find the commit in top-bases/patch/x preceding the last merge of
top-bases/patch/x to patch/x and call this commit Bx. The patch can
then be recreated from diff(Bx, Px) and .topmsg at Px.

Teemu
Permalink | Reply |
headers
Stéphane Glondu | 30 Sep 12:45

Re: recreating historic packages

Teemu Ikonen wrote:
> The obvious, although perhaps inelegant way to solve the storage of
> the released debian source would be to modify pristine-tar to work
> with deb-source packages and store them in a branch of their own,
> maybe called "released-deb" or similar. The storage overhead for this
> would be minimal, just the size of the compressed patches.

The idea crossed my mind :-)

> First, find a path from tagged release commit in master to the commit
> in topgit branch patch/x preceding the commit in master where patch/x
> was last merged in. Let's call this commit Px. Next, starting from Px,
> find the commit in top-bases/patch/x preceding the last merge of
> top-bases/patch/x to patch/x and call this commit Bx. The patch can
> then be recreated from diff(Bx, Px) and .topmsg at Px.

top-bases/* are just references, right? If so, I don't see what you mean
by "find the commit in top-bases/patch/x [...] and call this commit Bx".
How would you achieve this?

--

-- 
Stéphane


Teemu Ikonen wrote:
> The obvious, although perhaps inelegant way to solve the storage of
> the released debian source would be to modify pristine-tar to work
> with deb-source packages and store them in a branch of their own,
> maybe called "released-deb" or similar. The storage overhead for this
(Continue reading)

Permalink | Reply |
headers
Teemu Ikonen | 30 Sep 13:05

Re: recreating historic packages

On Tue, Sep 30, 2008 at 12:45 PM, Stéphane Glondu <steph@...> wrote:
> Teemu Ikonen wrote:
>> First, find a path from tagged release commit in master to the commit
>> in topgit branch patch/x preceding the commit in master where patch/x
>> was last merged in. Let's call this commit Px. Next, starting from Px,
>> find the commit in top-bases/patch/x preceding the last merge of
>> top-bases/patch/x to patch/x and call this commit Bx. The patch can
>> then be recreated from diff(Bx, Px) and .topmsg at Px.
>
> top-bases/* are just references, right? If so, I don't see what you mean
> by "find the commit in top-bases/patch/x [...] and call this commit Bx".
> How would you achieve this?

AFAIK, all branches in git are "just references", and branch names are
not stored in commit objects. The proposed program would have to do a
preliminary pass through the revision graph starting from the branch
heads (patch/x and top-bases/patch/x) and tag all the commits it can
reach as belonging to these branches. Gitk already does this to show
which branches a given commit belongs to and it does it reasonably
fast, at least on my smallish repositories.

Teemu
Permalink | Reply |
headers
Stéphane Glondu | 30 Sep 13:28

Re: recreating historic packages

Teemu Ikonen wrote:
> AFAIK, all branches in git are "just references", and branch names are
> not stored in commit objects. The proposed program would have to do a
> preliminary pass through the revision graph starting from the branch
> heads (patch/x and top-bases/patch/x) and tag all the commits it can
> reach as belonging to these branches. [...]

Sure, but you are assume topbases/* are behaving like branches, which
they are not. Correct me if I'm wrong, but it seems that these
references basically "randomly" jump with topgit.

--

-- 
Stéphane


_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
Teemu Ikonen | 30 Sep 14:31

Re: recreating historic packages

On Tue, Sep 30, 2008 at 1:28 PM, Stéphane Glondu <steph <at> glondu.net> wrote:
> Teemu Ikonen wrote:
>> AFAIK, all branches in git are "just references", and branch names are
>> not stored in commit objects. The proposed program would have to do a
>> preliminary pass through the revision graph starting from the branch
>> heads (patch/x and top-bases/patch/x) and tag all the commits it can
>> reach as belonging to these branches. [...]
>
> Sure, but you are assume topbases/* are behaving like branches, which
> they are not. Correct me if I'm wrong, but it seems that these
> references basically "randomly" jump with topgit.

Well, "tg help update" says (in topgit 0.3):

	Update the current topic branch wrt. changes in the branches
	it depends on and remote branches.
	This is performed in two phases - first,
	changes within the dependencies are merged to the base,
	then the base is merged into the topic branch.
	The output will guide you in case of conflicts.

	In case your dependencies are not up-to-date, tg update
	will first recurse into them and update these.

	If a remote branch update brings dependencies on branches
	not yet instantiated locally, you can either bring in all
	the new branches from the remote using 'tg remote --populate'
	or only pick out the missing ones using 'tg create -r'
	('tg summary' will point out branches with incomplete
	dependencies by showing an '!' near to them).
(Continue reading)

Permalink | Reply |
headers
Stéphane Glondu | 30 Sep 16:48

Re: recreating historic packages

Teemu Ikonen wrote:
> 	Update the current topic branch wrt. changes in the branches
> 	it depends on and remote branches.
> 	This is performed in two phases - first,
> 	changes within the dependencies are merged to the base,
> 	then the base is merged into the topic branch.
> 	The output will guide you in case of conflicts.

Thank you for spotting this, I had missed that.

> This would indicate that bases are managed by merging (which naturally
> can be a fast-forward merge) and not rebasing or otherwise rewriting
> history. The same applies for topic branches, which are merged to the
> latest base (and not rebased).

I wasn't thinking of rebasing or any other kind of rewriting history.
But indeed, the way topgit does thing is cleaner that what I thought.

> I haven't checked the implementation though, so there might be
> something more complicated going on behind the scene.

I understand better your original algorithm, now. And indeed, it seems a
good idea.

--

-- 
Stéphane


_______________________________________________
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 30 Sep 22:38
Favicon

Bug#500656: how tg-update works (was: recreating historic packages)

also sprach Teemu Ikonen <tpikonen <at> gmail.com> [2008.09.30.1431 +0200]:
> This would indicate that bases are managed by merging (which naturally
> can be a fast-forward merge) and not rebasing or otherwise rewriting
> history. The same applies for topic branches, which are merged to the
> latest base (and not rebased).

topgit never rebases, by design.

What happens on tg-update is that for every out-of-date dependency,
it is merged into top-bases/$name, and then top-bases/$name is
merged into $name.

This causes top-bases/$name to point to a commit with a tree that
has all dependencies merged and up-to-date, and $name has a tree
with all dependencies and the changes tracked in $name. Thus,
tg-patch just diffs the two to get the patch. I love it!

tg-tag would simply tag the tip and the current top-base, and then
tg-patch, when given a tag, would not diff tip to top-base, but the
pair of tags.

At the time when I created topgit 0.2-1, the debian/locations branch
was at 355c550 and its base at 6433286. Thus, the patch was:

  git diff 6433286 355c550 | filterdiff -p1 -x .top\*

(the .top* files have to be removed, which tg-patch automates).

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 30 Sep 21:08
Favicon

Re: recreating historic packages (was: Introductory mail)

On Tue, Sep 30, 2008 at 12:22:03PM +0200, Teemu Ikonen wrote:
> The obvious, although perhaps inelegant way to solve the storage of
> the released debian source would be to modify pristine-tar to work
> with deb-source packages and store them in a branch of their own,
> maybe called "released-deb" or similar. The storage overhead for this
> would be minimal, just the size of the compressed patches.

Actually, it doesn't look inelegant