[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |