|
[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 |