One of the reasons why we have maven point to repo.maven.apache.org is such
that if "the worst" happened, and sonatype was no longer providing the
service *and* there were delays transferring the maven.org domains then the
Maven PMC would be able to re-point the domain under our control
immediately
please follow me: @connolly_s
On 9 June 2015 at 23:20, Sally Khudairi wrote:
> Greetings, Apache Committers!
>
> I'm happy to announce that we now administer the @PlanetApache Twitter
> account and will begin to follow individual Twitter accounts of Apache
> Committers there.
>
> If you would li
I have found that chrome is not so good at expiring the cache on https pages
On 13 April 2015 at 23:59, David Crossley wrote:
> Hervé BOUTEMY wrote:
> > ok, I added forrest to projects.json and it is now visible in projects
> list
> > https://projects-new.apache.org/projects.html
>
> Beaut, than
On 19 January 2015 at 09:28, Konstantin Kolinko
wrote:
> 2015-01-19 11:31 GMT+03:00 Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
> > On Monday, January 19, 2015, Benedikt Ritter wrote:
> >
> > I am not against additional views, just let me keep it a
On Monday, January 19, 2015, Benedikt Ritter wrote:
> Hello,
>
> Guys, don't get me wrong, but you're sounding like a bunch of old man
> talking about the good old days, where you did everything on the command
> line. ;-)
> I'm 29 and before Apache, I hadn't heard about mailing lists. It always
>
Ross beat me to the punch
On Sunday, January 18, 2015, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:
> For me any alternative would still have to push everything into my inbox
> where I can use a my preferred tools, each developed and matured over many
> years, to help me proce
I think the key bit here is that releases of Apache projects must have an
associated source release and have been voted on by the PMC making the
release.
If the project you depend on is an independent project, you need to
remember that their -SNAPSHOT build is *not* a release. Therefore you need
i
On Thursday, 13 February 2014, Joseph Schaefer
wrote:
> Change is hard, we aren't a tiny org and we do have an opinion about how
> things should be done. That's all I'll say about the git stuff.
>
> But let's face reality for a moment- Cordova has averaged one release a
> month for the past seve
On 11 February 2014 22:01, Andrea Pescetti wrote:
> Jim Jagielski wrote:
>
>> One reason for the 72hour rule is to ensure that no PMC
>> member feels disenfranchised. ...
>>
>> PMCs are *inclusive*. The processes and procedures are
>> designed to maintain that inclusivity.
>>
>
> This is not 100%
It concerns me that people are knocking a fast release cadence *without
having tried it here*
Q: Is a fast cadence right for every project at ASF?
A: I think not
Q: Is a fast cadence right for the majority of projects at ASF?
A: I suspect not
Q: Is a fast cadence wrong for any project at ASF?
project *wants* to work that way we should find a
way to let them learn the value of taking a break every now and again ;-)
>
> On Feb 10, 2014, at 2:52 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > On Monday, 10 February 2014, Jim Jagielski >
On Monday, 10 February 2014, Jim Jagielski wrote:
> > So, I could ask, what's special about 72 hours?
>
> It was to prevent things from sneaking out during a weekend
So the release vote is scheduled for mid-week so that holiday weekends
won't come into play... Ok you'll have St Patrick's day fa
On 10 February 2014 16:29, Marvin Humphrey wrote:
> On Mon, Feb 10, 2014 at 5:36 AM, Jim Jagielski wrote:
> > A concern is that if the same person is RM, and the vote is always
> > done at the same time (and so the 12 hour window never shifts, time-
> > wise) then the vote will *always* favor th
On 10 February 2014 14:00, Jim Jagielski wrote:
>
> On Feb 10, 2014, at 8:48 AM, Benson Margulies
> wrote:
> >
> > In other words, an automated process can still allow for completely
> > inclusive participation.
> >
>
> I never said that it couldn't. I just wanted everyone to recall
> that inclu
; in the release process would lead me to guess that the opposite
> flow will happen- that surplussed users will stop following dev
> and go back to the user lists. If I'm right, then why
> is this a good and desirable effect for an Apache project?
>
>
>
>
from the votes, maybe that is not the end of the world
> if the next vote is only a week away but it ultimately removes the
> flexibility and inclusiveness that the current 72hr window gives me.
>
>
> Rob
>
>
> On 10/02/2014 08:30, "Stephen Connolly"
> wrote:
&g
On Monday, 10 February 2014, Upayavira wrote:
>
>
> On Sun, Feb 9, 2014, at 06:40 AM, Marvin Humphrey wrote:
> > On Sat, Feb 8, 2014 at 3:26 PM, Stephen Connolly
> > > wrote:
> > > 72h for a vote is not a hard and fast rule (you just need a good
> reason for
But what if the community wants Apache to have such a rapid cadence?
By forcing the community to decamp to GitHub, then what are we saying to
that community? Sorry we may value community over code, but we value
procedure over both?
If that is the answer, then so be it, let's change our mantra fro
I checked and I think my very original post is reply to dev... Somebody on
the board list pulled it back in I suspect.
On Friday, 7 February 2014, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hmm not sure how that happened, board and the "friend" project
(I would personally prefer that entire discussion take place in public.)
>
> Marvin Humphrey
>
> On Fri, Feb 7, 2014 at 3:02 AM, Stephen Connolly
> > wrote:
> > One of the projects I am involved with is the Jenkins project.
>
> >8 snip 8<-
>
--
Sent from my phone
; install the latest version. This helps to find bugs before they are
> released in the LTS version (sometimes it's hard to write tests for
> all envs + variables).
>
> So my +1 (probably not binding :)
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
On 7 February 2014 11:02, Stephen Connolly
wrote:
> One of the projects I am involved with is the Jenkins project. At Jenkins
> we cut a release of Jenkins every wednesday... assuming the test all pass...
> Not every release is as stable as people might desire (the tests don't
>
One of the projects I am involved with is the Jenkins project. At Jenkins
we cut a release of Jenkins every wednesday... assuming the test all pass...
Not every release is as stable as people might desire (the tests don't
catch everything), hence there is the LTS release line, but none the less,
th
23 matches
Mail list logo