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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130527202343.gd16...@an3as.eu