Maybe a crazy idea: If we have a main repository and a Bitbucket
mirror, we could add a hook on every commit to the main repository
that replicates the commits to the mirror.
If someone opens a pull request a reviewer (with commit rights to the
main repository) can review the pull and comment
On 18.03.2015 08:24, Benjamin Gudehus wrote:
I don't know if this
is feasible, sounds like a lot of coordination work, e.g. the people
from Node.js and its fork io.js have some problems with coordination
between both repositories.
Typically, even in the 'friendly fork' scenario, such setups
on with this.
-Florian
Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
Right. If you wanted to revive the unofficial OpenJFX bitbucket
mirror
for your own experiments, that is certainly something you could
do
(subject
On 18.03.2015 06:50, Benjamin Gudehus wrote:
then you have to spend weeks sorting out who contributed to the files
in the pull request
Is it common to have multiple authors for a single pull request?
It's fairly easy to create scenarios with multiple authors:
A forks away, patches, B forks
Ah I see, that's reasonable.
Using patch files sounds like the change sets will be really
scattered. I first thought about an official Bitbucket mirror that
acts as a gate and only accepts small pull requests where every author
identified by his/her email address has accepted the OCA/CLA. There
their forks and pull-requests in JIRA
for
documentation purposes.
It would really be great if we could move on with this.
-Florian
Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
Right. If you wanted to revive the unofficial OpenJFX bitbucket
mirror
for your own
a.m., Florian Brunner wrote:
Hi,
AFAIK there is/ was a mirror of OpenJFX at BitBucket.
I think the URL was https://bitbucket.org/openjfxmirrors, but it's not valid
anymore.
Is there still a mirror of OpenJFX at BitBucket?
A fork/pull-request workflow is state-of-the-art nowadays in software
Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
for your own experiments, that is certainly something you could do
(subject to the GPLv2 + CLASSPATH license terms).
For those patches to then be incorporated into the openjfx repos on
hg.openjdk.java.net they need to go
.
The contributors could link their forks and pull-requests in JIRA for
documentation purposes.
It would really be great if we could move on with this.
-Florian
Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
be great if we could move on with this.
-Florian
Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
Right. If you wanted to revive the unofficial OpenJFX bitbucket
mirror
for your own experiments, that is certainly something you could
do
(subject to the GPLv2 + CLASSPATH license terms
Rushforth:
Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
for your own experiments, that is certainly something you could do
(subject to the GPLv2 + CLASSPATH license terms).
For those patches to then be incorporated into the openjfx repos on
hg.openjdk.java.net they need
to revive the unofficial OpenJFX bitbucket mirror
for your own experiments, that is certainly something you could do
(subject to the GPLv2 + CLASSPATH license terms).
For those patches to then be incorporated into the openjfx repos on
hg.openjdk.java.net they need to go through the existing openjdk
really be great if we could move on with this.
-Florian
Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
for your own experiments, that is certainly something you could do
(subject to the GPLv2 + CLASSPATH
could link their forks and pull-requests in JIRA for
documentation purposes.
It would really be great if we could move on with this.
-Florian
Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
for your own experiments
On 18.03.2015 01:03, Tomas Mikula wrote:
Legal issues could be resolved by requiring a signed OCA before each
pull request is merged.
Or we could simply require changes to come in the way we do now and
avoid having to deal with another set of side issues altogether.
A development model
then you have to spend weeks sorting out who contributed to the files in
the pull request
Is it common to have multiple authors for a single pull request?
how to contact them, if they are covered under the OCA
Google [1] (googlebot), Mozilla [2] (rust-highfive robot) and Microsoft [3]
(msftclas
16 matches
Mail list logo
