[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Standardizing the layout of git packaging repositories



On Friday, August 15, 2014 23:04:54 brian m. carlson wrote:
> On Fri, Aug 15, 2014 at 08:17:16PM +0200, Marco d'Itri wrote:
> > On Aug 15, Raphael Hertzog <hertzog@debian.org> wrote:
> > > - are there other important things to standardize?
> > 
> > Do not try to make other people change their workflows without evident
> > benefits (pro tip: "standardization" in itself is not one) or they will
> > be annoyed and just ignore your work.
> 
> I send a lot of one-off patches to packages.  I like to file a bug and
> follow it up with a patch.  Unfortunately, everybody doing things a
> different way makes it unpleasant to do that.  (And yes, I know about
> README.source.)
> 
> Right now, I just build the source package repeatedly until it works,
> unless the package doesn't build twice in a row, in which case I swear
> repeatedly and no patch is sent.  If there's a standard workflow, it
> makes my life easier and results in a patch that works better for the
> maintainer.

This gets to why, for teams I work in where full source git branches are used, 
I really like git-dpm.  The output of the git-dpm workflow is a version 3.0 
(quilt) package with all the upstream changes in segregated patches per commit 
so they make logical sense.  That way, any third party that needs to address 
an issue in the package can do so with no reference at all to a VCS repo.  
They just work on the Debian source package that is available in the most 
common type that is used in the archive.

The packager's VCS is mostly useful for the people who normally work on the 
package.  For others, the source package is the most useful thing.  About the 
only thing I use the VCS of packages that aren't normally ones I work on for 
is to understand the history of something to try and figure out where it went 
wrong.

Whatever is "standardized" it really, really ought to produce a useful source 
package as that's the preferred form of modification in the project.

Scott K

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: