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
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
On Tue, Jul 15, 2008 at 03:39:27PM -0700, Russ Allbery wrote:
> Hm, that's a good point. I'm not sure. It's possible that maintaining a
> distinction between manipulating the output source package and
> manipulating the revision control system is good. I've documented more
> details frequently o
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> I see. So basically you are accepting the fact that your .diff.gz get
> "dirty", considering (I guess) that patches are clear enough while
> looking at the git repo.
Yes. I'm not particularly happy with that, but it turns out that most of
my curre
On Wed, Jul 16, 2008 at 12:04:38AM +0200, Stefano Zacchiroli wrote:
> On Tue, Jul 15, 2008 at 01:45:16PM -0700, Russ Allbery wrote:
[..snip..]
> > FWIW, I've been keeping notes on what I'm personally doing at:
> > http://www.eyrie.org/~eagle/notes/debian/git.html
Very interesting reading!
>
>
