Hi Yaroslav, On Tue, Mar 28, 2017 at 09:42:41AM -0400, Yaroslav Halchenko wrote: > > - I have already stated many times that if you want to move any of the > core packages under bigger (-med, -science, etc) maintenance -- I > don't mind. But it shouldn't complicate my own work on those > packages. Someone's "mess" might as well be my "consistency" and I > often can't afford spending time figuring out how this are now. And > even worse time "fixing" up packaging (e.g. re-enabling testing, > re-introducing dropped patches, etc) to make it as "messy" as it > was before ;)
It might be interesting to know what part of the "mess" is important to you. For instance it might help to know in advance if you are fine with the gbp layout specified by the packaging policy of the target team. :-) I fully agree that a migration of packaging to a team VCS should not include changing / dropping any patches in the first place. > - so far I still see only myself as the one who took care about pandas > even after I cried out loud for help. So helping instead of > complaining (again) would be more helpful (I started reading > this with an idea that we are talking about tzdata issue, but > apparently we are just making water harder) While I know that you always was cooperating when we started discussing about some issue this discussion used to start only after rdepends of one of the Neurodebian packages were affected by removal from testing warnings. When checking the bug log no response to those RC bugs was logged. This is simply frustrating since this means a time delay of at least 10 days until somebody starts reacting while beeing totally unclear whether some work was done or not. I fully understand if you are swamped with more important things but responding to an RC bug by tagging it help and forwarding the mail to interested parties - in this case Debian Science for instance - would help a lot. May be you consider all this making water harder, but I consider not responding to RC bugs (without an appropriate VAC message) in times of freeze not responsible maintenance. I'd like to repeat here that I would not say so if there would be *any* message crying for help. Since I also personally have no idea about Pandas and this issue I simply took some action and involved tzdata maintainers. This could have happened 10 days ago and this is my main point. (And sorry if I'm to German here. :-P ) > - regarding original tzdata issue -- since we are just expressing > sentiments here -- it would have been cool if maintainers of > core packages would do 'reverse depends testing' before uploading (as > I am trying to do in such cases) so we stop running after a gone train > [see e.g. our ad-hoc messy helper > > https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends > which I usually use successfully when preparing next uploads for > cython, nibabel, etc] Perfectly valid argument, yes. This again shows that you are doing really cool stuff in NeuroDebian which I totally appreciate. Unfortunately this does not make its way where it IMHO belongs like for instance at [email protected]. Well, you wrote some helpful tool and have hidden it nicely out of reach for those people who are obviously in need of this. > - outdated (not pushed) git on github or alioth is all the same -- just > me forgetting to push. "Fixed now" (thanks) - and present on > both github and alioth git://git.debian.org/git/pkg-exppsy/pandas.git Thanks. > Thanks in advance for your help! You are welcome - please ask actively next time. :-) Kind regards Andreas. -- http://fam-tille.de
