Thanks, Ben, for the email.
I would like to add, that such automatic check would make it easier for
newbie contributor like me to follow code standard of the project.
Regards,
Sandra
Am 27.11.20 um 10:29 schrieb Benjamin Marwell:
> Hello everyone,
>
> MJLINK-PR19 [1] removes some plexus import
Hello dev-list,
some weeks ago, I have started creating some Pull Requests for the Maven
JLink Plugin [1]. There were many hints about coding rules or decision
which version / libs etc should be used and more. So I need some
iterations till a trivial (IMHO) PR was accepted or in one case to find
o
p on becoming a
> Maven contributor? I think it would be very beneficial for the attendees, so
> we would not just have the appreciated voices of Karl-Heinz and Robert, but
> also your view as a first-time plugin contributor!
>
> -Ursprüngliche Nachricht-
> Von: S
t;>
>> On Tue, Dec 22, 2020 at 2:47 PM Gary Gregory
>> wrote:
>>
>>> It would be great if one could download Eclipse or Idea settings files,
>> or
>>> better yet, include them in each repo.
>>>
>>> Gary
>>>
>>> On Tue, D
at IF we would use them, we need to keep them in sync for all
> ~100 repositories, which is a big no for me.
> Updating the IDE specific files seems like the appropriate way to handle this.
>
> thanks,
> Robert
> On 23-12-2020 12:39:11, Sandra Parsick wrote:
>> those
Hi all,
I started a Github repository [1], where I will collect my lessons
learned. Contribution is welcome.
Regards,
Sandra
[1] https://github.com/sparsick/maven-contribution-newbie
Am 23.12.20 um 12:29 schrieb Sandra Parsick:
>
>> welcome in the Maven dev community!
>
Hi,
we already opened epic issues based on discussions in this repository
(see https://github.com/OpenElements/maven-support-care/issues).
This was necessary for the funding.
The issue about Java module path can be found here:
https://github.com/OpenElements/maven-support-care/issues/49
Do
My 2 cent from a user perspective:
Spring's approach has a benefit. As a user, I need only search for an
issue in only one location.
But I also understand Michael's point, that it is a chance for a cleanup
of the backlog.
Regardless of whether all issues should be migrated or not, I could a
which was actively in work.
Sandra
Am 04.12.24 um 08:36 schrieb Sandra Parsick:
My 2 cent from a user perspective:
Spring's approach has a benefit. As a user, I need only search for an
issue in only one location.
But I also understand Michael's point, that it is a chance for a cle
Hi,
I created an overview about the Jira Project that are Maven related (I
used the project category 'Maven' and ignored retired projects) [1].
I will start creating migration configuration based on that list. Do you
have prefered order? Did I miss any projects?
-
Sandra
[1] https://github
/main/java/io/pivotal/migration/MSharedMigrationConfig.java
Am 19.12.24 um 14:36 schrieb Sandra Parsick:
I'd like to share the current status of testing the migration tool.
Label Mapping:
I resolved a problem with already existing labels in the repository.
We can map Jira issue direct
Yes, it is not the best location. I didn't know it better. Do you know a
better place? Maybe a separate repository?
By the way, thanks for your effort.
You are welcome :)
Am 06.01.25 um 13:47 schrieb Slawomir Jaranowski:
On Mon, 6 Jan 2025 at 13:15, Sandra Parsick wrote:
Hi,
I crea
has to be informed to set the Jira project to read-only. Enabling Github
Issue could be done by a Maven committer.
Am 07.01.25 um 17:25 schrieb Slawomir Jaranowski:
On Tue, 7 Jan 2025 at 16:56, Sandra Parsick wrote:
I created migration configuration for the following projects :
- MCLEAN [1
12:22 schrieb Sandra Parsick:
After a discussion with Gerd Aschemann, I moved the migration list from
the Github Issue to the repository of the migration tool [1]. I adjusted
the list according to already provided feedback.
If someone wants to have write permission to this repository, please let
it to you (I only need your GitHub nickname).
I think that will be easier to maintain the migration list and to change
the tool, if necessary.
Am 06.01.25 um 15:03 schrieb Sandra Parsick:
First we need to enable issues on GitHub to allow migrating issues.
So please add a column "GitHub I
Sorry for not getting back to you sooner. I was on vacation.
it is something we prepared
https://lists.apache.org/thread/07p1xyz210755qsl5gt466nyp3tdzmrs
I don't know why it did not happen in this migration
@Benjamin any idea?
The PR linking did work because the step “importing issues” failed
-gh-issues
[3] https://github.com/support-and-care/mvn-issues-migration-test/issues
Am 07.12.24 um 18:04 schrieb Slawomir Jaranowski:
On Fri, 6 Dec 2024 at 14:41, Sandra Parsick wrote:
I asked on other channels, how Spring migrated their Jira issues. I got
a link to their migration tool:
https
,
Thanks for testing it.
Some comments inline.
On Wed, 11 Dec 2024 at 02:22, Sandra Parsick wrote:
IMHO, the task of manual checking of the issues is independent of the
issue location.
As I said, from a user perspective, it is comfortable to have one
location to search for issues,
Nevertheless
t-and-care/jira-to-gh-issues/refs/heads/master/README.adoc
Am 14.12.24 um 09:07 schrieb Sandra Parsick:
I tested the author mapping of the Spring migration tool.
You have to maintain a properties file for the mapping [1].
Mapping means that the original author is mentioned in the GH issue
co
+1 (non binding)
Am 18.12.24 um 08:29 schrieb Slawomir Jaranowski:
Hi,
I open vete for question:
Do we want to Switch to GitHub issues from JIRA?
Discussion was in thread:
https://lists.apache.org/thread/jskz22vsbv2n5ks1q42690ohp7cbt1qw
About technical questions how we will switch, if mig
care/mvn-issues-migration-test/issues/120
[3] https://github.com/support-and-care/jira-to-gh-issues/issues/7
[4] https://github.com/support-and-care/jira-to-gh-issues/issues/6
Am 12.12.24 um 07:37 schrieb Sandra Parsick:
Thanks for the feedback.
I collected it as issues in the migration tool repos
.adoc
Am 17.12.24 um 14:51 schrieb Sandra Parsick:
I'm playing around with the label mapping.
The migration tool has a feature, where you can configure a direct
mapping from Jira issue type to Github labels [1].
Furthermore, you can implement an IssueProcessor, where you can
implement
anels:comment-tabpanel#comment-17715440>
XXX commented on code in PR #212:
URL: https://github.com/apache/maven-site/pull/212#discussion_r1174557289
##
content/apt/guides/mini/guide-http-settings.apt:
##
pt., 10 sty 2025 o 21:51 Hervé Boutemy napisał(a):
Le mercredi 8 janvi
his case it should be the same.
On Tue, 7 Jan 2025 at 17:41, Sandra Parsick wrote:
No manual work ...
I thought about not migrate issues at all for this repo - MNGSITE
Ah, thanks for clarifying. I misunderstood it.
We have voted about switching to GitHub ...
https://lists.apache.org/thread/h4
/github.html#Priority
On Fri, 10 Jan 2025 at 21:51, Hervé Boutemy
wrote:
Le mercredi 8 janvier 2025, 18:50:59 CET Sandra Parsick a écrit :
- ARCHETYPE
Migration result:
https://github.com/support-and-care/mvn-issues-migration-test-archetype
Used migration config:
https://github.com/support-a
result in this repository:
https://github.com/support-and-care/jira-to-gh-issue-dummy-repo
Feedback is welcome.
If this solution is acceptable, we could start with the first migration.
-
Sandra
Am 21.01.25 um 08:36 schrieb Sandra Parsick:
To avoid lots of spam mails during testing, I think, I
k, but not easy...
what about using existing empty Jira project that you discovered?
https://issues.apache.org/jira/projects/MMETRIC
That should work, I will test it.
Thank you
-
Sandra
Am 21.01.25 um 07:47 schrieb Hervé Boutemy:
Le mardi 14 janvier 2025, 14:29:29 CET Sandra Parsick a écrit :
anche 12 janvier 2025, 09:50:28 CET Sandra Parsick a écrit :
It appears that link to an external sources have a separate datatype.
Therefore, the migration tool ignores it. I will fix it (see issue [1]).
I solved this issue. I added a new text in the body. Please check it if
it is good enoug
her thing that I recognized:
Some milestones have label characteristics like 'waiting-for-feedback',
'more-investigation' or 'backlog' (IMHO). Should they stay as
milestones, or should they map to (new) labels?
Am 13.01.25 um 11:12 schrieb Slawomir Jaranowski:
On Mon,
n 2025 at 12:51, Sandra Parsick wrote:
Please check, is there a space after ":"
"priority: major" - > "priority:major"
as defined in: https://github.com/apache/maven-gh-actions-shared/pull/129
Thanks for the catch. I fixed it.
I did a new test run with al
ra
Am 14.01.25 um 10:55 schrieb Slawomir Jaranowski:
On Tue, 14 Jan 2025 at 09:52, Sandra Parsick wrote:
I would like to move it to labels.
We can use a stale action to close inactive issues, pr.
I found the following milestone in MCLEAN, MJLINK, ARCHETYPE with label
characteristics (and I
As Hervé already mentioned, I started the list on GitHub because I
didn't know where is the best place to put this kind of information.
I clean up the list on GitHub and remove all duplicated information.
Only the status about the migration config for the tool is stayed and
some remarks, but I
Maven
has invited Sandra Parsick to become a committer
and we are pleased to announce that they have accepted.
Please join us in welcoming Sandra to their new role
and responsibility in our project community.
-
To unsubscribe, e
Thanks for your input. Let me try to summarize the current state of
discussion:
- It seems we have consensus that implementing Tier 1 (Prevent force
push + Prevent branch deletion) is a good idea
- The rules should be synced between Gitbox and GitHub
- We need more time to evaluate which conse
As discussed in a previous thread, it makes sense from a supply chain
security perspective to introduce the following branch protection rules
to all Maven repositories:
- Prevent force push
- Prevent branch deletion
It will be enabled by .asf.yaml to ensure that the same branch
protection rul
is evaluated by Gitbox. Do you have any reference
about the branch deletion part?
I am not against it, just highlighting that you can bypass it.
Thanks,
Konrad
On 5. Aug 2025, at 13:45, Sandra Parsick wrote:
As discussed in a previous thread, it makes sense from a supply chain security
Hi,
I have taken a more in-depth look at the branch protection checks of the
OpenSSF scorecard best-practices, and I'd like to discuss two topics:
1. Do we want to enable GH rules to pass some of them?
2. How do we want to enable the GH rules?
In their documentation [0] , follo
t's a very good step
for next steps, please all prepare in depth: maybe I'm just lacking optimism
Regards,
Hervé
Le mercredi 30 juillet 2025, 13:02:01 CEST Sandra Parsick a écrit :
Hi,
I have taken a more in-depth look at the branch protection checks of the
OpenSSF scorecard best-practi
be? Could one (a
malevolent actor) perform a force-push against a branch on the Gitbox
which would then nevertheless end up on GitHub as well? Or delete a
branch? Or... (you get the idea).
Thanks,
Maarten
On 30/07/2025 13:02, Sandra Parsick wrote:
Hi,
I have taken a more in-depth look at
It's a good idea to use test branches in maven-studies to check the
rules. I'd like to go a step further. I think that we should pick a
repository and apply a certain rule to it.
We can see if this rule works for us in real life.
If not, the change can be reversed. If it is successful, we can r
40 matches
Mail list logo
