[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is removing smell from packages OK? (Was: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883")



Quoting Philip Hands (2022-02-25 10:09:29)
> Andreas Tille <andreas@an3as.eu> writes:
> 
> > Am Thu, Feb 24, 2022 at 11:58:12PM +0900 schrieb Osamu Aoki:
> >> > This is probably very academic now since Andreas Tille has 
> >> > uploaded a fixed xdelta3 package today.
> >> 
> >> Now that I know that the new xdelta3 is uploaded, I am OK.  
> >
> > BTW, I stumbled upon xdelta3 since also a package of mine received 
> > this autoremoval warning.  Usually I try to take action on it.
> >
> > I had to decide between a "proper NMU" and an "upload that fits the 
> > packaging standards I apply to what I upload" (which includes 
> > maintained on Salsa, usage of dh, DEP5 copyright ... basically 
> > removing the smell from the package).  I decided for the latter but 
> > at the same time I was aware that I violated the rules we gave given 
> > each other.
> 
> FWIW I also started work on xdelta3 when I saw the removal warning for 
> installation-guide, but when I got to the point of creating a repo on 
> salsa you'd beaten me to it by about an hour :-)
> 
> I'd gone for a slightly lighter-touch approach, in that I'd only done 
> about half of what you'd done, but having looked, you had clearly done 
> a much more thorough job, and I had nothing to add.
> 
> I had replaced CDBS with dh simply because CDBS was FTBFS, and was 
> only a minimal 2-includes rules file, so it wasn't really contributing 
> anything that would justify working out how to fix it.
> 
> > Given the fact that there was a nearly 4 year old patch (#895957) 
> > made me feel that I'm not alone with this but on the other hand the 
> > creator of the patch (thanks Jeremy for doing at least half of the 
> > necessary work) hesitated to upload his work.  This brings up again 
> > the discussion about how much changes are allowed to simply remove 
> > smell from packages is accepted.
> 
> Given that the bug that's threatening its removal (#965883) has been 
> ignored for almost 2 years, and is about the fact that it had a dh 
> compat version of 5, which is completely trivial to fix, so the 
> package certainly has the look of having been abandoned, which is why 
> I think it's fine to do what you did, and I think you did a very good 
> job of it.

I also think it was fine to do a 0-day NMU here, concretely.

I do not think it was fine to refactor packaging _because_ of code 
smell, however:

a) I do *not* think it is generally fine to refactor a package when 
doing an NMU, even if "smelly" (i.e. packaging style is unusual).  [As I 
now understand it, this is how previous email from Andread should be 
understood.]

b) I also do not think that code smell is a reason for fast-tracking.  
[I understand now that this is *not* how previous email from Andreas 
should be understood.]

I agree that multiple factors might be involved when doing an NMU, and 
other factors may weigh higher than preserving current packaging style. 
Code smell is one such factor, but I oppose to code smell on its own 
being a reason to refactor an NMU (or to fast-track an NMU, which seems 
not the point Andreas wanted to make, only my previous misreading).

In other words, I think what was done here was a "proper NMU" (just not 
a simple one).


Thanks for the NMU, Andreas,


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: