Debian Bug report logs - #706957
RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: submit@bugs.debian.org

Cc: Andreas Tille <andreas@an3as.eu>

Subject: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Mon, 6 May 2013 14:35:04 +0200

[Message part 1 (text/plain, inline)]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package
  "tryton-modules-stock-lot"

 * Package name    : tryton-modules-stock-lot
   Version         : 2.8.0-1
   Upstream Author : Tryton project (www.tryton.org)
 * URL             : http://downloads.tryton.org/2.8/
 * License         : GPL-3+
   Section         : python

  It builds those binary packages:

    tryton-modules-stock-lot - Tryton Application Platform (Stock Lot Module)

  To access further information about this package, please visit the following
  URL:

  http://mentors.debian.net/package/tryton-modules-stock-lot


  Alternatively, one can download the package with dget using this command:

    dget -x
    http://mentors.debian.net/debian/pool/main/t/tryton-modules-stock-lot/tryton-modules-stock-lot_2.8.0-1.dsc


  More information about Tryton can be obtained from http://www.tryton.org
  Debian packaging for Tryton is hosted at http://debian.tryton.org

  Regards,
   Mathias Behrle

[signature.asc (application/pgp-signature, attachment)]

Message #12 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: 706957@bugs.debian.org

Cc: debian-python@lists.debian.org, debian-med@lists.debian.org, Andreas Tille <andreas@an3as.eu>

Subject: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Tue, 21 May 2013 17:12:42 +0200

[Message part 1 (text/plain, inline)]

* Mathias Behrle: " Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1
  [ITP]" (Mon, 6 May 2013 14:35:04 +0200):

CCing specific audience debian-med@lists.debian.org and
debian-python@lists.debian.org

Dear mentors,

could you please reconsider the RFS for this (and other) Tryton module(s)? Two
weeks have passed without a response.

The list of new packaged Tryton modules can be seen at [1] (ITPs) resp. [2]
(RFSs). VCS for packaging can be found at [7].

They all add important new functionality to the Tryton framework. Especially
this one (tryton-modules-stock-lot) is needed as dependency for the package
gnuhealth [3] currently waiting in experimental. gnuhealth contains another set
of Tryton modules providing the functionality of GNU Health, a free Health and
Hospital Information System.

All packages are packaged in the same way and they are free of lintian pedantic
warnings (the one indicated being outdated [5]). So checking one is checking
almost all of them, thus reducing the work load which could seem apparently
high for 19 packages. Basically the complete suite of Tryton packages [6] is
currently bug free, and I am doing my best to keep this state. I was already
signalled to get DM Upload permissions for those new modules as I have already
for the other packages. So sponsoring would be a one-shot and not a permanent
task.


I would appreciate a lot, if a sponsor could step up soon, because I would have
preferred to upload the whole Tryton suite (which is still waiting from the
freeze in experimental) together with the new modules at once to unstable. 

Thanks a lot for considering,
Mathias


[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=wnpp
[2]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=sponsorship-requests
[3] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnuhealth/trunk/
[4] http://health.gnu.org/index.html
[5] http://lists.debian.org/debian-lint-maint/2012/07/msg00007.html
[6] http://packages.debian.org/search?keywords=tryton
[7] http://debian.tryton.org/gitweb/


> Package: sponsorship-requests
> Severity: wishlist
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package
>   tryton-modules-stock-lot
> 
>  * Package name    : tryton-modules-stock-lot
>    Version         : 2.8.0-1
>    Upstream Author : Tryton project (www.tryton.org)
>  * URL             : http://downloads.tryton.org/2.8/
>  * License         : GPL-3+
>    Section         : python
> 
>   It builds those binary packages:
> 
>     tryton-modules-stock-lot - Tryton Application Platform (Stock Lot Module)
> 
>   To access further information about this package, please visit the following
>   URL:
> 
>   http://mentors.debian.net/package/tryton-modules-stock-lot
> 
> 
>   Alternatively, one can download the package with dget using this command:
> 
>     dget -x
>     http://mentors.debian.net/debian/pool/main/t/tryton-modules-stock-lot/tryton-modules-stock-lot_2.8.0-1.dsc
> 
> 
>   More information about Tryton can be obtained from http://www.tryton.org
>   Debian packaging for Tryton is hosted at http://debian.tryton.org
> 
>   Regards,
>    Mathias Behrle




-- 

    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

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: debian-med@lists.debian.org

Cc: Mathias Behrle <mathiasb@m9s.biz>, 706957@bugs.debian.org

Subject: Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Tue, 21 May 2013 18:02:38 +0200

Hi Mathias,

thanks for the ping and for working on the tryton modules.

On Tue, May 21, 2013 at 05:12:42PM +0200, Mathias Behrle wrote:
> * Mathias Behrle: " Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1
>   [ITP]" (Mon, 6 May 2013 14:35:04 +0200):
> 
> CCing specific audience debian-med@lists.debian.org and
> debian-python@lists.debian.org
> 
> Dear mentors,
> 
> could you please reconsider the RFS for this (and other) Tryton module(s)? Two
> weeks have passed without a response.
> 
> ...
>
> I would appreciate a lot, if a sponsor could step up soon, because I would have
> preferred to upload the whole Tryton suite (which is still waiting from the
> freeze in experimental) together with the new modules at once to unstable. 

In general I'm working in teams were the VCS is hosted on alioth.org and
where I have commit permissions.  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.

Because I prefer working with VCS rather than mentors I gave your Git
repository a try:

$ git stash
Saved working directory and index state WIP on debian: d30bd8f Moving doc/index.rst to appropriate subdirectory doc.
HEAD is now at d30bd8f Moving doc/index.rst to appropriate subdirectory doc.
$ git-buildpackage
dh clean --with python2
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot'
dh_auto_clean
running clean
'build/lib.linux-x86_64-2.6' does not exist -- can't clean it
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.6' does not exist -- can't clean it
running clean
'build/lib.linux-x86_64-2.7' does not exist -- can't clean it
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.7' does not exist -- can't clean it
rm -rf *.egg-info
make[1]: Leaving directory `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot'
   dh_clean
gbp:error: You have uncommitted changes in your source tree:
gbp:error: # On branch debian
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    trytond_stock_lot.egg-info/PKG-INFO
#       deleted:    trytond_stock_lot.egg-info/SOURCES.txt
#       deleted:    trytond_stock_lot.egg-info/dependency_links.txt
#       deleted:    trytond_stock_lot.egg-info/entry_points.txt
#       deleted:    trytond_stock_lot.egg-info/not-zip-safe
#       deleted:    trytond_stock_lot.egg-info/requires.txt
#       deleted:    trytond_stock_lot.egg-info/top_level.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

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.

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.

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.

Kind regards

        Andreas.

-- 
http://fam-tille.de

Message #22 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Andreas Tille <andreas@an3as.eu>, 706957@bugs.debian.org

Cc: debian-med@lists.debian.org, tryton-debian@lists.virtual-things.org

Subject: Re: Bug#706957: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Wed, 22 May 2013 13:01:00 +0200

[Message part 1 (text/plain, inline)]

* Andreas Tille: " Bug#706957: [Ping] Bug#706957: RFS:
  tryton-modules-stock-lot/2.8.0-1 [ITP]" (Tue, 21 May 2013 18:02:38 +0200):

Hi Andreas,

> thanks for the ping and for working on the tryton modules.

Thanks for answering and now responding additionally to previous PM.
 
> 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.

> 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.
 
> Because I prefer working with VCS rather than mentors I gave your Git
> repository a try:
> 
> $ git stash
> Saved working directory and index state WIP on debian: d30bd8f Moving
> doc/index.rst to appropriate subdirectory doc. HEAD is now at d30bd8f Moving
> doc/index.rst to appropriate subdirectory doc. $ git-buildpackage
> dh clean --with python2
>    dh_testdir
>    debian/rules override_dh_auto_clean
> make[1]: Entering directory
> `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot'
> dh_auto_clean running clean
> 'build/lib.linux-x86_64-2.6' does not exist -- can't clean it
> 'build/bdist.linux-x86_64' does not exist -- can't clean it
> 'build/scripts-2.6' does not exist -- can't clean it
> running clean
> 'build/lib.linux-x86_64-2.7' does not exist -- can't clean it
> 'build/bdist.linux-x86_64' does not exist -- can't clean it
> 'build/scripts-2.7' does not exist -- can't clean it
> rm -rf *.egg-info
> make[1]: Leaving directory
> `/home/tillea/debian-maintain/alioth/tryton/tryton-modules-stock-lot' dh_clean
> gbp:error: You have uncommitted changes in your source tree:
> gbp:error: # On branch debian
> # Changes not staged for commit:
> #   (use "git add/rm <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #
> #       deleted:    trytond_stock_lot.egg-info/PKG-INFO
> #       deleted:    trytond_stock_lot.egg-info/SOURCES.txt
> #       deleted:    trytond_stock_lot.egg-info/dependency_links.txt
> #       deleted:    trytond_stock_lot.egg-info/entry_points.txt
> #       deleted:    trytond_stock_lot.egg-info/not-zip-safe
> #       deleted:    trytond_stock_lot.egg-info/requires.txt
> #       deleted:    trytond_stock_lot.egg-info/top_level.txt
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> 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).
 
> 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.

Thanks so far,
Mathias


[1]
http://packages.debian.org/search?keywords=git-stuff&searchon=names&suite=all&section=all
[2]
http://debian.tryton.org/gitweb?p=packages/tryton-modules-stock-lot.git;a=commit;h=d30bd8f1e4e0901c089c358346fe1b8cd682eb49

-- 

    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

[signature.asc (application/pgp-signature, attachment)]

Message #27 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Mathias Behrle <mathiasb@m9s.biz>

Cc: 706957@bugs.debian.org, debian-med@lists.debian.org, tryton-debian@lists.virtual-things.org

Subject: Re: Bug#706957: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Wed, 22 May 2013 14:15:45 +0200

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

Message #32 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Andreas Tille <andreas@an3as.eu>, 706957@bugs.debian.org

Cc: debian-med@lists.debian.org, tryton-debian@lists.virtual-things.org

Subject: Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Mon, 27 May 2013 14:52:02 +0200

[Message part 1 (text/plain, inline)]

* 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

[signature.asc (application/pgp-signature, attachment)]

Message #37 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Debian Med Project List <debian-med@lists.debian.org>

Cc: 706957@bugs.debian.org, tryton-debian@lists.virtual-things.org

Subject: Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Mon, 27 May 2013 22:23:43 +0200

Hi Mathias,

On Mon, May 27, 2013 at 02:52:02PM +0200, Mathias Behrle wrote:
> >> 
> >> 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.

As I said previously I have sponsored a lot of packages but close to non
from mentors.d.o.  May be that the policy at mentors might be different
from what I'm used to.  My perception of a request for sponsering is
that the sponsee makes a "suggestion" what he thinks is fine for
uploading.  The sponsor is verifying this work and might add remarks or
change requests (or what I'm frequently doing is to do simple changes
myself because that might be simpler than explaining what to do and do
this change in a commit with an extensive commit changelog).  In this
type of workflow the tag in VCS would need to be removed and readded in
case some changes will need to be made.

> 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.

OK, I will not question your workflow if finally the uploaded package
and VCS will match.  I just need to remember this.

> > 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.

Yes, that's why I have given this hint to change it in all modules
because you can save extra renamings of debian/docs for any new module
because you can drop the name.

> > It seems that you are not expecting your sponsor to work in the same VCS as
> > you.
> 
> I don't understand this sentence.

As I described above you are rather relying on mentor.d.o and do not
expect any change directly done by the sponsor.  That's fine for me even
if I consider it less effective.

> >> [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'.

Sorry, sloppy wording.  I really assumed a sloppy / stupid mistake on
your side.

> 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.

If this was really your intention it is different from what I would do
but I will not question this kind of decisions.  From your other mail I
assumed you were expecting more docs of *other* modules coming soon and
thus I was wondering how separating a single file in a single directory
would help in this aspect.

> > 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.

WHen I was talking about Debian infrastructure I was only thinking od
the *development* infrastructure on Alioth.

> 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.

If you want me to ask for registering a pkg-tryton project (or whatever
name you want to suggest - feel free to do so) I'd volunteer to do so
and grant you admin permissions.  However, the announcement[2] is 10
years old and there was no DM status at this time - I can't believe that
you should not be able to register a project that makes perfectly sense.
Why not simply go to

   https://alioth.debian.org/register/

and fill in the form.  WOrst that can be happen is that your request
will be rejected but I have severe doubt that this will happen.

> 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.

As I said:  This is a safe procedure to ensure that you will remain
alone doing this work.  If you want to enjoy the pleasure of teamwork
inside Debian you need to dig through some administrative stuff first.

> 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.

I admit people might have a different sense of humor - but this World
Domination thingy is just a running gag.  I think there is no doubt that
it only can be a joke.

> 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.

I can try my best if the frequence you throw out new packages will not
increase over my capacity.  Currently it is not.

Kind regards and thanks for your preparation of the package

    Andreas.

-- 
http://fam-tille.de

Message #42 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Andreas Tille <andreas@an3as.eu>

Cc: Debian Med Project List <debian-med@lists.debian.org>, 706957@bugs.debian.org, tryton-debian@lists.virtual-things.org

Subject: Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Tue, 28 May 2013 13:28:13 +0200

[Message part 1 (text/plain, inline)]

* Andreas Tille: " Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1
  [ITP]" (Mon, 27 May 2013 22:23:43 +0200):

Hi Andreas,

> As I said previously I have sponsored a lot of packages but close to non
> from mentors.d.o.  May be that the policy at mentors might be different
> from what I'm used to.  My perception of a request for sponsering is
> that the sponsee makes a suggestion what he thinks is fine for
> uploading.  The sponsor is verifying this work and might add remarks or
> change requests (or what I'm frequently doing is to do simple changes
> myself because that might be simpler than explaining what to do and do
> this change in a commit with an extensive commit changelog).  In this
> type of workflow the tag in VCS would need to be removed and readded in
> case some changes will need to be made.

Thanks for clarifying your approach. This was just my attempt to follow official
recommendations (i.e. searching for sponsors after uploading to mentors.d.o.).
Now knowing, that you are willing to give me some support on this side and that
you preferably work from VCS, it will ease things for me, too (saving this
extra upload to mentors).

> > > 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

[...]

> > 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.
> 
> If this was really your intention it is different from what I would do
> but I will not question this kind of decisions.  From your other mail I
> assumed you were expecting more docs of *other* modules coming soon and
> thus I was wondering how separating a single file in a single directory
> would help in this aspect.

Documentation of modules in Tryton always comes with the module. Until now this
generally is doc/index.rst. As the name suggests, this is just the first step.
There are discussions in the project how to improve documentation. AFAIS I
expect this documentation to be in rst format (evtl. sphinx builds). With a
separate doc subdirectory we are prepared in any case.
 
[...]

> > 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.  
> 
> If you want me to ask for registering a pkg-tryton project (or whatever
> name you want to suggest - feel free to do so) I'd volunteer to do so
> and grant you admin permissions.  However, the announcement[2] is 10
> years old and there was no DM status at this time - I can't believe that
> you should not be able to register a project that makes perfectly sense.
> Why not simply go to
> 
>    https://alioth.debian.org/register/
> 
> and fill in the form.  WOrst that can be happen is that your request
> will be rejected but I have severe doubt that this will happen.

I simply went there and got a big fat red "Projektregistrierung ist beschränkt
auf Alioth, nur Administratoren können neue Projekte anlegen."
So, no, I didn't get rejected, it was just not possible to create any request.
 
> > 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.  
> 
> As I said:  This is a safe procedure to ensure that you will remain
> alone doing this work.  If you want to enjoy the pleasure of teamwork
> inside Debian you need to dig through some administrative stuff first.
> 
> > 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.  
> 
> I admit people might have a different sense of humor - but this World
> Domination thingy is just a running gag.  I think there is no doubt that
> it only can be a joke.

The document is meant and linked as *policy*. I think (and support), there is
very little humour in Debian, when it comes to policies as DFSG etc...;).
Humour is just not appropriate in policy documents. 

Whenever I will have a little spare time, I will make another proposal. As long
as this remains unchanged, it is indeed a showstopper for me.

> > 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.  
> 
> I can try my best if the frequence you throw out new packages will not
> increase over my capacity.  Currently it is not.

The recent output (19 modules) is due to stalled development in the last 2
years. Now that I have a working environment I am up-to-date again. Usually
there are ca. 1-3 new modules per release, which makes 2-6 packages a year.

Thanks a lot for considering,
Mathias


-- 

    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

[signature.asc (application/pgp-signature, attachment)]

Message #47 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Mathias Behrle <mathiasb@m9s.biz>

Cc: Debian Med Project List <debian-med@lists.debian.org>, 706957@bugs.debian.org, tryton-debian@lists.virtual-things.org

Subject: Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Wed, 29 May 2013 12:02:38 +0200

Hi Mathias,

On Tue, May 28, 2013 at 01:28:13PM +0200, Mathias Behrle wrote:
> 
> Thanks for clarifying your approach. This was just my attempt to follow official
> recommendations (i.e. searching for sponsors after uploading to mentors.d.o.).
> Now knowing, that you are willing to give me some support on this side and that
> you preferably work from VCS, it will ease things for me, too (saving this
> extra upload to mentors).

From my perspective mentors.d.n is helpful if you are *seeking* a
sponsor.  If you know a sponsor who just volunteered to upload your
packages (be it a single person or a team) it does create some overhead
we could probably save.

> > If you want me to ask for registering a pkg-tryton project (or whatever
> > name you want to suggest - feel free to do so) I'd volunteer to do so
> > and grant you admin permissions.  However, the announcement[2] is 10
> > years old and there was no DM status at this time - I can't believe that
> > you should not be able to register a project that makes perfectly sense.
> > Why not simply go to
> > 
> >    https://alioth.debian.org/register/
> > 
> > and fill in the form.  WOrst that can be happen is that your request
> > will be rejected but I have severe doubt that this will happen.
> 
> I simply went there and got a big fat red "Projektregistrierung ist beschränkt
> auf Alioth, nur Administratoren können neue Projekte anlegen."
> So, no, I didn't get rejected, it was just not possible to create any request.

Uhmm, that comes unexpected to me.  Just tell me if I should register
such a project (once you might agree to the policy).

> > I admit people might have a different sense of humor - but this World
> > Domination thingy is just a running gag.  I think there is no doubt that
> > it only can be a joke.
> 
> The document is meant and linked as *policy*. I think (and support), there is
> very little humour in Debian, when it comes to policies as DFSG etc...;).
> Humour is just not appropriate in policy documents. 

I admit that a policy document should refrain from humor and some better
wording should be found.

> Whenever I will have a little spare time, I will make another proposal. As long
> as this remains unchanged, it is indeed a showstopper for me.

From my perspective technically the wording would be worth a bug report
severity minor - I would not regard minor bugs as showstoppers.  (Just to
explain my point of view, not trying to change your mind.)

> The recent output (19 modules) is due to stalled development in the last 2
> years. Now that I have a working environment I am up-to-date again. Usually
> there are ca. 1-3 new modules per release, which makes 2-6 packages a year.

No problem.

Kind regards

       Andreas.

-- 
http://fam-tille.de

Message #52 received at 706957@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Andreas Tille <andreas@an3as.eu>

Cc: Debian Med Project List <debian-med@lists.debian.org>, 706957@bugs.debian.org, tryton-debian@lists.virtual-things.org

Subject: Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Wed, 29 May 2013 19:36:41 +0200

[Message part 1 (text/plain, inline)]

* Andreas Tille: " Re: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1
  [ITP]" (Wed, 29 May 2013 12:02:38 +0200):

Hi Andreas,

> > > If you want me to ask for registering a pkg-tryton project (or whatever
> > > name you want to suggest - feel free to do so) I'd volunteer to do so
> > > and grant you admin permissions.  However, the announcement[2] is 10
> > > years old and there was no DM status at this time - I can't believe that
> > > you should not be able to register a project that makes perfectly sense.
> > > Why not simply go to
> > > 
> > >    https://alioth.debian.org/register/
> > > 
> > > and fill in the form.  WOrst that can be happen is that your request
> > > will be rejected but I have severe doubt that this will happen.  
> > 
> > I simply went there and got a big fat red "Projektregistrierung ist
> > beschränkt auf Alioth, nur Administratoren können neue Projekte anlegen."
> > So, no, I didn't get rejected, it was just not possible to create any
> > request.  
> 
> Uhmm, that comes unexpected to me.  Just tell me if I should register
> such a project (once you might agree to the policy).

Please be so kind to register pkg-tryton. It will be enough for me to evaluate,
if I will find all I am needing. My username on alioth is mathiasb-guest.
 
> > > I admit people might have a different sense of humor - but this World
> > > Domination thingy is just a running gag.  I think there is no doubt that
> > > it only can be a joke.  
> > 
> > The document is meant and linked as *policy*. I think (and support), there
> > is very little humour in Debian, when it comes to policies as DFSG etc...;).
> > Humour is just not appropriate in policy documents.   
> 
> I admit that a policy document should refrain from humor and some better
> wording should be found.
> 
> > Whenever I will have a little spare time, I will make another proposal. As
> > long as this remains unchanged, it is indeed a showstopper for me.  
> 
> From my perspective technically the wording would be worth a bug report
> severity minor - I would not regard minor bugs as showstoppers.  (Just to
> explain my point of view, not trying to change your mind.)

Filed under [1]. 

BTW: The fusionforge package itself doesn't seem to have at all a public
VCS...;)

Cheers,
Mathias

[1]
http://alioth.debian.org/tracker/index.php?func=detail&aid=314285&group_id=1&atid=200001


-- 

    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

[signature.asc (application/pgp-signature, attachment)]

Message #57 received at 706957-done@bugs.debian.org (full text, mbox, reply):

From: Bart Martens <bartm@quantz.debian.org>

To: 706957-done@bugs.debian.org

Subject: closing RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]

Date: Fri, 31 May 2013 04:23:24 +0000

Package tryton-modules-stock-lot has been removed from mentors.

Send a report that this bug log contains spam.