Quoting Pirate Praveen (2019-08-15 08:18:01)
> 
> 
> On 2019, ഓഗസ്റ്റ് 14 11:05:03 PM IST, Jonas Smedegaard 
> <jo...@jones.dk <mailto:jo...@jones.dk>> wrote:
> > Quoting Pirate Praveen (2019-08-14 19:08:47)
> >>  Hi ruby and js teams,
> >> 
> >>  task_list project [1] provides both ruby and nodejs code from the
> > same
> >>  repo. Currently only ruby-task-list binary package is created. I
> > added
> >>  a new binary package node-deckar01-task-list for the nodejs code, 
> >> but
> > 
> >>  it was rejected by ftp masters [2].
> > 
> > Did you quote ftpmaster in full in that referenced post written by 
> > you?
> 
> Yes.
> 
> > 
> >>  They think we should not add a new binary package for this case 
> >>  and instead should use a Provides field and a single binary 
> >>  package.
> > 
> > Do they?  In what you reference above I only see Ftpmaster saying 
> > "We've talked about this." which can frankly mean a lot of different 
> > things.
> 
> I agree, that is why I asked them to state their position clearly, 
> first on irc, then on BTS. I even shared the BTS link on irc while we 
> were discussing.
> 
> This was before the second rejection. On second rejection, I again 
> asked them to reply on the bug. Do you have any other suggestion to 
> get an official statement from them?

Can you quote the conversation on irc?

Can you quote the first rejection?

Basically, can you quote whatever it is that ftpmaster refers to as the 
"talk" you've already had with them?


> >>  I don't agree with their decision, but the only option I have to 
> >>  challenege it is a GR.
> > 
> > You mean you have already tried the route of going to the technical 
> > committee, and asking for the opinion of the DPL?  Or am I missing 
> > something making those options a no-go?
> 
> FTP masters made it clear that CTTE cannot override a delegate on irc. 
> I have seen confirmation from CTTE members for the same on another 
> issue about browserified JavaScript and dfsg. [1]
> 
> "You seem to be asking us to decide on DFSG compliance (in place of 
> the FTP Team); but it's not at all clear that the constitution enables 
> the TC to override Delegates or decisions made by delegates (see 
> §6.1)."
> 
> Same for DPL, a DPL cannot override a delegate.

My suggestion is not to try override a decision.

What you do here on this mailinglist is, I believe, to try discuss what 
to do about a decision made by ftpmaster.

My suggestion is try discuss that with the DPL ot the Tech-CTTE.

...unless it is clear to you what to do about the decision from 
ftpmaster?  As you have not presented us other details than your _own_ 
reflections I cannot really have any sensible opinion about their 
decision.


> > Whichever options available, I think it would be helpful with the 
> > opinions of stakeholders more clearly laid out - i.e. more than 
> > quoting
> > 
> > ftpmasters for saying "We've talked about this." and you taking 
> > responsibility for explaining what that's supposed to mean.
> > 
> > 
> I agree, it is not a situation I like to be in as well. I asked 
> multiple times using multiple forums (email, irc and BTS) for ftp 
> master to officially state their policy, but none worked. With ftp 
> master refusing to even provide a statement or rationale for the 
> decision, it seems GR is the only option. I could still ask CTTE for 
> their opinion as it can help in case of a GR. But I wanted to first 
> check with the affected teams what they think before going to CTTE or 
> GR.

There is a difference between ftpmaster making a decision, talking about 
a decision, and providing a policy.

I can certainly understand how ftpmaster is _very_ reluctant to provide 
policies - i.e. expectations for future decisions.

Regardless of my opinion, if you want to discuss ftpmaster _policies_ 
with this team or any other body I again recommend to present not only 
your side of the story but (verbatim!) ftpmaster side of the story as 
well!


 - 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

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Reply via email to