If there are technical obstacles to doing what I described, then I
completely understand why you might not want to do it now, or ever.
Maybe you just consider this something to work towards for future
releases; that's fine too.
In any event, we haven't heard from most of the other committers
here, and I'm happy for all of you to work it out however you see
fit.
BTW, I don't think "let me be different just because I want to" is
an EF best practice, but "I unfortunately have to be different for
these technical reasons" is an EF best practice. It's not
the what, it's the why that makes the difference.
When this conversation started, there were no technical reasons for
why you had to do it differently. Now you've presented some
technical reasons. That changes things.
Markus KARG wrote on 12/22/19 10:47 PM:
Bill,
I understand
your reason and appreciate your engagement, but it simply
does not match the JAX-RS reality. Actually I am very fond
of best practices (in the sense of Git best
practices and Maven best practices) but not of EE4J
practices. My estimation is that there actually will
be zero external contributions for JAX-RS 3.0, but it will
impose a lot of action on my side to perform the steps you
proposed (as master is a protected branch, which means
involving EF admins, which implies a delay due to the
holidays, which implies a delay for the project as the
people doing the work are volunteers hence work more
on holidays). The theoretical benefits you predict simply do
not exist for JAX-RS, but always impose additional work to
the people actually doing the work here, so let us
do it how we want it. The latter is a EF best
practice, BTW. ;-)
-Markus
Von:
Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Montag, 23. Dezember 2019 03:19
An: Markus KARG; 'jaxrs developer discussions'
Betreff: Re: AW: AW: AW: [jaxrs-dev] Github
Branches
Apparently I'm
not able to convince you of the benefit of common practices
since every time I suggest that using common practices would
be better you come back with a reason for why it's better to
do things in your own unique way.
And yes, the highly skilled people who are capable of
contributing to multiple projects will also be capable of
adapting to the unique requirements of each project. That
doesn't mean it's better for each project to have unique ways
of doing common operations, it just means it's not fatal.
Markus KARG wrote on 12/22/19 1:00 PM:
If you actually find those people I am
happy to explain them our branch names once they really
produced valueable Content for JAX-RS and could really not
contribute them without!
-Markus
P.S.: I’m doing open source since 20
years in lots of projects. No need to teach me the benefit
of common practices. I was able to easily contribute to all
of them, and to adopt all their particular styles and ways.
People doing a lot of work on one
project are probably capable of working on many projects,
and we should encourage them to apply their skills more
widely.
Markus
KARG wrote on 12/22/19 2:35 AM:
I
understand your argument, but have a slightly different
view. For me the highest priority always have the people
actually doing the most work on each project,
not the ones that work on most projects.
-Markus
Von:
Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Samstag, 21. Dezember 2019 21:29
An: Markus KARG; 'jaxrs developer
discussions'
Betreff: Re: AW: [jaxrs-dev] Github Branches
In my opinion, the simplest
approach for most projects is to do the work for the
currently under development release on the master
branch, and reserve other branches for either work
supporting previous releases (maintenance) or work for
future releases.
There is no one right way to do this, it's all a matter
of opinion, so you can do whatever makes sense and works
for you. As usual, my concern is that we should
preserve as much commonality as possible between
projects in term of how they're managed, to make it
simpler for people to work on multiple projects. What I
described is what I believe to be the most common
approach.
Markus
KARG wrote on 12/21/19 4:38 AM:
Yes that
is possible, it is simply no technical problem, just
time to invest to juggle with the commits.
What do
you try to reach? We certainly can do that, but what
benefit do you expect from it?
-Markus
Von:
Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Samstag, 21. Dezember 2019 03:37
An: jaxrs developer discussions; Markus
KARG
Betreff: Re: [jaxrs-dev] Github Branches
I'm not a git expert, but...
Can you move everything on the master branch to a
"3.1" (or whatever) branch, then move everything on
the EE4J_8 branch to the master branch and use the
master branch for the "current release" (3.0)
development while leaving the other branch for the
"future work" development?
Markus
KARG wrote on 12/20/19 6:58 AM:
(1)
There is no need to actually keep a branch
for that purpose, as you can easily reconstruct it
from the corresponding tag (git
checkout -b <NEW-BRANCH> 2.1.6), as branches are for active
development, while tags are for archived
streams. BTW, note that "-1" means that we MUST NOT
remove that branch even if all other
contributors would be +1 (e. g. due to that simple
git trick), so I'd like to ask if you really mean
"-1" or "0" (i. e. "I would like to keep it, but I
do not stand in the way of the majority").
Thanks.
-Markus
I
would like to keep that branch around in case we
need to do another point release. This should
only mean very minor changes to the spec doc or
javadoc, etc, but if we do need to make a
correction, it will be a lot easier if the branch
is still there.
Committers,
(1) The EE4J PMC
agreed that we may delete the EE4J_8
branch, as Jakarta EE 8 was published
there is no more use of that branch. We
need to take care that everything in that
branch is also found in the master branch.
(2) As the master
branch contains new features, it is
targeting v3.1. As we need to provide a
v3.0 for Jakarta EE 9, I propose we create
a new branch "3.0-SNAPSHOT" for that
purpose (we cannot call it "3.0" because
it would interfer with tag names) as a
branch off master and removing the new
features manually.
If nobody
objects, I will perform these changes in
my X-mas holidays.
Vote, please. :-)
-Markus
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
|
