One more thing I just noticed. When I use the Github editor to make
small changes to a file directly in my browser as I did in
https://github.com/apache/maven-site/pull/629 and many other PRs,
especially ones focused on docs, it offers me the option to edit
master directly or create a branch, not a
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
+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
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
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
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
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 it is, let's fix it, not contort people's
> development processes an
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 it is, let's fix it, not contort people's
development processes and put still more restrictions and constraints
on the already very limited
Eclipse Platform uses Github for a while now and we have completely
switched to using forks for devs and contributors including protecting
the main branch from direct pushes as described here[1].
A slight (and convenient) deviation is that you do not clone your fork,
but the original repositor
anding worthies or
> from us occasional self-interest contributors.
>
> Later,
>
> Andy
>
> From: Elliotte Rusty Harold
> Date: Saturday, 4 January 2025 at 18:02
> To: Maven Developers List
> Subject: Re: Using git forks
> This email was sent to you by someone outside the
I am about to run some analysis of the overall Maven project with jQAssistant in the next weeks (currently I am fighting with some problems with the tool as it is really a large codebase).However, as a quick win I can provide some data about the number of branches.The attached Excel lists all (133)
contributors.
Later,
Andy
From: Elliotte Rusty Harold
Date: Saturday, 4 January 2025 at 18:02
To: Maven Developers List
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 certain that the email
is genuine
On Sat, 4 Jan 2025 at 15:15, Tamás Cservenák wrote:
>
> Howdy,
>
> I'd like to ask devs to NOT code directly against branches in ASF
> repositories, as we are swamped literally with unwanted spam: I am not
> interested in each commit of the branch being worked on.
>
> Instead, fork the repo and cr
On Sat, 4 Jan 2025 at 17:11, Elliotte Rusty Harold wrote:
>
> The tail is wagging the dog here. It sounds like you need to
> reconfigure the mailing list to not be so noisy; i.e. to ignore
> commits on non-master branches. The problem is the mailing list, not
> the branches.
It will be difficult
On Sat, 4 Jan 2025 at 18:17, Konrad Windszus wrote:
>
> Hi,
> There used to be some problems related to CI. At least ASF Jenkins
> differentiates between forked PRs and non-forked PRs.
> For GitHub Actions there is a difference with regards to permissions
> (https://docs.github.com/en/actions/wr
Eliotte,
don't get me wrong, but i have hard time to follow your reasoning:
- i posted how we all are _swamped_ by commit mails as canonical repo
is used for development
- you came back as "ML is misconfigured"
- then I asked you who will clean up these vaguely named branches you
create in canonic
On Sat, Jan 4, 2025 at 4:20 PM Tamás Cservenák wrote:
>
> But to continue: what will happen to branches named like "mdo",
> "apidoc", "copy", "null" etc in _cnonical maven repo_ if you go
> missing?
Branches are cheap, but the way these things work if these aren't
cleaned up manually, eventually
Howdy,
am pretty much sure:
https://github.com/apache/maven/actions/runs/12606622638
For starters, we haven't used Jenkins since some time... is disabled.
Thanks
T
On Sat, Jan 4, 2025 at 6:17 PM Konrad Windszus wrote:
>
> Hi,
> There used to be some problems related to CI. At least ASF Jenkins
Hi,
There used to be some problems related to CI. At least ASF Jenkins
differentiates between forked PRs and non-forked PRs.
For GitHub Actions there is a difference with regards to permissions
(https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-perm
Unsure about the tail,
but as I said: I do want to know about changes in the canonical repo.
Also, it is not "me", it is ASF setup and AFAIR it was always like it.
But to continue: what will happen to branches named like "mdo",
"apidoc", "copy", "null" etc in _cnonical maven repo_ if you go
missin
The tail is wagging the dog here. It sounds like you need to
reconfigure the mailing list to not be so noisy; i.e. to ignore
commits on non-master branches. The problem is the mailing list, not
the branches.
On Sat, Jan 4, 2025 at 2:46 PM Tamás Cservenák wrote:
>
> >>> and shouldn't clutter the c
>>> and shouldn't clutter the commit logs.
Well, my point is that they DO clutter commit logs, see ML link.
On your (private) fork I am not notified about your each commit, while
I AM notified about each commit on ASF repo :)
Also, I DO want to be notified about ANY change happening in canonical
This shouldn't be a problem if we disable everything except squash and
merge and require all commits to go through PRs. We do have a big
problem with commits that go straight into the source tree without a
PR or a code review.
Branch vs fork is a red herring. IMHO working on branches is much
simpl
Howdy,
I'd like to ask devs to NOT code directly against branches in ASF
repositories, as we are swamped literally with unwanted spam: I am not
interested in each commit of the branch being worked on.
Instead, fork the repo and create PRs.
The commits ML is nearly unusable, I'd really like to se
33 matches
Mail list logo
