Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)
On 25.08.2018 09:11, Raphael Hertzog wrote:
> On Sat, 25 Aug 2018, Hideki Yamane wrote:
>>> So you saved a few kilobytes and made the life harder for others.
>>> IMO it was the wrong decision.
>>
>> It was my mistake, of course, but I DON'T WANT TO MAKE SOMEONE'S LIFE
>> ANY HARDER, IT IS NOT INTENDED. People who made wrong decision should
>> be blamed as fool? If so, please revert debootstrap before I started
>> to commit to it.
>
> Sorry if you found my message a bit rude, I appreciate the work you are
> doing and I even encouraged you to try it out because clearly nobody
> was assuming the task. But honestly there have been way too many uploads
> with regressions, you should spend more time thinking about the
> consequences of each change and you should really add some automated test
> to catch the regressions.
>
> I understand the "release early, release often" mantra, but here we are
> speaking of an important tool that we really to keep working at any time.
In this case automated regression testing would only have found it if
derivatives would've been tested for.
Unfortunately while I tried to anticipate the fallout here in [1] I also
did not get an answer to my question. I guess I would've needed to be
more clear in wanting a debdiff between the two udebs because that's
usually how things are reviewed in Debian land - and just reviewing
changes to the source does not convey the same information.
At work we have code review tooling that shows you the change in data
(sadly not in .debs either). I wonder if something similar of "build
package at origin and at target and diff the two" exists.
But that would still require some culture of timely reviews and the
requester waiting until that review is done. Right now merge requests
for d-i won't really work for contributors who already have commit
access because there are two few people who are actually willing to
review - and others actively unassign themselves. I understand why that
is, but at the same time we then need to attenuate our feedback.
Anticipating the consequences requires a certain familiarity that new
contributors don't have. Still automatic pre-release testing is
something very useful.
Kind regards
Philipp Kern
[1]
https://salsa.debian.org/installer-team/debootstrap/merge_requests/16#note_35325
Reply to: