Just wanted to point out that in jclouds we only use GitHub for the code
reviews. We don't follow the entire pull request workflow and we actually
use the ASF repos as our primary source of code.
Contributors submit pull requests and code review happen in GitHub. Once
the patch is ready to be merg
being fixed and all documentation is being made more accessible.
We're working on it, our apologies for the confusion the old links may
cause!
Ignasi
On 4 February 2014 09:08, Bertrand Delacretaz wrote:
> On Tue, Feb 4, 2014 at 8:13 AM, Ignasi Barrera wrote:
> > ...Just wanted t
Good to see Brooklyn here. Look forward to seeing the project progress!
El 25/04/2014 08:39, "Duncan Johnston Watt" <
duncan.johnstonw...@cloudsoftcorp.com> escribió:
> Joe
>
> Thanks. Much appreciated.
>
> Please can you add yourself to the wiki proposal before Chip closes this
> thread and moves
Hi,
I'd like to join the IPMC to help mentor the SkyWalking project. I am
already a member of the ComDev PMC and would like to get involved in the
Incubator to get a deeper insight into its duties and how we can help
communities there. I'd like to initially help mentor the SkyWalking project
but l
+1 Accept Zipkin
On Mon, 27 Aug 2018 at 13:30, Willem Jiang wrote:
>
> +1 (binding)
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Mon, Aug 27, 2018 at 11:14 AM Mick Semb Wever wrote:
>
> > After a brief discussion¹ I would like to call a VOTE to accept Zipkin
> > into the A
Hi,
I am helping mentor SkyWalking and need permissions to edit the
incubator reports (https://wiki.apache.org/incubator/September2018).
Would someone please enable my account "IgnasiBarrera"?
Thanks,
I.
-
To unsubscribe, e-ma
Thanks for the detailed review, Justin. It is really appreciated. As I
commented in the PPMC vote:
"The README still contains a broken in the "Compiling" section, but I
wouldn't consider it a blocker for the release. The document is in the
source release and also properly linked from the main "Eng
That's why I meant when I said finding the build instructions was
trivial enough that I thought it should not block a release.
The README contains a clear link to the Documentation (which is a link
to a local file), and that file is a very comprehensive index with
direct links to architecture, tes
source release and also properly linked from the main "English
Document" page (linked from the README too) and it is trivial to
find.On Sun, 9 Sep 2018 at 19:19, Ignasi Barrera
wrote:
>
> That's why I meant when I said finding the build instructions was
> trivial enough that
+1
I checked:
* SHA 512 files present and valid
* Signatures are valid
* The expanded source archive builds and passes tests
* There are proper build instructions directly linked from the README.md
* Release contents match the release tag
* LICENSE and NOTICE files are present and correct
* Incub
+1
Checked:
* SHA 512 files present and valid
* Signatures are valid
* The expanded source archive builds and passes tests
* Release contents match the release tag
* LICENSE and NOTICE files are present and correct
* DISCLAIMER is present and correct
* No unexpected binaries bundled in the source
In the particular case of the "MavenWrapperDownloader.java" file, I would
say it is OK not to mention it in the LICENSE/NOTICE files, as per the
existing policy [1]. The project does not contain a NOTICE file, so there
is nothing to propagate there, and policy says that if the bundled
dependency is
On Thu, 14 Feb 2019 at 09:15, Ignasi Barrera wrote:
> In the particular case of the "MavenWrapperDownloader.java" file, I would
> say it is OK not to mention it in the LICENSE/NOTICE files, as per the
> existing policy [1]. The project does not contain a NOTICE file, so th
13 matches
Mail list logo
