[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] [External] : Re: Migrating repos to https://github.com/jakartaee
|
As per note https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2101#note_1035606:
"
@smarlowsxi
please provide a +1 as the project lead and let us know, when it's
a good time to do this move.
Please be aware that
committers and contributors will have to adjust their local git
environment to point to the new URL. Also CI jobs/pipelines will
need to be adjusted.
"
I didn't know that CI
jobs/pipelines will need to be adjusted. Has anyone where gone
through that before? We have many CI jobs/pipelines:
- Jakarta EE 8 CI jobs are in the root of
https://ci.eclipse.org/jakartaee-tck. I don't expect that we
would do any service releases for EE 8 but if we did, the
jobs/pipelines could be adjusted at that time.
- Jakarta EE 9.1 CI jobs are in
https://ci.eclipse.org/jakartaee-tck/job/9.1/. I don't expect
that we would do any service releases for EE 9.1 but if we did,
the jobs/pipelines could be adjusted at that time.
- Jakarta EE 10 CI jobs are in
https://ci.eclipse.org/jakartaee-tck/job/10/. We already are
planning to do a service release for the Platform TCK + Servlet
TCK. We are in progress on a Core Profile TCK service release
as well. We will need to update the EFTL Platform TCK jobs +
https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-coreprofile-tck-build
to reference the new git repo.
We will share instructions for updating our local repo + forks.
Lets wait a few days to before commenting our +1
that it is a good time for the github repo migration to start.
That will give us time to think about the CI changes and complete
the pending service releases. If anyone knows of other reasons to
delay the migration, please do speak up.
Scott
On 10/17/22 3:58 AM, Gurunandan Rao
wrote:
regards,
Guru
Hello All,
If there are no new suggestions, will start on
migration of the repo, since we have closed Jakarta
EE 10.
regards,
Guru
This might be a time to also change from
`jakartaee-tck` to something else that does not
repeat the words that are already in the new
repository link. Specifically, IMO, we should not
repeat the words `Jakarta EE`, to avoid the new
repo being called
https://github.com/jakartaee/jakartaee-tck.
Scott
All,
In 2019 the Steering Committee we passed a
proposal to move the Github repos for
specification projects into the
https://github.com/jakartaee org in
Github.
- Proposal:
https://docs.google.com/document/d/1vQst9k0fOGhUbbw3RoOvi-BvjiSsADH4dyjqTquIwE8/edit?usp=sharing
- Approval:
https://jakarta.ee/about/meeting_minutes/steering_committee/minutes-june-11-2019.pdf
- Breakdown:
https://docs.google.com/spreadsheets/d/1uoCebbw2ucpFO389VwTIEd6cqwBXhgE3Cq2fhS6g6ps/edit?usp=sharing
- Prototype:
https://github.com/orgs/jakarta-ee
We've delayed this for 2 years as to not impact
release dates of Jakarta EE 8, Jakarta EE 9 and
Jakarta EE 9.1. Those are out the door and we
finally have time to do fun things like refactor
TCKs, pay down technical debt and create new
features. This is also an item in our 2021
Jakarta EE Program Plan we have not yet
executed.
Here's my recommendation on how we should
approach the move:
- Set a goal of completing the move in the next
six months. It's
very quick to do and Github handles redirects,
but six months gives
the project some good flexibility to decide
when is the right time.
- Establish a naming convention of using your
specification's short
name as the prefix for any and all repos
moved. For example, the
project formerly known as JMS is "messaging"
and can be found at
https://jakarta.ee/specifications/messaging/
It would be ideal if all repos belonging to
Messaging, for example,
were available as either the bare word
https://github.com/jakartaee/messaging
or with a hyphen
https://github.com/jakartaee/messaging-*
- All repos belonging to the Specification
Project are moved, such as
any api, tck, proposal or example repos.
The caveat to the above is that if your
specification project has implementation code in
its repository this code should be moved to
another Github repo that stays in eclipse-ee4j
and is transferred to a new or existing
non-specification Eclipse project. That is, if
that is possible. If it isn't possible to
separate the implementation, we'll likely need
to move it as-is and just live with the slight
imperfection.
To initiate the move, file a ticket in the
Community bugzilla using the "Github" component,
list the repos to be moved and indicate any repo
name changes:
-
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community
Providing a link to this email in that ticket
can also help with context, but is not strictly
necessary.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev