Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [technology-pmc] [microprofile-wg] Release Approval for MicroProfile 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

Back to the top