Bug#706957: [Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
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
Reply to: