| Re: [technology-pmc] [microprofile-wg] Release Approval forMicroProfile GraphQL 1.1 |
[Phillip] 1.0.4 release - need to check with WG to determine process
Andy consulted Emily - we will need to go through the “extended” release process for micro releases (i.e. 1.0.3 -> 1.0.4), but not for milestone or RC releases (i.e. 1.1.0-M1 or 1.1.0-RC1).
Emily is working with Eclipse Foundation to avoid the extended process for micro releases.
MeHi Emily.
We (Quarkus) need a patch on MP OpenAPI.
The older 1.x branch
We need this (still to be backported) https://github.com/eclipse/microprofile-open-api/pull/470/files
Is that ok to do ?
Emily Jiang
it is ok. I think it is a bug fix. I am thinking to get all spec to do a RC1 release to store the tag
you might just do a service releaseMeThanks !
I looked at the gpg pluging. What you have should work. It might be a glitch.
All good! helidon 2.3.0-SNAPSHOT mp-graphql working fine with RC1. Thanks
Follow the instruction on the Specification Review issue to send an email to PMC for PMC approval. You normally can get an approval with 1-2 days. If you are not already a member of the technology-pmc and microprofile-wg mailing lists, sign up to avoid having your emails bounce.
Follow the instruction on the Specification Review issue to send an email to EMO for EMO approval. After an email is sent, a bug zilla will be created to track the release. You need to add the bugzilla link to the Specification Review issue. EMO approval normally takes longer time. It will asks for IP logs. If you need to generate IP Logs, just log onto the same site where you create Component Release Record and then click `Generate IP Log` on the right hand side. For MicroProfile specifications, if a number of specs are released at the same time, the first spec that goes into EMO process will have the IP log generated and the IP log will cover the rest specifications, because all of the MicroProfile specs share one single project. After IP log is approved, EMO will wait for MicroProfile WG ballot to conclude successfully (see the next bulletin list) before a final review is approved.
A service release (1.0.4 in your case) can not be performed until a corresponding major or minor release has been performed under the Eclipse Foundation Specification Process
Sorry! That's just part of the Specification Process which we all agreed to...
Phillip: No problem, so I can then do a 1.2 using the new process ? Basically doing exactly what I have done but change the version to 1.2. would that work?
Kevin: Yes. That would work. Thanks!
You need to create a release note to document the changes between 1.1 and 1.0, so that the end users or implementors are clear on what are the differences between the releases.
From your statement above I sense that you are refusing to work with the community. I'd like to say that this is not something we will accept as the PMC.
First of all, I am so sad and shocked with the response. I have been trying to help with the release since the beginning. I was even trying to help you with the gpg issue when you reached out even though it was late night for me. I promised you (when you reached out to me) to help with defining a lightweight version of service release. Wayne knows as I talked to him in the last few weeks on this. In my email on this thread, I said it was me as I signed my name and spoke as a MPWG rep as well. It was my comments. I put my comments there to share some best practices that we have done in our current releases for our end users' and implementors' benefit. It is like a PR review. You can argue and explain. Then the reviewer says " fair enough, I am not going to hold off your PR". Do you think it is dictating or ordering? By the way, I feel the tone in the email response was overreacting and it hurts people's feelings (not only me but also some of the community members). In the open source community, everyone has a right to share their opinion when she/he sees something needs to be improved. I don't see the connection between my comments and respect or trust.EmilyOn Thu, Mar 11, 2021 at 9:47 PM Phillip Kruger <phillip.kruger@xxxxxxxxx> wrote:So let me further explain my concern.Given the issue with the release notes as described above.Assumption 1. Emily is speaking on behalf of the MicroProfile Steering Committee to the MicroProfile GraphQL Workgroup.No with this assumption, I would also assume that the MicroProfile Steering Committee has had a discussion and decided that they will allow the release request to continue as it (without release notes), and asked Emily to reply on their behalf.(I assume that because as with the release, and the argument that this is a service release, we, the MicroProfile GraphQL Workgroup, had that discussion and I am representing the graphql workgroup in this release) see our meeting minutes where this has been discussed multiple times (https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit?usp=sharing)Here the reply then from MicroProfile Steering Committee: Since this is a special case (debating between minor and service release), I (assume MicroProfile Steering Committee here) am not going to hold you (assume MicroProfile GraphQL here) off the current release. Maybe when you perform a follow up release, you can add the release note then?This is how I see this reply: The MicroProfile Steering Committee are sitting on their throne, allowing the peasants to live another day. But just make sure this does not happen again.What the reply from MicroProfile Steering Committee could have looked like: First of all, thank you for the work that you, the MicroProfile GraphQL workgroup, have put into this release. As you know, we can not do a service release for your current branch as explained to you by Kevin, and the process for minor release requires release notes. This is an exceptional case and we are going to proceed with the ballot as is, because release notes would not make sense as this is technically a service release. Going forward, when doing a minor release, remember that our process needs release notes as part of the specification.This is how I would see this reply: The MicroProfile Steering Committee is here to help the Specification Workgroups by moving obstacles out of the way.Assumption 2. Emily is speaking in some other capacity, maybe as a fellow MicroProfiler, to me, Phillip.Now in this case, I would point out that it's not me arguing the case, it's the MicroProfile GraphQL Workgroup, that I merely represent. The reply then to Emily (or any other MicroProfiler) would be to please come join the workgroup and let's discuss there. Emily, or any other MicroProfiler, can not, and should not "allow us or me to continue". MicroProfiler are welcome to debate with us, or me, the usefulness of release notes that really means nothing to no-one in the future, but to "allow us or me to continue" indicating a boss : employee relationship. That, as you know, is not the case. I do not work for Emily. We both work on MicroProfile. We need to communicate better and respect each other._______________________________________________On Thu, Mar 11, 2021 at 11:14 PM Phillip Kruger <phillip.kruger@xxxxxxxxx> wrote:Hi Wayne. Thanks for your reply.So the issue is that it doesn't matter whether or not it is a service release: the process requires a review for all releases. I believe that the previous paragraph addresses this. However, the MicroProfile GraphQL specification has not yet engaged in a release review since the adoption of the EFSP and so the legal magic that manages the intellectual property grants has not occurred at all yet. I believe that you've sorted this out with the MicroProfile working group on their mailing list.This is actually the issue. We are not trying to *not* have a review. The initial request was to review and start a ballot on a service release, and after Keven explained we can not (ever) do a service release on the current branch, we agreed to do a minor release. In both cases, this would have gone through a review and ballot. The question is should this release (that is technically a service release) contain release notes for this release. We argue no, because it just would not make sense. Emily, in a still unknown capacity, argued that it should. This happened before that ballot had started, as a reply on the ballot request, with a conclusion that Emily, either as a representative of the MicroProfile Steering Committee, or in some other capacity, will *allow* the release without this release notes. My concern is not with the process. It is with the way that we treat each other.There are many people that are making industrial quality MicroProfile specifications successful.On Thu, Mar 11, 2021 at 10:19 PM EMO EMO <emo@xxxxxxxxxxxxxxxxxxxxxx> wrote:_______________________________________________The MicroProfile working group was formed late last year to provide oversight for the specifications developed by the MicroProfile project. The MicroProfile project has been adopted by the MicroProfile working group as a specification project. Per the MicroProfile Working Group charter, the Steering Committee performs the duties of a Specification Committee as defined by the Eclipse Foundation Specification Process (EFSP). There is no requirement that a top level project be dedicated specifically to a working group so the MicroProfile project continues to operate under the guidance of the Eclipse Technology PMC.The EFSP exists to manage how intellectual property rights flow through a specification. Without this management of intellectual property rights, there is a very real risk legal risk to specification implementers.Unfortunately, there are few ways in which specification projects just aren't the same as software projects and the EFSP was drafted to address those differences. The short version is that MicroProfile has hit the big time and--as a provider of specifications--needs to take the management of intellectual property grants seriously. Unfortunately, you do need to care about the process.As drafted, the EFSP requires that specification projects engage in a release review (with successful ballot approval from the specification committee) for all releases. This includes service releases. The basic reasoning at the time the EFSP was drafted was that even very minor changes like the addition of a comma could change meaning in a way that causes a specification to implicate additional intellectual property and the only way to be sure was to engage in the review process so that the various specification committee members could have an opportunity for their legal teams to have some say in the matter.We've come to realize that this was a mistake. Or at least more heavily handed than is necessary. The specification process is still relatively new and as we roll it out to additional working groups and otherwise use it in anger, we're finding that it needs to be adjusted. So we have started the ball rolling to change the specification process and exclude service releases from the need for review, ballot, or any specific ceremony, so long as the condition is met that the service release does not implicate any additional intellectual property. This will take some effort as there are legal implications, but I am hopeful that we'll have it sorted it out in time to ask the board for approval in their late April meeting. The focal point for this effort is here.Given that we've decided that the requirement for a release review with a specification committee ballots is overkill for a service release that implicates no additional intellectual property, the EMO will relax this requirement while we sort it out.So the issue is that it doesn't matter whether or not it is a service release: the process requires a review for all releases. I believe that the previous paragraph addresses this. However, the MicroProfile GraphQL specification has not yet engaged in a release review since the adoption of the EFSP and so the legal magic that manages the intellectual property grants has not occurred at all yet. I believe that you've sorted this out with the MicroProfile working group on their mailing list.I am grateful that Emily has taken the time to understand the specification process and has taken on the responsibility to help her project committer colleagues navigate it. As a member of the MicroProfile Steering Committee, Emily shares voting responsibility, but also has a voice on the committee whose successful ballot as part of release review is required to ratify specifications.I am hopeful my explanations here have helped you understand why we have the requirements that we do and appreciate Emily's critical role in making industrial quality MicroProfile specifications successful.WayneOn Wed, Mar 10, 2021 at 1:58 PM Werner Keil <werner.keil@xxxxxxx> wrote:_______________________________________________Philip,
Glad, you are willing to do a service release of MicroProfile GraphQL even without functional changes, that is something the MP JWT project was unwilling to do despite several flaws and issues in the latest spec, but it Chose to wait till Maybe upgrading to Jakarta EE 9 or 10 before they fix them. Happy to see, at least one or the other project makes an exception from that.
Not sure, if Emily has time and capacity for yet another „hat“ like actively participating in your spec? ;-)
The Steering Committee doesn’t vote on your spec, that is done by the Technology PMC since MicroProfile does not have any top Level project of its own or a dedicated Specification Committee like Jakarta EE.
While IBM certainly has a couple of People on the Technology PMC (https://projects.eclipse.org/projects/technology/who) I don’t see Emily there either, so she’s only subscribed to the list like myself in this case (also because I am committer and Project lead of at least two other Technology Projects)
Cheers,
Werner
Von: Phillip Kruger
Gesendet: Mittwoch, 10. März 2021 18:39
An: Microprofile WG discussions
Cc: Technology PMC
Betreff: Re: [technology-pmc] [microprofile-wg] Release Approval forMicroProfile GraphQL 1.1
> I am not going to hold you off the current release
Are you (Emily) the gatekeeper we need to pass ? Or are you talking on behalf of the Steering Committee ?
Are `you` in your sentence above me (Phillip) ? As I am speaking on behalf of the MicroProfile GraphQL Workgroup.
This is not a debate between minor and service release. This is an issue of trust. Now, I get that you do not trust me, and I am fine with that, but, like I said, I am speaking on behalf of the MicroProfile GraphQL Workgroup, of which IBM has
a representation (Andy) that agrees that this is (technically) a service release. So you need to check in with your representation. If you do not trust your own representation, then join the MicroProfile GraphQL Workgroup yourself and take part.
We (MicroProfile GraphQL Workgroup) have already concluded that this is a service release. You either trust, or have a representation that you trust, or you take part yourself.
Now, I am sure you can agree that taking part yourself in all workgroups is just not a scalable solution for the Steering Committee, and that is why you should, as a vendor, have some representation on the Spec Workgroup that you trust.
If a Spec Workgroup have to transfer the context of months worth of discussion and work to the Steering Committee on every release every time, we (MicroProfile) will halt to a standstill. That is not a scalable solution. The Steering Committee should not be the police. The Steering Committee should help to enable the induvidual workgroup to perform optimally and trust them.
> Maybe when you perform a follow up release, you can add the release note then?
Me (Phillip) will not be doing any more releases. But you can make sure your representation knows about your requirement.
Cheers
On Wed, Mar 10, 2021 at 5:31 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
Since this is a special case (debating between minor and service release), I am not going to hold you off the current release. Maybe when you perform a follow up release, you can add the release note then?
Thanks
Emily
On Wed, Mar 10, 2021 at 1:54 PM Phillip Kruger <phillip.kruger@xxxxxxxxx> wrote:
On Wed, Mar 10, 2021 at 2:54 PM Phillip Kruger <phillip.kruger@xxxxxxxxx> wrote:
If you want to have context, then either check in with your representation in the workgroup (in the case of OpenAPI there is none for any vendor but Red Hat) or read the comments in the issue provided: https://github.com/eclipse/microprofile-graphql/issues/212
This is technically a service release.
On Wed, Mar 10, 2021 at 1:40 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
Hi Phillip,
Thanks for sharing your thoughts! From what the project plan on GraphQL 1.2, it states "Other changes include a fix in the TCK to allow any order of properties when describing a default value in the schema and a fix in the API to allow `@NonNull` on parameter". It indicates it is not just a TCK. It also allows `@NotNull` on parameters. Even if it is just a TCK fix, it is useful just to say it is to fix a TCK bug and bring the project aligning with MPSP, so that in the future you understand why you did a minor release instead of a service release.
The reason for adding this in the spec is that when end users or implementors are trying to find out what is included in GraphQL 1.2, they can just look at the spec instead of trolling through some other places to find out. In MicroProfile, the feedback we consistently got is to improve the documentation and gather information into one place. I understand taking shortcuts seems running faster. However, this might confuse end users. When you do another release of GraphQL 1.3 or 2.0, in the spec, there is no mention that GraphQL 1.2 was released at all.
Once you have done a successful release under the EFSP process, the future releases are much easier. Besides, we are continuing our pursuing lightweight service release process.
By the way, I disagree this has something to do with "People over Process". I think it is useful for end users and implementators.
Hope this helps!
Thanks
Emily
On Wed, Mar 10, 2021 at 10:26 AM Phillip Kruger <phillip.kruger@xxxxxxxxx> wrote:
This is really a service release, with no impact on the user or implementors (both implementations has already tested against this)
As you know, due to the Eclipse process, we could not do a service release, so, as agreed we bumped the version to a 1.1 even if there is no new functionality, no breaking changes etc.
I think we (MicroProfile) need to be careful that our process is not busy killing any progress and inovation. We have already lost a lot of momentum in most specs due to the "waiting for the workgroup" and now the process is making it difficult to get going again.
I want to point everyone to the agile manifesto, specifically people over process.
I have worked in enough businesses where too rigid process enforment killed any inovation and progress and I think we need to be careful in how we proceed.
I understand that process is needed, but this is an exceptional case where we need a small fix, and the current effort is just not worth it, and anyone that cared to take part in this workgroup (and the same argument for the OpenAPI workgroup) would know that.
So, back to what is needed to get this out. Are you saying that I need to add a part in the actual spec document, that states that we previously had an error in our TCK that is now fixed ? And that we forgot to make a annotation available on a parameter, and that is now fixed ? That seems unnecessary.
Let me know.
On Tue, Mar 9, 2021 at 11:35 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
You need to create a release note to document the changes between 1.1 and 1.0, so that the end users or implementors are clear on what are the differences between the releases. You can find examples from other spec changes, e.g. MicroProfile Config 2.0 release note.
Thanks
Emily
On Tue, Mar 9, 2021 at 8:40 PM Phillip Kruger <phillip.kruger@xxxxxxxxx> wrote:
We have staged MicroProfile GraphQL 1.1 final release with this release plan and created this issue listing the various release artifacts. Please can you approve this release?
Thanks
Phillip on behalf of MicroProfile GraphQL
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/microprofile-wg
--Thanks
Emily_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/technology-pmc_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/technology-pmc
--Thanks
Emily_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/technology-pmc_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/microprofile-wg
--Thanks
Emily_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/microprofile-wg
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/technology-pmc
--The Eclipse Management Organization | Eclipse Foundation
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/technology-pmc
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/technology-pmc
--_______________________________________________Thanks
Emily
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/technology-pmc