Why don't you just apply to be a committer on every project? Would
that give you want you need? The PMC could make it a requirement
that the Jakarta EE "release manager" is given Committer rights on
every project. If necessary, you can be retired as a Committer when
you are no longer doing the release manager job.
Kevin Sutter wrote on 1/29/20 6:47 AM:
> 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.
Absolutely
agree.
This will be my number one piece of feedback after this release
is
done. I pushed for this at the beginning of the process, but I
wasn't
able to convince them. So, I'm attempting to live within the
means
for now.
---------------------------------------------------
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
From:
Dmitry
Kornilov <dmitry.kornilov@xxxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
01/29/2020
08:34
Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Tracking progress of Jakarta EE 9
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
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
On 28 Jan 2020, at 23:38, Kevin
Sutter
<sutter@xxxxxxxxxx>
wrote:
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
columnare 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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
