* Andreas Tille: " Bug#706957: [Ping] Bug#706957: RFS:
tryton-modules-stock-lot/2.8.0-1 [ITP]" (Wed, 22 May 2013 14:15:45 +0200):
Hi Andreas,
sorry for responding late. I was consumed by work and I have to do Debian in my
free time.
>> > 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?
Because this is exactly the state, when I uploaded to mentors.d.o. For me it is
rather unexpected, that you ask me to follow official guidelines (thus
uploading to mentors and posting the RFS) and afterwards you don't want to use
that package. For me it is absolutely clear, that I have to tag a state, when I
am proposing a package to you via mentors.d.o, because the state in the VCS will
change permanently following further development. If I am proposing version
2.8.0-1 (as written in the changelog) to you, it is absolutely logic for me to
tag that state.
> 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.
Your hint is not ignored, but I will for sure consider it in further
development. Please take into account, that in the maintenance of a series of
similar packages like the Tryton modules you are best to keep the layout very
strictly together. So if I change tryton-modules-stock-lot in this repsect, I
will change all.
> It seems that you are not expecting your sponsor to work in the same VCS as
> you.
I don't understand this sentence.
>> [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.
First I would personally refrain from qualifying anyones work as
'simply stupid'.
Second I saw exactly this behavior in other Debian packages and after thinking
quite a while found it useful. Having the module documentation (in rst format)
mixed up with the standard Debian documentation is confusing. Separating it in
its proper doc subdirectory should make clear, that this is really upstream
documentation. YMMV of course.
> 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.
As already said I had expected this in the first place anyway. Additionally I
don't see any friction in using the git repositories. They are in sync with
what is officially uploaded and for that purpose they are tagged.
> 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.
Debian infrastructure for sure is lacking features to be able to build all
sorts of needed Tryton packages. I pointed this already out in an earlier mail
and can do it once again. Tryton uses a release cycle of 6 months, providing
bug fix releases for 2 years. No way to get this currently into Debian.
Furthermore I just gave a try to Alioth. After registering an account (as
-guest, while I am DM, hmm;)) I am told at the wiki [3]:
"Anyone can ask for a new project on Alioth but it will only be approved if it
respects the project approval policy."
While the link to "ask for a new project [3][1]" just isn't really helpful,
"Anyone" according to [2] seems to be rather a synoym for DD.
So I will have still to ask a DD to sponsor the project etc., creating even
more overhead. My time for Debian is limited and the time I am currently using
to just follow administrative procedures takes a lot of it. I prefer to do real
work on my packages than to create overhead.
Reading the policy I read
"We may also approve other projects on a case by case basis, for
example:
[...]
- Any other project where you can convince the Alioth's
administrators that it will help Debian achieve World Domination."
Be it a joke or not, I cannot apply to such policy.
Thanks for uploading tryton-modules-stock-lot in the meantime. I would be
happy, if you also could do for the other modules (not gnuhealth related
modules) for the sake of all Tryton users.
Best regards,
Mathias
[1] http://alioth.debian.org/register/
[2] http://lists.debian.org/debian-devel-announce/2003/03/msg00024.html
[3] http://wiki.debian.org/Alioth
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Attachment:
signature.asc
Description: PGP signature