It’s fine to create a new repository dedicated for Jakarta Platform management. But, there are some disadvantages:
1. Only developers who has access to this repository will be able to update issues. If you want to update it yourself, it’s fine. If you want people who work on tasks to do it, you will need to give them rights. 2. I think it’s better if all project related tasks are stored in one place which is a project issues tracker. Adding another tracker will make developer’s life more complicated.
IMO, the beast solution would be if you (or whoever else managing a platform release) has rights to manage issues in all eclipse-ee4j organization repositories. In this case no new repository is needed, all issues are created in a project they belong to and you can edit them, create labels and do all management work without limitations.
- Dmitry
This is more of a
release management question (vs a technical question), so if you are not
interested in planning, you can skip this message...The github
project boardwe have in place is working nice, but I'm hitting a couple of gotchas...- The notecards
I am using in the RC
column are
not very usable or flexible. I can't add tags, labels, relationships,
assignments, etc.
- For example, if
Ifilter on "wave:1",
I can see all of the Issues assigned to Wave:1, except I can't see whether
we have any RCs available for Wave:1 yet. Unless I open each individual
Issue and review it's checklist.
- I was thinking
of converting these Notecards in the RC column to Issues. I could
add the necessary tags/labels to these Issues and the project board would
be more useful. But, these Issues would only be used for tracking
purposes, so it seems silly to clutter up "real code" repositories.
- So, I was thinking
of creating a new repo called jakartaee-release, or jakartaee-mgmt, or
jakartaee-project (I'm not picky). I used the jakartaee- prefix since
the Platform project was responsible for developing the Release Plan and
we already own the jakartaee-platform, jakartaee-api, and jakartaee-schemas
repos. I just didn't want to clutter up the jakartaee-platform repo
with these release mgmt Issues. I also want to use a repo that we
have write access to so that it's easier to maintain.
- You'll notice
that the PR column for the Specifications and Apidocs can already utilize
these tags/labels since we have write access to that repo. So, a
query for "wave:0"shows all of the Issues and the PRs associated with "wave:0".
Maybe I'm
over-complicating things here... I'm open to other suggestions. Thanks! --------------------------------------------------- Kevin Sutter STSM, MicroProfile and Jakarta EE architect @ IBM e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|