I'm a happy (Debian) package maintainer which have just switched most of
his packages from svn to git. All nice, finally I can work directly on a
real source code tree instead of fiddling with patch management system.
Nevertheless, patches are separate in topic branches which enable
knowing the con
Hi all (again),
with $DVCS the branch layout for a given package can become quite
complex, and AFAICS there is no agreed upon convention on branch layout.
Just the single choice of whether to use branches just for work and then
serialize changes in patch series or not drastically differentiate th
On Tue, Jul 15, 2008 at 01:38:14PM -0500, John Goerzen wrote:
> I don't split out patches, but all my Debian packages live on
> git.debian.org (except software where I'm the upstream, in which case
> it's on my own git server). Using gitweb, people can inspect the
> changelog and download diffs of
Stefano Zacchiroli wrote:
> Specifically for Debian: do we have any guideline on how to do that? If
> not it is probably worth to create one ...
>
> And finally, the problem of the problems: how about the situation where
> one patch for topic branch is not enough as topic branches have got
> inter
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> My question is whether we have a guideline about *where* to document
> branch layout for a given package. Regarding Debian,
> debian/README.source comes to mind quickly, but its current description
> in policy does not make it clear that it is the s
On Tue, Jul 15, 2008 at 01:45:16PM -0700, Russ Allbery wrote:
> > branch layout for a given package. Regarding Debian,
> > debian/README.source comes to mind quickly, but its current description
> > in policy does not make it clear that it is the suitable place where to
> > document branch layout.
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> I take your word on this :-), ... but can I suggest to improve the
> wording of Policy 4.14 to make it clearer? As it is right now the
> wording is totally source package oriented. Hence, if one has a source
> package which is entirely VCS-free (as
