Bug#847681: packaging repository and sid diverging? Various fixes needed.
On 14/12/16 23:41, Ben Hutchings wrote:
> On Tue, 2016-12-13 at 20:55 +0100, Daniel Pocock wrote: [...]
>> Thanks for providing this feedback
>>
>> I've done the following: - forked the upstream repository
>
> The existing packaging repos are also based on the upstream git
> repo.
>
OK, I see that now, but I notice that the debian/* files have been
committed on the master branch. This was confusing for me as it is
not clear which commits are real upstream commits on that branch and
which commits are the work of maintainers (unless you look inside the
commit to see what changes).
It would be nicer to have the master branch as a pure copy of
upstream's master branch and then have a branch called debian/sid with
the commits made by package maintainers. Is there an easy way to
adapt the existing repository to that model? If so, I could very
quickly re-apply my changes on top of it.
I think the master branch in that repo can simply be renamed to
debian/sid and then a new master created based on upstream's master.
Then we can periodically merge the tags (or tarballs) from the
upstream master into the debian/sid branch.
>> - created a debian/sid branch - copied debian/* from jessie into
>> that branch and committed - copied debian/* from sid into that
>> branch and committed - used "git format-patch" and "git am" to
>> copy in changes from your repo - merged upstream's 1.3.4 tag into
>> debian/sid - updated patches (many could be dropped) - other
>> small updates (home page, VCS fields) - pushed my repo into a new
>> location, collab-maint/nfs-utils
>
> This throws away all the packaging history, which I don't think is
> a good idea.
>
I agree and if we can have the history and have a pure copy of
upstream's master branch that would be ideal.
>> Please have a look at my repository structure and tell me if you
>> feel it is useful for this project. If not, my changes could be
>> extracted easily enough with git format-patch and applied into
>> your repository with git am and then we could start the
>> collab-maint/nfs-utils repository over again.
>>
>> Are you happy for this to live in collab-maint now? Maybe that
>> will encourage more collaborators. I've added a README.source
>> inviting contributions too.
>
> I'm happy for nfs-utils to move away from the kernel team, and
> that implies it should go in a different project on Alioth. I've
> never been very comfortable with collab-maint and I don't see the
> value in allowing everyone to push to a git repository (versus
> sending a pull request). However, as I'm not going to be
> maintaining it any more I don't claim a right to veto that.
>
In this case, I'm simply trying to find a safe way to move forward
with a package that is probably used quite widely.
> I think you should check whether Anibal and Steve want to continue
> being co-maintainers for nfs-utils and if so what their opinions
> are.
>
Yes, I was waiting for them to comment on all of this. I don't want
to be the only person involved in this package either so I'll let it
sit the way it is for a bit longer and give them time to respond.
Regards,
Daniel
Reply to: