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
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
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
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 with our com
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
I'm talking with the jgit guys to see about adapting the git archive
functionality to implement an effective export that we can use from the
release plugin. Mark, it looks like the git provider is already setup to
easily integrate an alternate implementation so I think this won't be
hard once t
will that not remove the release.properties file too?
2009/4/25 Antony Stubbs
>
> not true!
>
> git reset --hard
> git clean -f
> git checkout tag
>
> will ensure an exact match with the tag/branch.
>
>
> struberg wrote:
> >
> >
> >> Do we really need to do a clean checkout from the tag?
> >
> >
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
not true!
git reset --hard
git clean -f
git checkout tag
will ensure an exact match with the tag/branch.
struberg wrote:
>
>
>> Do we really need to do a clean checkout from the tag?
>
> I'd strongly recommend it!
>
> The main problems here are files which aren't checked in or ignored but
There are some fundamental ways in which git works vs Mercurial that make it
better - i.e. changesets vs snapshots, multiple branches in 1 repo (in hg
last time i looked you have to create a new copy to checkout a different
branch) and others...
Raphaël wrote:
>
> Hi folks,
>
> Thinking of dis
Grok GitX - it's awesomeness for Git's level atm :)
http://gitx.frim.nl/seeit.html
I've been using it since September, and git since the beginning of last year
and it's the nicest gui i've seen yet - mind you i havent' played with
idea's stuff yet.
Arnaud HERITIER wrote:
>
> +0I never used GI
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 to use GIT
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 better chance of
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
Agreed 100%, it applies across the board. We have two hurdles, one easy,
one not so easy:
1. fix the release plugin / scm provider.
2. convince infra to host a rw git repo.
Tim O'Brien wrote:
I think DVCS would benefit Maven doc. Someone (not a commiter) could clone
the site, fix it, contribu
I think DVCS would benefit Maven doc. Someone (not a commiter) could clone
the site, fix it, contribute it back without having to jump through the JIRA
+ patch + "convince a committer to pay attention" hoop. The main
difference here is that Git makes it really easy to merge in changes and
select
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
cent Siveton
> Betreff: Re: Using GIT as the canonical repository for Maven 3.x
> An: "Maven Developers List"
> Datum: Donnerstag, 23. April 2009, 23:48
> Hi,
>
> GIT is already proposed by infrastructure in read only
> mode
> http://git.apache.org/
> Using GIT i
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,
>
> Maven wa
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
On Thu, Apr 23, 2009 at 6:33 PM, Mark Struberg wrote:
>
> +1 for moving to git.
>
> Jukka already mirrors a lot of projets on GitHub and there is already a
> git.apache.org domain too (not sure where this leads too).
>
> Jason is already convinced, but for all other sceptics:
> Basically the loca
+0I never used GIT but I'm hearing a lot of good things about it and it is
already used by many opensources projects.
I would prefer to not have another drama with infra team if possible.
Perhaps we could help them to set it up if necessary ?
If you have tools for GIT on MacOS, do not hesitate to s
On the release plugin I believe John Smart has that working. And
having our release toolchain tested before switching is a completely
reasonable criterion.
That's my primary concern, that the tools support it, or we experiment
first to find out _how_ they work. It seems like from the maven
On 23-Apr-09, at 11:13 AM, John Casey wrote:
Sounds like an interesting idea, though it does bring up the
question of what lives at the ASF if not the project source code.
Having said that, I understand the reasons for using an external
hosting service.
In any case, I've used Git a little
Sounds like an interesting idea, though it does bring up the question of
what lives at the ASF if not the project source code. Having said that,
I understand the reasons for using an external hosting service.
In any case, I've used Git a little bit for utility projects and to
check out other o
I would like to start it with Maven 3.x only because I would be
willing to put in the effort to maintain it, find resources to
maintain it and support users.
I can't speak for everyone, but if we wanted to move everything to GIT
I would be in favor of that.
I think we basically decide whe
I'm fine with moving to Git. When you say it will start with Maven 3.x, what
does that include? Will all the trunks switch over or just components/trunk to
start with?
Jason van Zyl wrote:
Hi,
Maven was the first project at Apache to use JIRA and though there was a
great deal of concern/no
Excellent. I do not have a long history with Git but from the projects I
used I'm always annoyed when I have to the projects I develop using SVN. So,
if my vote counts anyway I'm +1. We started using it for OI4J and everyone
getting accustom is loving it. Soon, I hope, all OPS4J projects will be on
You should google for egit...it's only in 0.3, IIRC, but seems to
work relatively well for the basics of commit, update, add, remove, etc.
-john
On Nov 13, 2007, at 9:15 AM, Paul Gier wrote:
Jason van Zyl wrote:
On 12 Nov 07, at 4:21 PM 12 Nov 07, Mark Struberg wrote:
--- Johan Kindgren <[
On 13 Nov 07, at 9:15 AM 13 Nov 07, Paul Gier wrote:
Jason van Zyl wrote:
On 12 Nov 07, at 4:21 PM 12 Nov 07, Mark Struberg wrote:
--- Johan Kindgren <[EMAIL PROTECTED]> schrieb:
Maybe it's better to make things easier for the
committers? I've been following this list for a couple of months,
1 - 100 of 118 matches
Mail list logo
