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

Re: [Xen-devel] [PATCH v2 0/3] Remove tmem



On Fri, Nov 30, 2018 at 05:09:42PM +0000, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2 0/3] Remove tmem"):
> > It is agreed that tmem can be removed from xen.git. See the thread starting 
> >                                                                             
> >       
> > from <D5E866B2-96F4-4E89-941E-73F578DF2F17@xxxxxxxxxx>.
> 
> Those are notes from some phone call amongst industry stakeholders.
> None of the messages have a Subject line mentioning tmem.  There is no
> explanation of the basis for the decision; just a confirmation from
> the current maintainers that they will ack the removal.
> 
> I think this is not really an appropriate way to carry on!  What if
> there is someone else who wants to step up to maintain this ?  What
> about user communication ?  Going straight from `Supported' to
> `Deleted' seems rather vigorous.

Step up to maintain> I would rather say step up to develop.

The status in MAINTAINERS is wrong. According to SUPPORT.md, it is only
experimental. Our definition of "experimental" is:

   Functional completeness: No
   Functional stability: Here be dragons
   Interface stability: Not stable
   Security supported: No

(https://wiki.xenproject.org/wiki/Xen_Project_Release_Features/Definitions)

This means without putting in significant effort, no-one would be able
to use TMEM. There is no stability guarantee at all for TMEM interface.
Deleting something experimental doesn't seem controversial to me.

I dare say no-one cared because it has got zero development effort in
years since 4.6. Also as you already noticed, no-one can possibly uses
TMEM since the switch to xl (that' even earlier than 4.6).

> 
> 
> In summary I think the claim that "It is agreed" in this cover letter
> is false (or, at least, if it is true, the cover letter provides no
> references to any basis for thinking that it is true).
> 
> If it didn't happen on the mailing list it didn't happen.
> 
> 
> Unfortunately, therefore, on process grounds,
> 
> Nacked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 

Yet the removal of ia64 port wasn't warned or announced on xen-announce,
so I disagree the removal is wrong on process grounds -- since there has
already been a precedence.

If there is a policy file, I would be happy to comply.

> 
> I dare say the decision to remove it now might be right.
> 
> Can we please start this again with a proper explanation of why this
> should be summarily deleted, rather than (say) made unmaintained and
> deprecated for a release ?  Can someone explain why we don't feel the
> need to consult anyone by (say) posting to xen-announce ?  etc.
> 

See above.

> Then we can actually have an on-list discussion where the decision
> would be taken.
> 
> Next time I suggest a good first step would be a patch which deletes
> the M: line from MAINTAINERS and changes the status to Orphan, since
> obviously the current maintainers don't want it.  That patch should be
> uncontroversial.  Also in general, depending who we think might be
> using a feature, a plan which gives some warning to users (by
> deprecating the feature, for example) would often be a good idea.
> 

Can we not invent policy and ask for compliance on the fly?

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.