Re: Keeping upstream commits separate from Debian packaging commits
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.
>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
Reply to: