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
us occasional self-interest contributors.Later,AndyFrom: Elliotte Rusty Harold Date: Saturday, 4 January 2025 at 18:02To: Maven Developers List Subject: Re: Using git forksThis email was sent to you by someone outside the University.You should only click on links or attachments if you are certain
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
On 1/24/24 6:31 AM, Konrad Windszus wrote:
Ping, does anyone have any input on this? Would be much appreciated,
Thanks,
Konrad
On 8. Jan 2024, at 19:16, Konrad Windszus wrote:
Hi,
According to https://maven.apache.org/pom/maven/#the-format-profile the git
commits created through applying
Ping, does anyone have any input on this? Would be much appreciated,
Thanks,
Konrad
> On 8. Jan 2024, at 19:16, Konrad Windszus wrote:
>
> Hi,
>
> According to https://maven.apache.org/pom/maven/#the-format-profile the git
> commits created through applying the spotless formatting should be ig
Hi,
According to https://maven.apache.org/pom/maven/#the-format-profile the git
commits created through applying the spotless formatting should be ignored via
a .git-blame-ignore-revs file. This file is automatically evaluated by GitHub
blame view. This doesn’t work well if the formatting also
https://jira.codehaus.org/browse/MRELEASE-723
> From: mfriedenha...@gmail.com
> Date: Tue, 20 Dec 2011 21:14:59 +0100
> Subject: Re: maven-release-plugin: using git where do I see the tag used to
> build the release in the pom?
> To: dev@maven.apache.org
>
> Hello,
>
Hello,
I erroneously opened the issue in the SCM plugin
(https://jira.codehaus.org/browse/SCM-655), however it is an issue of
MRELEASE probably. Would someone with the according rights move it to
http://jira.codehaus.org/browse/MRELEASE, please?
Best regards Mirko
On Mon, Dec 19, 2011 at 22:56,
Then it will have to be the tag name so...
On 19 December 2011 21:28, Mirko Friedenhagen wrote:
> Hm, this will be a hard one. I know detected, that the rewrite of the
> SCM section happens in the maven-release-plugin
> (org.apache.maven.shared.release.phase.RewritePomsForReleasePhase).
> Two pro
Hm, this will be a hard one. I know detected, that the rewrite of the
SCM section happens in the maven-release-plugin
(org.apache.maven.shared.release.phase.RewritePomsForReleasePhase).
Two problemes I encountered now:
- The maven-scm-plugin does not seem to implement the equivalent of
"scm:info" (
some scm providers have something implemented.
for git it's : git rev-parse --verify HEAD
for svn: svn info
for hg: hg id
more details on those providers in various Info command impls.
2011/12/19 Stephen Connolly :
> On 19 December 2011 10:45, Mirko Friedenhagen wrote:
>> As discussed on the us
On 19 December 2011 10:45, Mirko Friedenhagen wrote:
> As discussed on the user-list:
>
>>> > > > On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
>>> > > > wrote:
>>> > > > > Hello,
>>> > > > >
>>> > > > > I know that with SVN the developerConnection and connection are
>>> > > > > updated to th
As discussed on the user-list:
>> > > > On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
>> > > > wrote:
>> > > > > Hello,
>> > > > >
>> > > > > I know that with SVN the developerConnection and connection are
>> > > > > updated to the "real" URL, that is when I invoke release:prepare
>> > > > >
Milos, with all respect: Unless Nigel is an employee of or paid by
Microsoft, IBM, or whoever might have a professional interest in the
decline of NetBeans, I do think that's a valid expression of an
opinion.
On Mon, May 11, 2009 at 8:12 AM, Milos Kleint wrote:
> On Wed, Apr 29, 2009 at 10:34 PM
On Wed, Apr 29, 2009 at 10:34 PM, Nigel Magnay wrote:
> > My vote does not really count here, but Sun aggressively
> supports
> > Mercurial in NetBeans. Based on reviews, Mercurial seemed to initially
> have
> > a technical edge whereas GIT had a loyal following. They do compete
> > aggressively
> My vote does not really count here, but Sun aggressively supports
> Mercurial in NetBeans. Based on reviews, Mercurial seemed to initially have
> a technical edge whereas GIT had a loyal following. They do compete
> aggressively and GIT has fixed many of its issues.
>
> NetBeans works better wi
in context:
http://www.nabble.com/Using-GIT-as-the-canonical-repository-for-Maven-3.x-tp23201420p23301063.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr
ntony Stubbs
Reply-to: "Maven Developers List"
To: dev@maven.apache.org
Subject: Re: Using GIT as the canonical repository for Maven 3.x
Date: Fri, 24 Apr 2009 17:57:51 -0700 (PDT)
multiple branches in 1 repo (in hg
last time i looked you have to create a new copy to checkout a d
> Do you see that Google choose Mercurial rather than Git ?
>
> Mercurial support for Project Hosting on Google Code
> http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html
>
> Analysis of Git and Mercurial
> http://code.google.com/p/support/wiki/DVCSAnalysis
>
2009/4/27 Rémy Sanlaville
> Do you see that Google choose Mercurial rather than Git ?
>
well, they didn't exactly choose one over the other - they decided to
implement Mercurial support first because it fitted better (at the time)
with GoogleCode hosting - I wouldn't be surprised to see Git supp
Do you see that Google choose Mercurial rather than Git ?
Mercurial support for Project Hosting on Google Code
http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html
Analysis of Git and Mercurial
http://code.google.com/p/support/wiki/DVCSAnalysis
Rémy
The gitexe has already the full maven-sm-test TCK suite implemented. So all the
things like a prepackaged git repo for the TCK is already there.
LieGrue,
strub
--- Brian Fox schrieb am Sa, 25.4.2009:
> Von: Brian Fox
> Betreff: Re: Using GIT as the canonical repository for Maven 3.
If you like me to help then simply ping me, I'd be honoured to help.
I didn't dive into the testing structure in place there, but if it
doesn't exist already, some external ITs would be awesome. Something we
could run against the multiple implementations to guarantee compatibility.
---
d the need) to start to
implement the jgit part.
But it should be really easy to add it.
If you like me to help then simply ping me, I'd be honoured to help.
LieGrue,
strub
--- Brian Fox schrieb am Sa, 25.4.2009:
> Von: Brian Fox
> Betreff: Re: Using GIT as the canonical repo
a separate directory.
-
___
http://stubbisms.wordpress.com http://stubbisms.wordpress.com
--
View this message in context:
http://www.nabble.com/Using-GIT-as-the-canonical-repository-for-Maven-3.x-tp23201420p23227239.html
Sent from the Maven Developers mailing list a
y a clean checkout into a separate directory.
> >
>
>
> -
> ___
>
> http://stubbisms.wordpress.com http://stubbisms.wordpress.com
> --
> View this message in context:
> http://www.nabble.com/Using-GIT-a
all rubbish from
.gitignore left in your working directory. And this may affect the build ...
LieGrue,
strub
--- Antony Stubbs schrieb am Sa, 25.4.2009:
> Von: Antony Stubbs
> Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> An: dev@maven.apache.org
> Datum: Samsta
n't checked in or ignored but
> somehow affect the compile or test outcome. This may imho only be
> guaranteed by a clean checkout into a separate directory.
>
-
___
http://stubbisms.wordpress.com http://stubbisms.wordpress.com
--
View this message i
; Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> --
>>>
>>> In short, man creates for himself a new religion of a rational
>>> and technical order to justify his
ail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
>
> --
> Arnaud
>
>
-
___
http://stubbisms.wordpress.com http://stubbisms.wordpress.com
--
View this messa
On 24-Apr-09, at 11:17 AM, Robert Burrell Donkin wrote:
Correct. The model that Android uses I would say is optimal for an
open source project. People can take real copies and derive all the
benefit from that, but they push to a gatekeeper where submissions
are
vetted. Gerrit represents som
> If developers here were truly interested they would ask and I'm
always > happy to answer specific questions.
I'd just like to point out one thing: it's not necessarily lack of
interest that can keep developers out of the picture, but also an
inability to keep up. Too much project velocity c
Yes I agree. Only the canonical code can be used to produce official
maven builds and those tags are pushed back to the master. No different
really than what happens today.
On 4/24/2009 4:53 PM, John Casey wrote:
There is one very important issue with dscm:
To be in line with our goals for Ma
There is one very important issue with dscm:
To be in line with our goals for Maven in general - especially
reproducibility - the tag created from a release MUST be available for
others to grab and rebuild from. This means that a git push is
absolutely necessary to finish off the release proce
ectory?
isn't the scm tag supposed to give you the relative path to the pom's
parent folder?
could we not just parse the scm URL to get the git root relative path
to the pom
LieGrue,
strub
--- Brian Fox schrieb am Fr, 24.4.2009:
Von: Brian Fox
Betreff: Re: U
not a technical one. Gerrit may
also check for a 'ASL2 license granted' flag like it's solved in
issues.apache.org for patches.
LieGrue,
strub
--- Robert Burrell Donkin schrieb am Fr,
24.4.2009:
> Von: Robert Burrell Donkin
> Betreff: Re: Using GIT as the canonical reposito
On 4/24/09, Jason van Zyl wrote:
>
> On 24-Apr-09, at 7:55 AM, Robert Burrell Donkin wrote:
>
>> On Fri, Apr 24, 2009 at 3:46 PM, Jason van Zyl
>> wrote:
>>> On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
>>>
>
> Is sounds like the process used by our release plugin doesn't
>
On 24-Apr-09, at 7:55 AM, Robert Burrell Donkin wrote:
On Fri, Apr 24, 2009 at 3:46 PM, Jason van Zyl
wrote:
On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
Is sounds like the process used by our release plugin doesn't
really
match
the way git works, so maybe we can change the w
On Fri, Apr 24, 2009 at 3:46 PM, Jason van Zyl wrote:
> On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
>
>>>
>>> Is sounds like the process used by our release plugin doesn't really
>>> match
>>> the way git works, so maybe we can change the way the release plugin
>>> works
>>> instead of
I have been starting to play with git for the jetty @ eclipse source
base, still backed by svn but just to get a feel for how it
works...and its pretty neat.
that said, I would say that maven3 is the prime mvn target to iron out
the mvn issues with release plugins and all the other core toolchain
On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
Is sounds like the process used by our release plugin doesn't
really match
the way git works, so maybe we can change the way the release
plugin works
instead of trying to fit git into our model. Do we really need to
do a
clean checko
On Fri, Apr 24, 2009 at 3:20 PM, Paul Gier wrote:
> Mark Struberg wrote:
>>
>> Hi!
>>
>> I thought in a similar direction. I think we can even let the maven-scm as
>> it is.
>> The problematic usecase is if we have a multi-module build and like to
>> release only one of the sub modules.
>>
>> John
On 24-Apr-09, at 10:20 , Paul Gier wrote:
Mark Struberg wrote:
Is sounds like the process used by our release plugin doesn't really
match the way git works, so maybe we can change the way the release
plugin works instead of trying to fit git into our model. Do we
really need to do a clea
y.
> process doesn't really match the way git works
I have the gut feeling that there are quite a few SCMs out there (accurev, hg,
PVCS, git,..) which work that way and they only got not enough love yet ;)
LieGrue,
strub
--- Paul Gier schrieb am Fr, 24.4.2009:
> Von: Paul Gier
> Be
Mark Struberg wrote:
Hi!
I thought in a similar direction. I think we can even let the maven-scm as it is.
The problematic usecase is if we have a multi-module build and like to release
only one of the sub modules.
John Casey prepared an example for this use case:
$> git-clone http://www.co
On 24-Apr-09, at 4:24 AM, Raphaël Piéroni wrote:
Hi folks,
Thinking of distributed SCM, why choosing GIT over Mercurial or over
Bazaar
?
For one of the biggest reasons is that there is an extremely good
implementation in Java. The other proof point is that this is
successfully being
he right project directory?
LieGrue,
strub
--- Brian Fox schrieb am Fr, 24.4.2009:
> Von: Brian Fox
> Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> An: dev@maven.apache.org
> Datum: Freitag, 24. April 2009, 1:21
>
>
> Mark Struberg wrote:
> > tec
We have already a long thread with lot of things so I won't repeat some
questions.
I'm +0 to move to GIT but -1 to go outside of the Apache infrastucture.
Emmanuel
On Thu, Apr 23, 2009 at 7:00 PM, Jason van Zyl wrote:
> Hi,
>
> Maven was the first project at Apache to use JIRA and though there
Hi folks,
Thinking of distributed SCM, why choosing GIT over Mercurial or over Bazaar
?
They use GIT: http://git-scm.com/ (linux kernel)
They use Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial(openJDK)
They use Bazaar: http://bazaar-vcs.org/WhoUsesBzr (MySQL)
N
Here is a more complete summary of why I think GIT, and more
specifically JGIT is the best thing going for the SCM:
http://www.sonatype.com/people/2009/04/git-the-sweetest-scm-around/
On 23-Apr-09, at 10:00 AM, Jason van Zyl wrote:
Hi,
Maven was the first project at Apache to use JIRA and t
; 2009/4/24 Mark Struberg
>
> >
> > answers inside
> >
> > --- Daniel Kulp schrieb am Fr, 24.4.2009:
> >
> > > Von: Daniel Kulp
> > > Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> > > An: dev@maven.apache.org
> > >
Struberg
>
> answers inside
>
> --- Daniel Kulp schrieb am Fr, 24.4.2009:
>
> > Von: Daniel Kulp
> > Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> > An: dev@maven.apache.org
> > CC: "Mark Struberg"
> > Datum: Freitag, 24. April 2009
answers inside
--- Daniel Kulp schrieb am Fr, 24.4.2009:
> Von: Daniel Kulp
> Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> An: dev@maven.apache.org
> CC: "Mark Struberg"
> Datum: Freitag, 24. April 2009, 2:51
> On Thu April 23 2009 5:46
2009/4/24 Brian Fox
>
>
> Mark Struberg wrote:
>
>> technically there is no git repo which is 'better' than the other. This
>> hierarchy is an orga one.
>> If you can pull from my repo and from Jasons, from whom will you pull your
>> master mainly? Bet you will pull from Jasons. And I also bet al
On 23-Apr-09, at 7:50 PM, Wendy Smoak wrote:
On Thu, Apr 23, 2009 at 10:00 AM, Jason van Zyl
wrote:
Maven was the first project at Apache to use JIRA and though there
was a
great deal of concern/noise about using JIRA it ultimately proved
to be a
decent system and now lots of projects
On 23-Apr-09, at 6:17 PM, Brett Porter wrote:
There are points on either side of this for me. In summary, I'm in
favour of greater exploration of using GIT, but not a wholesale
switch today.
On 24/04/2009, at 3:00 AM, Jason van Zyl wrote:
I'd be happy if everyone here wanted
On Thu, Apr 23, 2009 at 10:00 AM, Jason van Zyl wrote:
> Maven was the first project at Apache to use JIRA and though there was a
> great deal of concern/noise about using JIRA it ultimately proved to be a
> decent system and now lots of projects are using JIRA.
>
> I'm not particularly intereste
On 23-Apr-09, at 5:33 PM, Daniel Kulp wrote:
Personally, I'm +0 on the idea moving to git.I really don't care
one way
or the other if its svn or git.
However, I'm -1 to anything that involves pulling the code outside
of the ASF
unless it would get the "blessing" from infrastructure a
There are points on either side of this for me. In summary, I'm in
favour of greater exploration of using GIT, but not a wholesale switch
today.
On 24/04/2009, at 3:00 AM, Jason van Zyl wrote:
I'd be happy if everyone here wanted to use GIT but I do believe
that I have a bet
2) On a more serious note: this is EXACTLY the issue. Jason is no more
special than I am or anyone else on the Maven PMC. That is why there is a
centralized storage for the repo. Anyone on the PMC (actually, any
committer) MUST have access to entire repo for the project and be able to do
rrell Donkin schrieb am Do,
23.4.2009:
> > Von: Robert Burrell Donkin
> > Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> > An: "Maven Developers List"
> > Datum: Donnerstag, 23. April 2009, 23:27
> > On Thu, Apr 23, 2009 at 6:33 PM, Mark
> &
Personally, I'm +0 on the idea moving to git.I really don't care one way
or the other if its svn or git.
However, I'm -1 to anything that involves pulling the code outside of the ASF
unless it would get the "blessing" from infrastructure and/or the board. If
you want to invest some time/
I have two concerns:
1. Is GIT firewall friendly? At work I could never get to the CVS
repository because my employer's firewall pretty much only allows http
traffic. GIT would need to support that.
2. Is this OK with infra? Last I checked all Apache software had to be
under subversion.
No
o merge radical
contributions into the Maven documentation set.
On Thu, Apr 23, 2009 at 4:48 PM, Vincent Siveton
wrote:
Hi,
GIT is already proposed by infrastructure in read only mode
http://git.apache.org/
Using GIT in write mode sounds like a normal step.
Does Maven SCM support *fully* GIT? I thin
http://git.apache.org/
> Using GIT in write mode sounds like a normal step.
>
> Does Maven SCM support *fully* GIT? I think specially for some plugins
> like the release plugin
>
> Cheers,
>
> Vincent
>
>
> 2009/4/23 Jason van Zyl :
> > Hi,
> >
> >
Mark Struberg wrote:
technically there is no git repo which is 'better' than the other.
This hierarchy is an orga one.
If you can pull from my repo and from Jasons, from whom will you pull your
master mainly? Bet you will pull from Jasons. And I also bet all contributors
will try to get th
Hi Vincent!
> http://git.apache.org/
> Using GIT in write mode sounds like a normal step.
These are only git mirrors of our SVN and not intended to push to them but to
use dcommit.
So this is cool for quickly download/going offline with the whole project
history but not enough fo
Hi,
GIT is already proposed by infrastructure in read only mode
http://git.apache.org/
Using GIT in write mode sounds like a normal step.
Does Maven SCM support *fully* GIT? I think specially for some plugins
like the release plugin
Cheers,
Vincent
2009/4/23 Jason van Zyl :
> Hi,
>
&
nges being pulled by Jason and published in his repo
at the end of the day.
LieGrue,
strub
--- Robert Burrell Donkin schrieb am Do,
23.4.2009:
> Von: Robert Burrell Donkin
> Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> An: "Maven Developers List"
> Datum
tics:
> Basically the location of the repo is just wurscht! It doesn't make any
> difference, since any repo is simply a clone of each other.
how is the code provenance control going to work using GIT?
- robert
-
To u
1 - 100 of 132 matches
Mail list logo
