Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jaxrs-dev] JAX-RS Kick-Off: Commiters, Start Your Engines!

Gentlemen,

 

as our spec lead did not react upon my private mails, and as no progress had been made by anybody in the JAX-RS project, I informed the PMC that hereby kick-off work on this project.

 

It looks as if the code is here, no more branches will come, and all issues are here, too. Hence, we do not have to wait for anything else. As Oracle has to do other stuff (as in the past years), we have to chime in!

 

The PMC's first goal is to push out an EF-provided Java EE 8 compatible release of JAX-RS API 2.1. So here we go!

 

As my first act (and please don't shitstorm me for doing so) was to cleanup the mess in the master branch: It is a clean starting point now as it only contains two commits -- the empty one of the EF webmaster, and the first one when Oracle pushed their last "own" commit.

 

My proposal for the next steps (if nobody else has a better idea, then please speak up):

 

(1) Short round of introductions: Please, every commiter briefly introduce yourself (I will start a separate thread for thead). Who are you, who pays your work on JAX-RS API, what is your aim in participating to this project.

 

(2) Add issues for JAX-RS 2.1 (= Java EE 8) and JAX-RS 2.1.1 (= MR 1) to the tracker if you have some on stack.

 

(3) Assign "your" issue to your, then branch from master and implement "your" issue.

 

(4) While apparently we all have full write access to master, we should apply Four-Eyes-Principle. Hence, I would propose that nobody pushes against master directly, but we open PRs against master and nobody merges his own PRs. So at least one other committer has to be convinced of the usefulness. Or better two or three, as this is a spec project. ;-)

 

(5) If somebody wants new features or deprecate features, due to the PMC-enforced compatibility to Java EE 8, we should send _those_ PRs not against master, but against a new branch. I would say, "3" is a good branch name, but maybe you have a better idea?

 

(6) ASAP we should vote for a new project lead, as he is completely unresponsive for weeks, and nobody else has administrative rights on GitHub.

 

Again, please don't judge this as an act of piracy, but apparently Oracle has not time for this, and I want to get work done since weeks. I would be glad if we could get some life into this project, and hopefully you all will chime in!

 

-Markus

 


Back to the top