pon., 6 sty 2025 o 20:26 Manfred Moser napisał(a):
>
> On 2025-01-06 11:00 a.m., Sylwester Lachiewicz wrote:
> > One important thing here is that Maven is not a single repo but has more
> > than 100 repos.
> > If I fork all repos then I need to sync forks.
>
> You only need to sync and maintain f
On 2025-01-06 11:00 a.m., Sylwester Lachiewicz wrote:
One important thing here is that Maven is not a single repo but has more
than 100 repos.
If I fork all repos then I need to sync forks.
You only need to sync and maintain forks of what you are working on ..
not all repos.
Also in my f
One important thing here is that Maven is not a single repo but has more
than 100 repos.
If I fork all repos then I need to sync forks. Also in my forks
- Dependabot will push branches and PRs. Run GHAk tests on my fork also.
So we have lots of notifications - not only to Maven dev/commit lists bu
On Mon, Jan 6, 2025 at 4:56 PM Manfred Moser wrote:
>
> Abandoned and even used personal branches cause overhead for everyone
> who works on that repo or a fork of it.
Exactly what overhead is that? Seriously, I don't see it.
> Also note.. that using a personal fork is the only way to guarantee
On Mon, 6 Jan 2025 at 16:47, Konrad Windszus wrote:
>
> Leveraging Automatic Analysis cannot calculate code coverage. Therefore the
> option with two different GHAs should be used (as outlined in
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=321719166#GitHubActionsSecurity-B
On Mon, 6 Jan 2025 at 16:16, Elliotte Rusty Harold wrote:
>
> On Mon, Jan 6, 2025 at 8:20 AM Slawomir Jaranowski
> wrote:
> >
> > Hi,
> >
> > Last time I enabled GitHub issues in https://github.com/apache/maven-site
> > I don't have a plan to copy old issues for this project from jira to GitHub.
+1 from me (not that my opinion should count for much here)
From: Manfred Moser
Date: Monday, 6 January 2025 at 16:51
To: dev@maven.apache.org
Subject: Re: Using git forks
This email was sent to you by someone outside the University.
You should only click on links or attachments if you are cert
Abandoned and even used personal branches cause overhead for everyone
who works on that repo or a fork of it.
They are personal branches.. so they should be in personal forks..
Also note.. that using a personal fork is the only way to guarantee that
the branch is under your control. If you use
Well, it's not like abandoned branches cost anything significant, but
as someone else suggested if there's no activity after N months and
there are no open PRs on the branch, then delete them. No biggie.
On Mon, Jan 6, 2025 at 4:02 PM Tamás Cservenák wrote:
>
> Howdy,
>
> This is all nice and dan
Hi all,
Let me chime in as Maven committer (mostly inactive but involved on
various external fronts) and core maintainer of Trino. Trino had over
200 separate contributors in our repo in 2024. We only have about a
dozen maintainers and none of us really has the time to worry about
branches in
Howdy,
This is all nice and dandy with you explaining how things are done in
companies, but this is NOT one of them, this is an open source
project.
Somewhere in the future, when you are gone from the project, NOBODY
will know what these branches are for (unless they do some archaeology
explorati
Howdy,
And I guess fixing the mailing list will also take care of all your
branches in canonical repo, if a bus hits you tomorrow...
On Mon, Jan 6, 2025 at 4:40 PM Elliotte Rusty Harold wrote:
>
> On Mon, Jan 6, 2025 at 3:33 PM Tamás Cservenák wrote:
> >
> > This is just utterly silly: I am NOT
Leveraging Automatic Analysis cannot calculate code coverage. Therefore the
option with two different GHAs should be used (as outlined in
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=321719166#GitHubActionsSecurity-Buildstriggeredwithworkflow_run).
Regards,
Konrad
> On 5. Jan
On Mon, Jan 6, 2025 at 3:33 PM Tamás Cservenák wrote:
>
> This is just utterly silly: I am NOT interested at all in your branches:
>
I don't expect you to be. Ignore them. The problem is not that the
branches exist. It is that the mailing list is bothering you with
them. Fix the mailing list.
--
This is just utterly silly: I am NOT interested at all in your branches:
➜ maven git:(master) git fetch upstream -p
>From github.com:apache/maven
- [deleted] (none)
-> upstream/dependabot/maven/org.assertj-assertj-core-3.27.1
remote: Enumerating objects: 72, done.
remote: Coun
On Mon, Jan 6, 2025 at 7:38 AM Guillaume Nodet wrote:
>
> Le dim. 5 janv. 2025 à 15:49, Elliotte Rusty Harold
> a écrit :
> >
> > I do think the mailing list is severely misconfigured if it's paying
> > any attention to dev branches. There's no reason it should be picking
> > these commits up. If
On Mon, Jan 6, 2025 at 8:26 AM Guillaume Nodet wrote:
>
> Is there any way to make the JIRA for migrated projects read-only, or
> at least disable the creation of new issues ?
We don't want it to be read-only prior to a full migration since many
of these issues still need to be worked on. Disabli
On Mon, Jan 6, 2025 at 8:20 AM Slawomir Jaranowski
wrote:
>
> Hi,
>
> Last time I enabled GitHub issues in https://github.com/apache/maven-site
> I don't have a plan to copy old issues for this project from jira to GitHub.
>
Can we figure that out before we proceed with the other repos? This is
i
First we need to enable issues on GitHub to allow migrating issues.
So please add a column "GitHub Issues enabled"
Thanks for the feedback. I added another column.
I'm still not sure if we need to copy issues for all projects - up to you.
My preferred way is to migrate all issues for all pr
Hello
(Please let me know if there is a more appropriate mailing list for this
query. Apologies if it's duplicated, I tried sending before I was
subscribed before)
Is there a release schedule for this extension? Or, when is the next
release tag planned for?
https://maven.apache.org/extensions/ma
On Mon, 6 Jan 2025 at 13:15, Sandra Parsick wrote:
>
> 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
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
Le 2025-01-06 08:38, Guillaume Nodet a écrit :
What I think would be lost time is to have to go through all branches
in a repo to do some cleanup... ;-)
That could be automated anyway. Have a short list of known branches you
want to keep, and then for everything else:
- branch merged? -> del
On Mon, 6 Jan 2025 at 09:26, Guillaume Nodet wrote:
>
> Is there any way to make the JIRA for migrated projects read-only, or
> at least disable the creation of new issues ?
> That would help a lot in guiding existing contributors to GitHub for new
> issues.
>
There is a ticket for infra ...
htt
Is there any way to make the JIRA for migrated projects read-only, or
at least disable the creation of new issues ?
That would help a lot in guiding existing contributors to GitHub for new issues.
Le lun. 6 janv. 2025 à 09:21, Slawomir Jaranowski
a écrit :
>
> Hi,
>
> Last time I enabled GitHub i
Hi,
Last time I enabled GitHub issues in https://github.com/apache/maven-site
I don't have a plan to copy old issues for this project from jira to GitHub.
Now I'm working on next repo -
https://github.com/apache/maven-apache-resources/pull/23
In next I will use the similar issues templates
We ha
26 matches
Mail list logo
