Project Manager / Release Engineer Role to reduce process burden on MP developers

[Andy McCright]

Hi All,

Releasing things in MPWG is hard. There have been some "strongly worded" letters in that department lately, and as someone who went through the process for MP Rest Client 2.0, I sympathize.  

I don't think I can adequately sum up the difficulties in performing a release, but it certainly includes the "paperwork", the compatible implementation records, navigating a lot of documentation and voting forums, and just general knowledge of the system.

As a technical person who (though perhaps lacking in ability) likes the more creative/innovative aspects of MicroProfile and thoroughly despises the paperwork aspects, I would like to propose that we consider hiring (or maybe one of the member organizations could sponsor) someone with a passion and skillset for project management / release engineering to handle these hurdles. If possible, that person would attend the individual project hangouts and would (1) perform the paperwork process and (2) guide the project teams to avoid pitfalls in the process.  I think that would ease some of the process burden on the developers - and allow them time/space to add user value to the MP projects.

Thanks,

Andy

[Edwin Derks]

Hi Andy,

Thanks for bringing this up. It sounds valid and important enough to have a discussion about. We can of course continue the discussion in this thread, but we can also add it to the agenda of the Hangout meetings to have a discussion there. Does that work for you?

Edwin

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ca473d4b-587f-4bd2-998e-2c0ef68a6156n%40googlegroups.com.

[Scott Stark]

This certainly relates to the lack of an operations guide that details the steps to follow. I will put one together since it was brought up in the context of my other message about release artifact requirements.

I can't see how the delta of work for the additional steps needed relative to what was done before the MPSP could amount to even a week of dev hours, so it is hard to see how a resource could be brought on to offload the tasks. 

[Andy McCright]

Edwin - sure, I'd be happy to bring this up on the next community hangout.  I'll add an agenda item.

Scott - ultimately I think you're probably right, that we won't be able to afford a dedicated resource. Still, the process was long and painful for me (and at least a few others that I have spoken with).  If you have had better luck, would you be willing to help other projects with their releases?  If you took over release responsibilities for Rest Client and GraphQL, I'd definitely buy you a beer the next time we're at the same conference.  ;-)

Thanks!

[Emily Jiang]

There is a dedicated wiki to document the steps. Personally, I also think the CCR requirement is quite a heavy task. We started the conversation on the other thread regarding CCR. I really think the requirements for CCR can be further reduced as these rules were invented by us and they are not required by EF. If producing CCR is a huge task, we need to be worried.

Thanks

Emily

[Scott Stark]

Next time someone goes through a release, track the time spent on the various steps. We should be optimizing so that every minute spent is worth the trouble.

The CCR and TCK requirements are not absolute requirements of a specification process under the EFSP in terms of IP capture and being able to distribute rights to compatible implementations. That was the case under the JCP. I would be fine with greatly reducing the requirements for a CCR to allow for snapshot builds of CIs that only exist in the staging repo, and only for the duration of the vote.

This also addresses a concern that was recently voted in in Jakarta EE where the requirement for how the CI used to ratify a specification is identified. If that CI was really just an intermediate step to some future product, and not something that needed to be maintained, it would give less weight to the first CI to pass. Unless a final release of a supported product comes out and files a CCR, the spec is not really worth having. However, that should not be a requirement for ratifying and releasing a spec.

[Emily Jiang]

+1 Scott! This is what I tried to advocate for as well. I think we made trouble for ourselves for requiring a beta/GA release for CCR. This is especially troublesome for choosing runtimes (e.g. Open Liberty, Payara, Wildfly, etc) to do CCR. I don't think requiring the runtimes to do a beta release just to satisfy our CCR is the right call. I also like the idea of keeping the release for the duration of CCRs is sufficient. If we settle CCR is for releasing specs and nothing else, we can make CCR much simplier to manage.

Thanks

Emily