[Pkg-javascript-devel] node-websocket_1.0.19-2~bpo8+1_amd64.changes REJECTED

[Daniel Pocock]

On 01/10/15 10:27, Rhonda D'Vine wrote:
>    Dear Daniel,
> 
> * Daniel Pocock <daniel at pocock.pro> [2015-09-30 09:38:07 CEST]:
>> On 29/09/15 20:25, Alexander Wirt wrote:
>>> we (ftpmasters) expect you to update packages in bpo regulary during the
>>> whole lifetime of a suite, if you are not able to do that, the package is not
>>> suitable for bpo.
>>
>> Some of the node-* packages change quite frequently and I don't
>> personally have time to test every one of them every time they release
>> and backport them too.
> 
>  "Regularly" doesn't mean every update that hits testing.  In some
> development steps it might make a lot of sense to wait for a later
> upload in a bigger picture, so to say.
> 
>  But if you feel like taking regular care of the packages you backport
> is too much of a trouble I suggest you to please, with sugar on top, NOT
> upload them in the first place.  backports is a service that is meant to
> be used in addition to stable, and thus should be taken care of in a
> useful and sensible way.  That is:
> 
>  -) do not upload packages that aren't in testing (there are exceptions
> to this, but in general those are rather rare than the default and it
> would be convenient to ask beforehand)
> 
>  -) do not upload packages that are neither in testing nor in unstable!
> Sorry, but that is absolutely off.  When you want to have a certain
> middle step of a package uploaded to backports, hold back the unstable
> upload until it transitioned to testing before updating unstable, making
> the version you backport from disappear ...
> 

That was just an oversight with one package, it wasn't something
deliberate.  I had built the package for unstable but forgot to run dput.

>> When I update JSCommunicator, as upstream developer, I test with a set
>> of dependencies, including JsSIP and its dependencies, and everything
>> that I've tested and validated is then uploaded to Debian (both unstable
>> and eventually backports).  This involves testing standalone
>> JSCommunicator, testing DruCall, testing on rtc.debian.org and testing
>> each major browser on Linux and Android.  It is not feasible for me to
>> repeat all of that every time a node-* package changes though.
> 
>  Backports is not your test field.  You are pushing the testing towards
> users of an expected stable system which isn't acceptable, no matter how
> feasible you consider it.
> 

That is not what I said: my statement was qualified "as upstream
developer", which means this was a statement about what I do before an
upstream tag.  So the workflow is:

- upstream testing, as described above
- upstream tag/release
- unstable upload
- finally, backport


>> I've uploaded a 1.0.19-1~bpo8+1 build corresponding to the version in
>> testing, 1.0.19-1, this will work with the other packages that have
>> already been accepted into jessie-backports yesterday.
> 
>  Thanks.  And if you want to stay in the ACL file, whenever you try to
> do something out of the line, speak to us beforehand, don't let us
> stumble upon it like this because that doesn't help us to be convinced
> that you should be able to upload to backports directly without anyone
> else involved.  You can find us in #debian-backports on irc which I know
> you do use at least at times.
> 

Thanks for the feedback

Can you clarify one other thing: if a newer version of node-websocket
propagates from unstable to testing while the node-websocket backport is
in NEW, does that mean it will be rejected again?  Or will it be
accepted into backports because it had been in testing, at least at the
moment I uploaded it?

Regards,

Daniel