Re: Keeping upstream commits separate from Debian packaging commits
Barry Warsaw wrote:
> On Oct 16, 2014, at 09:26 AM, Tristan Seligmann wrote:
>
>> I would expect it to make merging / rebasing Debian patches on top of
>> a new upstream version easier, since you have the granular history of
>> changes to the source tree, not one massive single commit which may
>> not be accurate (eg. renames of change files may not be detected
>> etc.). On the flip side, if there are few or no patches to the
>> upstream source, then it probably doesn't matter much at all.
>
> Yep. I get that, although it ought not to be *too* hard usually to just clone
> upstream separately and generate patches from there. But agreed that if there
> are a lot of those such things, it can be less convenient.
Having the upstream commits in the packaging repo is also quite useful if you
need to make a release that is not an official one, like based on a specific
commit rather than a tag. It also makes it easier to manage generating an
orig tarball if upstream does not make one. If the upstream git is very
active, then it can be annoying to follow the packaging commits.
>> I do think the benefits of team maintenance are diminshed quite a lot
>> when packages need to have such specialized instructions, so aiming
>> for a standardized workflow / configuration (*whatever* that might
>> be!) is valuable.
>
> Fully agreed. I feel strongly that we want to preserve the current team
> default where you can essentially just debcheckout any team package and not
> have to guess about its workflow.
>
> Cheers,
> -Barry
I also agree, a standard, documented workflow is very valuable.
.hc
Reply to: