You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Eric Evans <ee...@rackspace.com> on 2009/04/17 22:48:16 UTC

Attaching patches to Jira

jbellis pointed me in the direction of a script[1] which can format one
or more git changesets into a patch series and post them as attachments
to Jira.

[1] http://github.com/dreiss/git-jira-attacher/tree/master

For anyone who is working locally with git, this script could be a real
life saver, but there is a problem that I am afraid might be a
show-stopper.

When you are creating an attachment in the web interface, there is a
radio box to tick in order to grant license to the ASF for inclusion. I
can't see any way to do the equivalent using the SOAP interface (unless
it's a custom field which I'm not authorized to view).

Does any know of a way to attach a file to Apache's JIRA with the
licensing bit set? If this isn't doable, does anyone know if sending in
a signed CLA[2] would be enough to exempt contributors from setting the
attachment flag?

[2] http://www.apache.org/licenses/icla.txt

-- 
Eric Evans
eevans@rackspace.com


Re: Attaching patches to Jira

Posted by Eric Evans <ee...@rackspace.com>.
On Fri, 2009-04-17 at 15:48 -0500, Eric Evans wrote:
> Does any know of a way to attach a file to Apache's JIRA with the
> licensing bit set? If this isn't doable, does anyone know if sending in
> a signed CLA[2] would be enough to exempt contributors from setting the
> attachment flag?
> 
> [2] http://www.apache.org/licenses/icla.txt

I guess I was hoping that at the very least, one of the ASF folks could
sound off on this. Are they not subscribed to this list?

-- 
Eric Evans
eevans@rackspace.com


Re: read repairs for get_columns_since

Posted by Jonathan Ellis <jb...@gmail.com>.
Here is another reason to have a repair flag:

Currently read repair is all or nothing.  (There is an undocumented
DoConsistencyChecksBoolean that turns it on or off globally.  The
default is true.)   Assuming that no RR at all is unacceptable, having
it on all the time causes inefficiency when there are more reads than
writes, since RR sends a read command to each replica.

If you're doing a weak read (the only kind exposed in thrift right
now) where writes are relatively rare then it would allow more
requests per node to only do a RR every M requests.  Then you would be
closer to one read op per request instead of N reads where N is the
number of replicas.

-Jonathan

On Tue, Apr 21, 2009 at 4:28 PM, Jun Rao <ju...@almaden.ibm.com> wrote:
>
> The difference is that for get_slice/get_columns_since, their results are
> affected by every update. For get_column, the result only changes when the
> asked for column is updated.
>
> Jun
> IBM Almaden Research Center
> K55/B1, 650 Harry Road, San Jose, CA  95120-6099
>
> junrao@almaden.ibm.com
>
>
> Jonathan Ellis <jb...@gmail.com> wrote on 04/20/2009 01:35:34 PM:
>
>>
>> It seems to me that you could come up with workloads that would cause
>> similar behavior for get_slice as well, or even get_column.  No?
>>
>> In my mind it would be reasonable to add a read_repair boolean flag to
>> all the read API calls.  (But I'm not volunteering to implement that,
>> since I don't think we're going to need it in the near future. :)
>>
>> -Jonathan
>>
>> On Mon, Apr 20, 2009 at 1:54 PM, Jun Rao <ju...@almaden.ibm.com> wrote:
>> >
>> > I am wondering is we should really be doing read repairs for
>> > get_columns_since. If there is continuous ongoing updates, it's very
> likely
>> > that two consecutive get_columns_since calls will never return the same
>> > result, even when there is no real data loss. It seems that read repair
> for
>> > this function could add a lot of unnecessary overheads.
>> >
>> > Jun
>> > IBM Almaden Research Center
>> > K55/B1, 650 Harry Road, San Jose, CA  95120-6099
>> >
>> > junrao@almaden.ibm.com

Re: read repairs for get_columns_since

Posted by Jun Rao <ju...@almaden.ibm.com>.
The difference is that for get_slice/get_columns_since, their results are
affected by every update. For get_column, the result only changes when the
asked for column is updated.

Jun
IBM Almaden Research Center
K55/B1, 650 Harry Road, San Jose, CA  95120-6099

junrao@almaden.ibm.com


Jonathan Ellis <jb...@gmail.com> wrote on 04/20/2009 01:35:34 PM:

>
> It seems to me that you could come up with workloads that would cause
> similar behavior for get_slice as well, or even get_column.  No?
>
> In my mind it would be reasonable to add a read_repair boolean flag to
> all the read API calls.  (But I'm not volunteering to implement that,
> since I don't think we're going to need it in the near future. :)
>
> -Jonathan
>
> On Mon, Apr 20, 2009 at 1:54 PM, Jun Rao <ju...@almaden.ibm.com> wrote:
> >
> > I am wondering is we should really be doing read repairs for
> > get_columns_since. If there is continuous ongoing updates, it's very
likely
> > that two consecutive get_columns_since calls will never return the same
> > result, even when there is no real data loss. It seems that read repair
for
> > this function could add a lot of unnecessary overheads.
> >
> > Jun
> > IBM Almaden Research Center
> > K55/B1, 650 Harry Road, San Jose, CA  95120-6099
> >
> > junrao@almaden.ibm.com

Re: read repairs for get_columns_since

Posted by Jonathan Ellis <jb...@gmail.com>.
It seems to me that you could come up with workloads that would cause
similar behavior for get_slice as well, or even get_column.  No?

In my mind it would be reasonable to add a read_repair boolean flag to
all the read API calls.  (But I'm not volunteering to implement that,
since I don't think we're going to need it in the near future. :)

-Jonathan

On Mon, Apr 20, 2009 at 1:54 PM, Jun Rao <ju...@almaden.ibm.com> wrote:
>
> I am wondering is we should really be doing read repairs for
> get_columns_since. If there is continuous ongoing updates, it's very likely
> that two consecutive get_columns_since calls will never return the same
> result, even when there is no real data loss. It seems that read repair for
> this function could add a lot of unnecessary overheads.
>
> Jun
> IBM Almaden Research Center
> K55/B1, 650 Harry Road, San Jose, CA  95120-6099
>
> junrao@almaden.ibm.com

read repairs for get_columns_since

Posted by Jun Rao <ju...@almaden.ibm.com>.
I am wondering is we should really be doing read repairs for
get_columns_since. If there is continuous ongoing updates, it's very likely
that two consecutive get_columns_since calls will never return the same
result, even when there is no real data loss. It seems that read repair for
this function could add a lot of unnecessary overheads.

Jun
IBM Almaden Research Center
K55/B1, 650 Harry Road, San Jose, CA  95120-6099

junrao@almaden.ibm.com