On Tue, 28 Mar 2017, Andreas Tille 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. itemize "mess"y aspects (I was not the one to provide this qualification) and I will let you know. Could as well happen that the answer will be "none" > 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. :-) yes -- it is fine. I use gbp as well > I fully agree that a migration of packaging to a team VCS should not > include changing / dropping any patches in the first place. good > > - 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. would be great indeed > 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. yeah, agree. In the long run, I may indeed need to shorten the list of packages I maintain. I am NOT on VAC virtually ever but indeed seems getting short of time to provide adequate oversight at times. Again -- actual help is welcome. > 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 ) it is ok -- I like Germans in general ;-) > > - 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 debian...@lists.debian.org. Well, you wrote some helpful > tool and have hidden it nicely out of reach for those people who are > obviously in need of this. apt-get install neurodebian-dev I have pointed to it multiple times. I think there is a (possibly better) alternative now $> apt-cache show ratt Package: ratt ... Description-en: Rebuild All The Things! ratt (“Rebuild All The Things!”) operates on a Debian .changes file of a just-built package, identifies all reverse-build-dependencies and rebuilds them with the .debs from the .changes file. . The intended use-case is, for example, to package a new snapshot of a Go library and verify that the new version does not break any other Go libraries/binaries. but I haven't tried it so YMMV. You can help leading the initiative to promote it/them to debian-qa@ or -devel@ or any other appropriate in your opinion channel. I would really appreciate! > > - 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. :-) Hereby I am officially announcing (again) what is already known (I thought that RC bugsquashing is a normal procedure and not requiring special invitation, but if it helps, here you go) Everyone is welcome to address RC bugs (unless tagged as pending) in packages I maintain, especially during the freeze. NMUs etc are more than welcome. Your help will be very much appreciated! If I don't react to RC bug, it might be that I have missed it. If you want to tackle it, and really need my official blessing to get it fixed by you -- email me and I will bless you officially for that endeavor. Adding "bless me to fix RC bug" in the subject line would help to attract my attention. I do not think I can add more to this line of the discussion ATM. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
