Re: TopGit: Is there still a need for a long-lived build branch?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.13.0055 +0200]:
> > I wish there was a way to combine both options: update all refs already
> > on the server *and* push any ref matching a certain pattern.
> 
> And I wish I'd been smart enough to try "Push: :" before complaining.
> 
> I guess I'll then file a wishlist against topgit, to replace the last
> "Push: *" line with ":" instead.

As I stated in #528442, TopGit is currently growing a tg-push
command, which should make those pushspecs obsolete.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"self-denial is the shining sore
 on the leprous body of christianity."
-- oscar wilde


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[Frédéric Brière]

Frédéric Brière  wrote:
> I wish there was a way to combine both options: update all refs already
> on the server *and* push any ref matching a certain pattern.

And I wish I'd been smart enough to try "Push: :" before complaining.

I guess I'll then file a wishlist against topgit, to replace the last
"Push: *" line with ":" instead.


-- 
 home is where the highest bandwidth is


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.07.0223 +0200]:
> I wish there was a way to combine both options: update all refs
> already on the server *and* push any ref matching a certain
> pattern.

I am sure that patch won't be hard to write. If you don't have the
time, maybe file a wishlist bug or bring it up on the mailing list?

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
the uncertainty principle:
  you can never be sure how many
  beers you had last night.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[Frédéric Brière]

martin f krafft  wrote:
> > (OTOH, I'm not particularly looking forward to having even more
> > top-* refs that I'll forget to push...)
>
> You know you can set it up to auto-push, right? ;)

Unfortunately, any Push line will turn off the default ":" behavior.
So, I either have to maintain a list of all pushable refs in git-config,
or remember to manually push any new top-* ref.

I wish there was a way to combine both options: update all refs already
on the server *and* push any ref matching a certain pattern.


-- 
 home is where the highest bandwidth is


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.06.1940 +0200]:
> Ah, I see.  Basically, your build branch is not TopGit-specific, but is
> an integral part of your workflow.  In that case, it certainly makes
> sense to export your patches there.  But am I right in assuming that you
> would still maintain a build branch even if you were not using TopGit?

I used to, but I don't think there's a point anymore. I don't see
any difference between treating the debian branch as a topic branch
and merging it into build last, or just doing all of debian/* on
master and merging upstream and topic branches into it. With mdadm,
which is a thorough mess right now (since I am the only one tracking
that repo I can afford to go wild), I am building maint/lenny and
debian/experimental directly, while master still gets merged into
build. I don't see a reason for that anymore.

Now, with TopGit, and specifically the need to recreate ancient
packages, well, see your other post... with TopGit right now, the
build branch makes sense.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
EARTH
  smog | bricks
 AIR  --  mud  -- FIRE
soda water | tequila
 WATER


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.06.2049 +0200]:
> Given what I previously said about all debian/* topic branches
> falling behind as soon as I commit something to master, I'm
> considering basing them off the upstream branch.  After all,
> there's no technical reason for basing them off master;
> I certainly won't be patching anything in debian/.

I thought it was a nice logical separation between features that are
intended for upstream, and features which we know are
Debian-specific. If you make the distinction, then you can tell
upstream to just track all branches off upstream (assuming TopGit
could identify them easily). OTOH, this is what namespaces
upstream/* and debian/* are for.

> > I still think the proper solution is the one discussed in
> > #500656, specifically to implement refs/top-tags, which holds
> > */base and */tip tags for each tg-tag. I don't actually think
> > this is very hard to implement, but I've not been able to make
> > time for it. If you
> 
> Hmm, I initially dismissed this as something I didn't need, but on
> second thought (yeah, thanks Gmane) there is some appeal to the
> idea of being able to run tg-cleanexport for previous versions.
> Maybe this could also be useful for backports and security
> updates?
> 
> (OTOH, I'm not particularly looking forward to having even more
> top-* refs that I'll forget to push...)

You know you can set it up to auto-push, right? ;)

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"emacs sucks, literally, not an insult, just a comment that it's
 large enough to have a noticeable gravitational pull..."
   -- mercury on #debian-devel


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[Frédéric Brière]

(Grr, I'd forgotten how Gmane silently loses posts the first time.)

martin f krafft  wrote:
> … the thought of having debian/patches/* with a given patch foo
> inside the topic branch that creates foo just seems sort of, uh,
> cyclical to me, even though (Top)Git won't care as long as you don't

I hadn't thought about that.  You're right, it *is* yucky.

Given what I previously said about all debian/* topic branches falling
behind as soon as I commit something to master, I'm considering basing
them off the upstream branch.  After all, there's no technical reason
for basing them off master; I certainly won't be patching anything in
debian/.

> Go see how things pan out for you.

Thanks!  Just wanted to make sure I wasn't missing something obvious.

> I still think the proper solution is the one discussed in #500656,
> specifically to implement refs/top-tags, which holds */base and
> */tip tags for each tg-tag. I don't actually think this is very hard
> to implement, but I've not been able to make time for it. If you

Hmm, I initially dismissed this as something I didn't need, but on
second thought (yeah, thanks Gmane) there is some appeal to the idea of
being able to run tg-cleanexport for previous versions.  Maybe this
could also be useful for backports and security updates?

(OTOH, I'm not particularly looking forward to having even more top-*
refs that I'll forget to push...)

Not that I'm volunteering right now, though.  :)  I've got enough on my
plate for the moment.  (Heck, I've been piling up logcheck reports for
over a year now.  Maybe I should start with *that*.)


-- 
 home is where the highest bandwidth is


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[Frédéric Brière]

James Vega  wrote:
> From my perspective, it's still worthwhile.  The build branch is where
> integration of all changes to the upstream package happens.  This
> includes pulling in the packaging changes (aka, debian/) which happens
> on the master branch.

Ah, I see.  Basically, your build branch is not TopGit-specific, but is
an integral part of your workflow.  In that case, it certainly makes
sense to export your patches there.  But am I right in assuming that you
would still maintain a build branch even if you were not using TopGit?

To answer my own question, I would say that the issue of a build branch
is somewhat TopGit-agnostic: if you already have one, use it; otherwise,
there's not much of a point in creating one just to hold the patches.


-- 
 Joy: thanks, joy
 elmo: that's redundant, elmo
 doogie: go play in traffic
 ah, the elmo we know and love


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: autogenerating debian/NEWS (was: TopGit: Is there still a need for a long-lived build branch?)

[James Vega]

On Tue, May 05, 2009 at 09:59:01PM +0200, martin f krafft wrote:
> also sprach James Vega  [2009.05.05.2135 +0200]:
> > Files that are purely a result of the final integration (like
> > debian/changelog, debian/NEWS, and debian/patches/*) only exist in the
> > integration branch.  This provides a clean separation between the
> > changes I'm actively making to handle the debianization of the upstream
> > source and the changes that are only being made in the process of an
> > upload.
> 
> How do you generate debian/NEWS?

With `dch --news' and my fingers. :) I don't (yet) have either
debian/changelog or debian/NEWS generated and I'm not sure that'd be
easy for the latter.  It just doesn't make sense to me to have either of
these files on branches other than the ones from which releases are cut.

I'm more comfortable with collating the commit logs into
debian/changelog using a tool like git-dch and then massaging the data
into what's relevant for a user-facing changelog.

I guess one could use specific commit log formatting and automate
pulling that metadata out into the debian/NEWS and debian/changelog
entries, but I haven't given much thought to it.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

autogenerating debian/NEWS (was: TopGit: Is there still a need for a long-lived build branch?)

[martin f krafft]

also sprach James Vega  [2009.05.05.2135 +0200]:
> Files that are purely a result of the final integration (like
> debian/changelog, debian/NEWS, and debian/patches/*) only exist in the
> integration branch.  This provides a clean separation between the
> changes I'm actively making to handle the debianization of the upstream
> source and the changes that are only being made in the process of an
> upload.

How do you generate debian/NEWS?

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
half a bee, philosophically, must ipso facto half not be.
but half the bee has got to be, vis-a-vis its entity. you see?
but can a bee be said to be or not to be an entire bee,
when half the bee is not a bee, due to some ancient injury?
   -- monty python


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.05.2118 +0200]:
> Maybe it's just me, but I can't see the point in having a dedicated
> long-lived[2] build branch separate from master anymore.

The point for me is inherent in #500656: to be able to obtain the
source tree for a package in history, which TopGit cannot yet do.

You say that you are exporting all patches to master. If you commit
them there, then indeed there seems to be little point in having
a build branch, but…

> The only thing I can think of is that after running
> tg-cleanexport,
[and commit]
> all debian/* topic branches (which are based on master) will
> automatically be marked as requiring an update.

… the thought of having debian/patches/* with a given patch foo
inside the topic branch that creates foo just seems sort of, uh,
cyclical to me, even though (Top)Git won't care as long as you don't
modify the patch inside the topic branch.

Go see how things pan out for you.

I still think the proper solution is the one discussed in #500656,
specifically to implement refs/top-tags, which holds */base and
*/tip tags for each tg-tag. I don't actually think this is very hard
to implement, but I've not been able to make time for it. If you
want to have a shot, count me in on supporting you and helping out
with explanations of TopGit internals, feedback, and ideas (if you
want them).

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"if confronted with a choice between all the truth in god's right hand
 and the ever live struggle for truth, coupled with eternal error, in
 god's left, i would choose the left."
   -- gotthold lessing


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: Is there still a need for a long-lived build branch?

[James Vega]

On Tue, May 05, 2009 at 03:18:51PM -0400, Frédéric Brière wrote:
> I've recently converted my opencbm[1] package to TopGit, adopting a
> workflow similar to that suggested by Martin.  The main difference is
> that instead of maintaining a separate long-lived build branch, I'm
> exporting all patches directly on master.
> 
> Maybe it's just me, but I can't see the point in having a dedicated
> long-lived[2] build branch separate from master anymore.  It certainly
> made a lot of sense before TopGit, when all topic branches were merged
> into the (messy) integration branch.  But now, the topic branches are
> cleanly exported into debian/patches.

From my perspective, it's still worthwhile.  The build branch is where
integration of all changes to the upstream package happens.  This
includes pulling in the packaging changes (aka, debian/) which happens
on the master branch.

Files that are purely a result of the final integration (like
debian/changelog, debian/NEWS, and debian/patches/*) only exist in the
integration branch.  This provides a clean separation between the
changes I'm actively making to handle the debianization of the upstream
source and the changes that are only being made in the process of an
upload.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

TopGit: Is there still a need for a long-lived build branch?

[Frédéric Brière]

Hiya everybody,

I've recently converted my opencbm[1] package to TopGit, adopting a
workflow similar to that suggested by Martin.  The main difference is
that instead of maintaining a separate long-lived build branch, I'm
exporting all patches directly on master.

Maybe it's just me, but I can't see the point in having a dedicated
long-lived[2] build branch separate from master anymore.  It certainly
made a lot of sense before TopGit, when all topic branches were merged
into the (messy) integration branch.  But now, the topic branches are
cleanly exported into debian/patches.

Can someone point out an advantage in having a build branch, or a
drawback in not having one?  The only thing I can think of is that after
running tg-cleanexport, all debian/* topic branches (which are based on
master) will automatically be marked as requiring an update.  I don't
really mind, since they're bound to fall behind anyway.  (I'll be damned
if I update them on every single master commit.)


 [1] 
 [2] Of course, this discussion does not apply to throwaway branches.


-- 
* SynrG notes that the number of configuration questions to answer in sendmail
  is NON-TRIVIAL
-- Seen on #Debian

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss