Please write about your intentions before doing changes

Thu Mar 10 02:25:43 UTC 2016

Hi,

Thanks for reverting the work.

2016-03-09 12:59 GMT+00:00 Gianfranco Costamagna
<costamagnagianfranco at yahoo.it>:
>>
>>This behaviur is "pushy", and forces the person who might want to say
>>"no" to enter in a conflict between pointing out errors or not go
>>ahead so quickly and being rude.
>>If you know that you want to do those changes, why not declare your
>>intentions first, when you know that other people are actively working
>>on it?
>
> actually I thought there were issues, because of your mail about build
> failures with the qsort implementation.
> When I tried, and everything worked well, I thought they were fixed, so I
> pushed

Yes, there are issues building it on my side, and I haven't figured
out why yet, because I did basically the same and didn't have time to
work on it since (because of working on other Debian things, fwiw).

What I try to point out is that, since you knew that I was working on
it, it doesn't hurt and it is polite to ask if the person is done yet,
or if have anything pending to commit, or offer your help because you
figured out a way to make it work but /before doing changes difficult
to untangle/, and better avoided like pushing things to VCS that might
cause external conflicts.

The RC bug is not causing FTBFS or other technical problems for the
rest of Debian at the moment (I thought that testing auto-removal
could be a problem, but it didn't kick in yet), the legal front is
covered, the non-free file has been in Debian *for 15 years*, so there
is no need to rush things at this point [*].

And if somebody thinks otherwise, nobody provided feedback in the bug
report to that effect, which is the normal procedure.

[*] In particular, I still had some faint hope that they did a release
soon, or otherwise, since we have to upload a new orig, pack the
current VCS state so the delta with the next release is smaller.  What
does people think?

>>So sorry if this or the following comes across as a bit rude, but I
>>don't have any other alternative by now, other than remain silent.
>
> I can dcut in any minute, (and I already dcutted them as soon as I received
> this email)

That's not the point, the point is that doing changes and asking later
puts people in the uncomfortable situation to stay silent when they
don't really agree (but to avoid all of the hassle), or the pain to
ask to revert work and send these messages, when the whole situation
would have better been avoided.

If for example you want to take responsibility of some of the packages
and be the main maintainer, fine for me.  If I took over most of the
libsdl packages by now is because there were not many people around
during these years.  In fact, I would have liked to not have to spend
time dealing with this bug at all, it's not exactly fun.  But nobody
else replied to the bug, seemed troubled enough in the beginning, and
it was only me who tried to solve it initially.  Nobody else from the
team (and I count you as part of the team by now) did anything
practial on it for weeks, like writing to the bug reports or
communicating with the external parties.

Then Ben in the Cambridge BSP by chance knew the author and contacted
him directly, and I coordinated things back and forth with upstream
before and after, while taking the opportunity and asking them again
to make the new release, copying the list to keep you all up-to-date.
Even if I had the issue working on my side, I would have waited for
them to make a new release with the excuse of that.  (They initially
were going to make a new release, finally decided otherwise (silently)
for some reason, I only learnt in the last few days when asking
again).

So after all of this, is simply not polite to go ahead and do just the
last bit of work remaining when others took the initiative for a month
and who might know more things about the current status of the issue,
without at least asking or declaring your intentions and giving people
enough time to reply -- and specially not setting the clock ticking by
uploading to delayed.

>>Secondly, you clobbered the tag of libsdl1.2 and a version which is
>>already uploaded to unstable:
>
> that was a mistake, for some reasons master didn't contain the changes in -2 upload
> so I had to gbp import-dsc and push again.
>
> not sure what caused the issue, but it was an honest mistake (not even sure why git
> pull didn't fetch the new tag).

The reason was that I had missed to push the last of the change the
changes, possibly because my system crashed that day when I was
uploading things.

When noticing that something was wrong, it is better to raise the flag
about these issues, and I would push my git state before you did your
changes; and the conflicts and modification of tags and commits that
people could have already cloned elsewhere.

>>Thirdly, as I already told you in a private e-mail a few days ago when
>>you asked (so you were fully aware of it), I wanted to wait a bit for
>>the SDL_qsort stuff to use the opportunity to try to get SDL people to
>>do an upstream release, or perhaps the alternative to pack whatever is
>>in current VCS, since we have to have a new "orig" tarball anyway.
>
> the problem was an imminent release, as it was for sdl1.2.

If there is an imminent release of anything that affects SDL packages,
we've not even been notified about it.  If you know about such cases,
please also keep the list in CC so the rest of the team is aware.

And I expect that whatever is the issue, it's not so urgent that needs
to be attended right away, rather than asking and waiting at least for
a few hours or a couple of days for replies.

> I'm fine with the new upstream version, but it isn't there, and upstream developers
> strips the mail list from their replies, so I can't know if progresses are made
> (none if I read everything correctly).

Well, that's basically what I am arguing -- if you don't know the
state of things please ask first rather than doing things and asking
later.

Progress has been made because the license issue is resolved, that's
the best outcome, closing the bug is not a priority IMO (for the
reasons that I already explained).

>>So the legal situation is clear and solving it in this way was hugely
>>benefitial; but uploading a fix for this was not urgent, and possibly
>>not even legally necessary, and fixing other cosmetic-only issues like
>>the VCS thing as you did was not urgen either (that maybe will be
>>fixed in another way by using relative URLs, according to the
>>discussion in -devel that died a bit, but might be revived).  Doing
>>gratiutous uploads is not free for the Debian infrastructure nor for
>>thousands of people who have to download files for a cosmetic issue
>>that they don't even see in the binary package and that are of no
>>importance whatsoever, once the author relicensed the code.
>
> well, the upload was to avoid an useless binNMU, not for cosmetic changes.
> Since the infrastructure will need a full rebuild, I thought speeding up
> the changes was "the best option"

You have a point there, but the rest of the people in the team (or at
least, I) is/was not aware of things that happen within a few hours
and are not relevant to Debian.

That said, having had a binNMU would not be worse in general than
having a full source uploaded.  The full upload is still more taxing
for the infra in general: new .orig (that maybe is not needed if they
release in a few weeks), saving it forever in mirrors and snapshot,
etc.

> I dcutted it, so feel free to upload when necessary.
> I saw the auto transition in place
> https://release.debian.org/transitions/html/auto-directfb.html

That's the last upload of the package in experimental which causes the
auto-directfb transition, as far as I can tell:

[2010-02-14] Accepted directfb 1.4.3-1 (source amd64) (Fathi Boudra)

So it seems that it's a bogus transition, and in any case, I already
said in #816125 that: "So I guess that it's better to drop this
dependency at some point before the freeze.  If this becomes more high
priority for some reason, e.g. because of a pending RM of libdirectfb,
please let us know."

Since nobody asked to make it happen quicker, I assume that there's no
rush; so it's better to make a release only when really needed.

> I already did this before reading the last part. sorry but I was in a hurry, and I
> honestly just tried to help
> (I tried a lot but my flu didn't allow me, so I was happy to help a little bit
> after recovering from it)

It's fine, I hope that I didn't put you off too much with my long
mails and diatribes :-P

I am happy that you want to collaborate and to keep the SDL packages
in good shape.

Just please take into account that it's important to give other people
room to participate and to do things at their own pace, specially when
they took the initiative to resolve the issues and if the open bugs
are not destroying people's disks or something serious.

Not evebody has time to keep an eye an many lists or reply within
hours or the same day; and if you suddently do the job that other
people was planning to do without warning, it tends to put people off
and alienate them from the work that they've been doing for years, or
that they're about to start if they are beginners, etc.

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>