Bug#706957: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
Hi Mathias,
On Wed, May 22, 2013 at 01:01:00PM +0200, Mathias Behrle wrote:
> > In general I'm working in teams were the VCS is hosted on alioth.org and
> > where I have commit permissions.
>
> Completely agreed for team maintenance, all Debian Tryton Maintainers stuff is
> organized like that. My previous sponsor (Daniel Baumann) retired, so the team
> currently is as small as a team can be...;) If you are willing to step in I
> will be happy to put you in Uploaders as well as receiving an ssh key for
> commit access.
Well, perhaps my wording was not as precise as it should have been. I
do not really want to become a team member. My focus inside the
sentence above was *on* *alioth.org* where I just have an ssh key and
the repositories I'm working have usually ACLs set that any DD can
commit. I will definitely not become an "Uploader".
> > It is not that I usually would tend to
> > commit a lot. But sometimes it is just simpler to commit a small fix
> > than explaining the sponsee what I want to be changed.
>
> Since we are obviously using a little bit different workflow I would prefer to
> talk first until we know, which fixes should be applied.
OK, than I will not commit but send `git diff` created patches.
> > Because I prefer working with VCS rather than mentors I gave your Git
> > repository a try:
> >
> > $ git-buildpackage
> > ...
> > gbp:error: Use --git-ignore-new to ignore.
> >
> > The reason is that you intentionally are deleting
> > trytond_stock_lot.egg-info which is part of upstream tarball. People
> > (like me) who are keen on creating packages that are building twice in a
> > row would prefer to rather move the package out of the way, lets say to
> > trytond_stock_lot.hen-info and restore it afterwards.
>
> Deleting *.egg-info is just for the purpose to be able to build the package
> twice. Please read below.
>
> > However, I was running git-buildpackage --git-ignore-new which worked.
> > So I would not have used the issue above as a showstopper specifically
> > when targeting at experimental.
>
> I am following the workflow of git-stuff [1], which until now for me gives
> clean and stable results. The Tryton packages so far use pure debhelper
> and I am building just with with debuild/dpkg-buildpackage (no use of
> git-build-package).
I coan confirm that building twice in a row works with plain debuild.
However, even if I have mixed feelings with git-buildpackage sometimes I
think it is correct here because your way is rather a hack but a
solution because after building the source tree once it is different
from the upstream unpacked tarball. As I said - this is nothing which
would prevent me from sponsering but I wanted to give the hint that the
clean solution would to move the dir out of the way and restore it
later.
> > But there is finally one issue which let me refrain from a final upload
> > because the file debian/docs is different in Git and on mentors. So I
> > do not have an idea what you really want to be uploaded. Please bring
> > both into sync and I'll sponsor what I will find in Git once you have
> > confirmed that this is OK.
>
> I think you are building from HEAD, not from the release tag. Thus I suppose the
> doc patch [2] in VCS is making the difference.
>
> Doing
> git checkout debian/2.8.0-1
> debuild
> should just do the job.
Uhmmm, that's true but comes unexpected! How can you know that a
sponsor will upload the status you tagged as release? I can confirm
that it is fine for me to upload that way (even if this ignores my hint
to rename debian/<pkg>.docs to debian/docs) but if I had other issues
the tag would be wrong. It seems that you are not expecting your
sponsor to work in the same VCS as you.
> [2]
> http://debian.tryton.org/gitweb?p=packages/tryton-modules-stock-lot.git;a=commit;h=d30bd8f1e4e0901c089c358346fe1b8cd682eb49
BTW, despite what you wrote about this patch in PM it is wrong anyway
because it creates a dir
/usr/share/doc/tryton-modules-stock-lot/doc
which is simply stupid and your argument that there will be more docs in
this dir is not correct. I'd recommend to stick to my proposed patch in
the future.
I guess if I try to use your Git repository it creates more friction
than needed and so I fall back to mentors.d.n method and upload what I
find there. I just did so for tryton-modules-stock-lot_2.8.0-1.
However, my strong advise is the following: If you really want to
increase the size of the team you should definitely migrate to the usual
Debian infrastructure for development on Alioth. I can't see a reason
that might make Tryton that special that the infrastructur that exists
should not be sufficient. Using different ways for development
increases your chances to remain alone.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: