Adam, just added your account to the myfaces-developers group. You should
have the appropriate permissions now.
John, I added you as well. Please confirm, that your Jira account is
jfallows. Just to be sure, because there exists another John Fallows
account with a different username.
Manfred
On
Just changed the sender email to adffaces-issues at
incubator.apache.orgadffaces-issues@incubator.apache.orgin Jira. So,
Jira notifications should now have this address as from header.
Hint: To permanently allow an email address on an ezlml list just hit the
reply to all button for the moderator
Omar, Jonas, Matze,
Highway 101 is not far from your office, right? Have you been aware
that 101 brings you directly to Trinidad when driving 300 miles north?
Cool, isn't it?
Apache Incubator = Hwy 101 - it's a long road, but there is a goal!
:-)
Manfred
On 6/8/06, Manfred Geiler [EMAIL
Yes, there is no way to restrict commit privileges within a project. Neither
technical, nor according to the Apache idea.
Sandbox is also the place where committers can apply patches much faster
with less care. So the committers workload should not be to much a problem
IMO.
BTW,
+1 for trinidad
.
Does manual signing with gpg work fine on your machine?
--Manfred
On 2/13/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Matze,
First of all, please do not deploy tomahawk into
.../people.apache.org/builds/myfaces/m2-staging-repository right now.
We are currently preparing core 1.1.5
Yes, IMHO you should build and sign all the stuff, deploy it to a
temporary staging dir and start a vote on those artifacts.
Regards,
Manfred
On 2/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
ok, I think next step is doing a checkout on the tag (1.0.0-inc) and
build the stuff and do
No.
release:perform ends the release process - after the vote!
Just do a mvn clean deploy -Psign-artifacts (after you have checked
that distributionManagement points to the correct staging dir)
--Manfred
On 2/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
so that means doing a
the release:perform after asking the incubator PMC would change this
(IMO)
-M
On 2/13/07, Manfred Geiler [EMAIL PROTECTED] wrote:
No.
release:perform ends the release process - after the vote!
Just do a mvn clean deploy -Psign-artifacts (after you have checked
that distributionManagement points
No, it's nothing with the gpg-plugin.
What you are doing is something like mvn release:perform
-Dpassphrase=, right?
Well, the release:perform does a svn checkout to work folder and then
forks a new mvn deploy process. But: It seems like the command-line
properties are not passed over!
Try a manual scp connect first to add the server fingerprint to your
ssh trusted server list.
--Manfred
On 2/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
one more ... now getting this:
[INFO] [deploy:deploy]
altDeploymentRepository = null
The authenticity of host 'people.apache.org'
[ ] +1 (Binding) for PPMC members only
[x] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released,
and why..
Wish for future releases:
Add
Just confirmed the issue.
Regards,
Manfred
On 4/28/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Ah, ok. Thanks for pointing out the practical implications of infra
needing validate the request in JIRA. I hadn't considered that.
On 4/28/07, Martin van den Bemt [EMAIL PROTECTED] wrote:
12 matches
Mail list logo
