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        

Reply via email to