Thanks Jeff - I have an initial rough draft of basically exactly what
you've enumerated above from starting to formally ramp back up last week
I'll tidy up and try to get out here Monday.
And thanks everyone for the discussion. This is Hard Stuff; a huge part of
the Apache Way (at least on our
Back to the original question in the thread - I think a critical pass through
open issues is warranted -
What hasn’t been triaged?
What is slated for 4.0 but unassigned ?
What is patch available but needs more engineering ?
What is ready to commit and uncommitted?
You’ve got the context to
I don't think there was anything wrong with the linked thread.
On 11/01/2020, 18:19, "Sankalp Kohli" wrote:
Words are open to interpretation but I do not see anyone telling anyone
anything but proposing it in this and other thread. AFAIK, people who tell even
accidentally don’t start a
Words are open to interpretation but I do not see anyone telling anyone
anything but proposing it in this and other thread. AFAIK, people who tell even
accidentally don’t start a discussion thread or ask for feedback before they do
things.
The thread on video calls was a discussion and no one
I've tried to make my concerns as clear as possible: there's a difference
between proposing and telling.
People who have de-facto power (through the resources they control) are able to
_tell_ other people that things are a certain way. They may easily do it
accidentally. So they must be
The Agenda is public and everyone will contribute to it. Anyone can attend the
meeting. Anyone can propose an alternate time. How is it private ?
What else do you suggest ?
> On Jan 11, 2020, at 9:31 AM, Benedict Elliott Smith
> wrote:
>
> I think everyone is missing my point, and the
I think everyone is missing my point, and the reason for it. I am super
focused on not repeating the situation that happened before. So I am super
keen that everyone is focused on doing everything as properly as possible.
Telling the community: we've privately decided this important
Here is the mail thread where we discussed this. It also has agreement that
we will discuss things on mailing list and no decision till it happens on
mailing list. Hope this clears things up when you read the thread.
On 1/11/20 10:02 AM, Mick Semb Wever wrote:
This brings up the issue that links to builds on tickets should
ideally refer to information that is permanent. This could be
done by configuring builds to keep status and logs but not the
built artefacts (and/or adding bigger disks). I will now
On 1/11/20 9:17 AM, Michael Shuler wrote:
On 1/11/20 4:48 AM, Mick Semb Wever wrote:
This brings up the issue that links to builds on tickets should
ideally refer to information that is permanent.
This could be done by configuring builds to keep status and logs but
not the built
> > This brings up the issue that links to builds on tickets should ideally
> > refer to information that is permanent.
> > This could be done by configuring builds to keep status and logs but not
> > the built artefacts (and/or adding bigger disks). I will now update the
> > builds to
On 1/11/20 4:48 AM, Mick Semb Wever wrote:
This brings up the issue that links to builds on tickets should ideally refer
to information that is permanent.
This could be done by configuring builds to keep status and logs but not the
built artefacts (and/or adding bigger disks). I will now
I recall this being discussed at ApacheCon, and I recall the idea seemed very
much for a semi-formal regular project meeting, in which project business would
be discussed on a pre-agreed agenda. Some ground rules were even suggested at
ApacheCon, such as ensuring the meetings occur in rotating
> I would still be in favour of adding the post-commit CI feedback
> integration, though in a shorter format that what Hadoop does. It's a
> nice finalising comment on the ticket. Maybe we can come back to this
> once we stabilise Jenkins a bit more and ask what everyone thinks? (For
>
14 matches
Mail list logo
