[jira] [Created] (JENA-1793) IRILib.decode does not reverse encoded UTF-8

[Andy Seaborne (Jira)]

Andy Seaborne created JENA-1793:
---

 Summary: IRILib.decode does not reverse encoded UTF-8
 Key: JENA-1793
 URL: https://issues.apache.org/jira/browse/JENA-1793
 Project: Apache Jena
  Issue Type: Improvement
Affects Versions: Jena 3.13.1, Jena 3.12.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne
 Fix For: Jena 3.14.0


{{IRILib.decode}} does not reassemble encoded UTF-8 2+ byte sequences.

It does not reverse {{IRILib.encodeNonASCII}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jena] afs opened a new pull request #648: JENA-1793: Decode %-encoded UTF-8

[GitBox]

afs opened a new pull request #648: JENA-1793: Decode %-encoded UTF-8
URL: https://github.com/apache/jena/pull/648
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

On 05/12/2019 14:12, Andy Seaborne wrote:
Now would be a good time to get this done so we can have dev@ for 
discussions.


Please yes/no/etc and when it settles down I'll run a vote.


Ping?

When going to infra, we then have a definite PMC agreement to point to, 
not some minority or rogue action.


On 19/11/2019 19:55, aj...@apache.org wrote:


Andy, you've given a nice list of potential discussions and others 
have as

well. My meta-question is when do we want to switch to tickets for this
process? I don't want to smother discussion in process, but I find it 
very

hard to follow a multithreaded discussion over email and I much prefer
breaking things out early to more specifics.


Splitting the lists will make it easier. I think we switch to tickets 
when there specific activities.  When sorting what the activities are, 
there is benefit in using dev@ so we can see the interactions more 
clearly. With a quieter dev@, sensible [] should mean anyone can see the 
overall activity.  We can change this if it does not work out.


List proposal:

2 new lists: issues@ (for JIRA) and pr@ (for github traffic).

Reply-to on JIRA becomes a comment (which I think it does at the moment 
- the reply is j...@apache.org)


For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on 
GH so the usual GH controls work for people.  pr@ is more of a safe 
archive.


Using the same names as other projects helps infrequent visitors to 
navigate our lists. "issues" is a common name; there isn't a common name 
for the "pr" that I found - and it's not that common to split out GH. 
(Cassandra have pr@).


If anyone wants to combine issues@and pr@ they can do so with their own 
mail filtering rules.


Routing:

JIRA:

There are bunch of events:

Issue Created
Issue Updated
Issue Assigned
Issue Resolved
Issue Closed
Issue Commented
Issue Comment Edited
Issue Comment Deleted
Issue Reopened
Issue Deleted
Issue Moved

These are all:

     All Watchers
     Current Assignee
     Reporter
     Single Email Address (dev@jena.apache.org)

I suggest that all go to issues@ and, in addition, "Created" goes to dev@

I think PRs are linked to JIRA by the title JENA-. We don't need pr 
discussion on JIRA if we have pr@ but it probably isn't a big deal 
because either it's a PR discussion or JIRA discussion, rarely both.


(but please keep the "^JENA-:" on PRs)

Github: I don't know what's possible.

My ideal is all PR traffic to pr@, and like JIRA, any created PRs 
notices go to dev@.


(There aren't a GH issues for the Apache mirrored projects)

     Andy

On 02/06/2019 13:57, ajs6f wrote:
I like the idea of breaking PR discussions off, but if we're going to 
continue to copy PR comments onto Jira tickets it only makes sense if 
we have separate pr@ and issue@ lists. Also, we would have to stop 
copying them onto dev@ (which I would be fine with).


Ideally, I would like to see ticket _creation_ cc:ed onto dev@, so 
that any interested parties would be aware without having to set up 
notifications in Jira, but other ticket actions not cc:ed. I'm not 
sure if that's possible with our gear, but I'm sure INFRA can tell us.


ajs6f


On May 30, 2019, at 10:42 AM, Andy Seaborne  wrote:

The dev@ list can be dominated by github discussions.

We have feeds from github PRs and JIRA. We could split the list in 
one list per feed to leave the dev@ list for people.


While you can do this with mail client rules, searching using the 
archives isn't easy.


Suggestion:
Add email lists for:

pr@ -- github pull request discussions.
issues@ -- JIRA

I'm not sure how clever we can be - for example, it would be nice for 
dev@ to get an email for the submission of a pull request, then not 
the discussion, but I don't think that is configurable. (It is all 
INFRa consifuration anyway AFAIK).


These names are the ones I have seen other projects use.

Thoughts?
What have you seen work for other projects?

    Andy

Re: [Discuss] Split the dev@ mailing list?

[Claude Warren]

+1  This change seems like it will make my life easier so I am in favor ;)

On Mon, Dec 9, 2019 at 11:48 AM Andy Seaborne  wrote:

>
>
> On 05/12/2019 14:12, Andy Seaborne wrote:
> > Now would be a good time to get this done so we can have dev@ for
> > discussions.
> >
> > Please yes/no/etc and when it settles down I'll run a vote.
>
> Ping?
>
> > When going to infra, we then have a definite PMC agreement to point to,
> > not some minority or rogue action.
> >
> > On 19/11/2019 19:55, aj...@apache.org wrote:
> >>
> >> Andy, you've given a nice list of potential discussions and others
> >> have as
> >> well. My meta-question is when do we want to switch to tickets for this
> >> process? I don't want to smother discussion in process, but I find it
> >> very
> >> hard to follow a multithreaded discussion over email and I much prefer
> >> breaking things out early to more specifics.
> >
> > Splitting the lists will make it easier. I think we switch to tickets
> > when there specific activities.  When sorting what the activities are,
> > there is benefit in using dev@ so we can see the interactions more
> > clearly. With a quieter dev@, sensible [] should mean anyone can see
> the
> > overall activity.  We can change this if it does not work out.
> >
> > List proposal:
> >
> > 2 new lists: issues@ (for JIRA) and pr@ (for github traffic).
> >
> > Reply-to on JIRA becomes a comment (which I think it does at the moment
> > - the reply is j...@apache.org)
> >
> > For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on
> > GH so the usual GH controls work for people.  pr@ is more of a safe
> > archive.
> >
> > Using the same names as other projects helps infrequent visitors to
> > navigate our lists. "issues" is a common name; there isn't a common name
> > for the "pr" that I found - and it's not that common to split out GH.
> > (Cassandra have pr@).
> >
> > If anyone wants to combine issues@and pr@ they can do so with their own
> > mail filtering rules.
> >
> > Routing:
> >
> > JIRA:
> >
> > There are bunch of events:
> >
> > Issue Created
> > Issue Updated
> > Issue Assigned
> > Issue Resolved
> > Issue Closed
> > Issue Commented
> > Issue Comment Edited
> > Issue Comment Deleted
> > Issue Reopened
> > Issue Deleted
> > Issue Moved
> >
> > These are all:
> >
> >  All Watchers
> >  Current Assignee
> >  Reporter
> >  Single Email Address (dev@jena.apache.org)
> >
> > I suggest that all go to issues@ and, in addition, "Created" goes to
> dev@
> >
> > I think PRs are linked to JIRA by the title JENA-. We don't need pr
> > discussion on JIRA if we have pr@ but it probably isn't a big deal
> > because either it's a PR discussion or JIRA discussion, rarely both.
> >
> > (but please keep the "^JENA-:" on PRs)
> >
> > Github: I don't know what's possible.
> >
> > My ideal is all PR traffic to pr@, and like JIRA, any created PRs
> > notices go to dev@.
> >
> > (There aren't a GH issues for the Apache mirrored projects)
> >
> >  Andy
> >
> > On 02/06/2019 13:57, ajs6f wrote:
> >> I like the idea of breaking PR discussions off, but if we're going to
> >> continue to copy PR comments onto Jira tickets it only makes sense if
> >> we have separate pr@ and issue@ lists. Also, we would have to stop
> >> copying them onto dev@ (which I would be fine with).
> >>
> >> Ideally, I would like to see ticket _creation_ cc:ed onto dev@, so
> >> that any interested parties would be aware without having to set up
> >> notifications in Jira, but other ticket actions not cc:ed. I'm not
> >> sure if that's possible with our gear, but I'm sure INFRA can tell us.
> >>
> >> ajs6f
> >>
> >>> On May 30, 2019, at 10:42 AM, Andy Seaborne  wrote:
> >>>
> >>> The dev@ list can be dominated by github discussions.
> >>>
> >>> We have feeds from github PRs and JIRA. We could split the list in
> >>> one list per feed to leave the dev@ list for people.
> >>>
> >>> While you can do this with mail client rules, searching using the
> >>> archives isn't easy.
> >>>
> >>> Suggestion:
> >>> Add email lists for:
> >>>
> >>> pr@ -- github pull request discussions.
> >>> issues@ -- JIRA
> >>>
> >>> I'm not sure how clever we can be - for example, it would be nice for
> >>> dev@ to get an email for the submission of a pull request, then not
> >>> the discussion, but I don't think that is configurable. (It is all
> >>> INFRa consifuration anyway AFAIK).
> >>>
> >>> These names are the ones I have seen other projects use.
> >>>
> >>> Thoughts?
> >>> What have you seen work for other projects?
> >>>
> >>> Andy
> >>>
> >>
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [Discuss] Split the dev@ mailing list?

[ajs6f]

>>> For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on GH 
>>> so the usual GH controls work for people.  pr@ is more of a safe archive.


GH notifications include the ability to reply via email to put a remark in the 
conversation. How will that work with this? IMO, that is important 
functionality that we can't throw away.

Anything that prevents the duplication of messages is good. Right now any 
comment on a PR creates at least three email messages in my inbox, all of which 
are duplicated and of which, only one is formatted usefully. First the useful 
message direct from GH, then a duplicate via copying onto dev@ (I realize it's 
for the record-- that doesn't make it useful or any less annoying), then one or 
more replications from Jira. So to the extent that we get any improvement on 
that from splitting out lists, great.

I wouldn't subscribe to a pr@ list. GH's native service for that kind of 
communication is much better than any email list. But if keeping a separate 
list allows us to keep GH traffic off the main dev@ list and out of Jira, I'm 
+1 to that. Duplicating all PR comments onto the Jira issues has made Jira 
almost unusable for me. I can't page through screen after screen of nested 
email and GH quotes duplicating each other.

On another note, the question I was asking was about how to organize the API 
discussion. This proposal, while interesting in its own right, wouldn't do 
anything to address my concern. Filtering via [] subject components is a 
valuable and powerful technique, but it doesn't actually connect the thread to 
work proposed and it's difficult for many people. I'd rather start tickets for 
API ideas, but I'm willing to try something else, i.e. more list-based 
conversation for some further period.

ajs6f

[GitHub] [jena] afs commented on issue #646: JENA-1785: A newly created node can remain invisible after commit

[GitBox]

afs commented on issue #646: JENA-1785: A newly created node can remain 
invisible after commit
URL: https://github.com/apache/jena/pull/646#issuecomment-563245118
 
 
   Good idea.
   
   If you update the PR, we are ready to put this in.
   
   I'll go and update/clean up the comments once it's in separately.
   
   (The transaction mechanism itself will ensure there is only one write 
transaction.)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] strangepleasures commented on issue #646: JENA-1785: A newly created node can remain invisible after commit

[GitBox]

strangepleasures commented on issue #646: JENA-1785: A newly created node can 
remain invisible after commit
URL: https://github.com/apache/jena/pull/646#issuecomment-563255055
 
 
   Sure


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

On 09/12/2019 13:26, ajs6f wrote:



For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on GH so 
the usual GH controls work for people.  pr@ is more of a safe archive.



GH notifications include the ability to reply via email to put a remark in the 
conversation. How will that work with this? IMO, that is important 
functionality that we can't throw away.


The change means emails go to a different list - we can leave reply-to 
as "GitBox ".


The important point is a less-busy dev@.


Anything that prevents the duplication of messages is good. Right now any 
comment on a PR creates at least three email messages in my inbox, all of which 
are duplicated and of which, only one is formatted usefully. First the useful 
message direct from GH, then a duplicate via copying onto dev@ (I realize it's 
for the record-- that doesn't make it useful or any less annoying), then one or 
more replications from Jira. So to the extent that we get any improvement on 
that from splitting out lists, great.


So can you +1 the discussion now?

Whatever we do, we can fine-tune later when we see how it works in practice.


I wouldn't subscribe to a pr@ list. GH's native service for that kind of 
communication is much better than any email list.


(Though if you subscribe, can't you then choose not to have 
notifications direct?)



But if keeping a separate list allows us to keep GH traffic off the main dev@ 
list and out of Jira, I'm +1 to that. Duplicating all PR comments onto the Jira 
issues has made Jira almost unusable for me. I can't page through screen after 
screen of nested email and GH quotes duplicating each other.


Agreed. (But that's actually separate from splitting the dev@ list.)

I checked and it does not happen in some other projects so it does look 
possible.


Before I go and talk to infra, I do need to show its the PMC wanting to 
make changes.


-


On another note, the question I was asking was about how to organize the API 
discussion. This proposal, while interesting in its own right, wouldn't do 
anything to address my concern. Filtering via [] subject components is a 
valuable and powerful technique, but it doesn't actually connect the thread to 
work proposed and it's difficult for many people. I'd rather start tickets for 
API ideas, but I'm willing to try something else, i.e. more list-based 
conversation for some further period.


I want to get to tickets as soon as possible. At the moment we have some 
ideas and next we can get some agreed general directions.


e.g. new API in addition to a ported existing one?; or changes within 
the existing one?


Tickets work best for getting taking a proposal through the details.  We 
need the proposal first. Otherwise tickets are a record of ideas with 
unclear commitment to progress.  Too many tickets dilutes discussion.


You (ajs6f) put forward some general ideas (Nov 21) in other Model APIs 
and SPARQL - how about moving those into some thing more concrete , not 
necessary complete (!), so we can see where it leads to?


Andy



ajs6f

Re: [Discuss] Split the dev@ mailing list?

[ajs6f]

> On Dec 9, 2019, at 10:01 AM, Andy Seaborne  wrote:
> The important point is a less-busy dev@.

Well, I want the right discussion on dev@, not just less discussion. Now that I 
go back and look over the recent archives, it's not clear to me at all that if 
we drop all the duplication we are now getting because of Jira-GH-dev 
reflection that dev@ is actually too busy.

> So can you +1 the discussion now

Not yet, because it is not clear to me that this is the minimal improvement. 
(see below)

> Whatever we do, we can fine-tune later when we see how it works in practice.
> 
>> I wouldn't subscribe to a pr@ list. GH's native service for that kind of 
>> communication is much better than any email list.
> (Though if you subscribe, can't you then choose not to have notifications 
> direct?)

I'm not sure why I would want to use a clunky and less-functional (no reply-to 
to comment on PR, non-formatting-aware) email list instead of the more powerful 
_and_ more pleasant GH system. No offense meant to INFRA; they are amazing 
people who often accomplish more in an hour than I often do in a day, but a 
mailing list is no substitute for the sophisticated integration that GH has 
done for email notifications and PRs.

> Agreed. (But that's actually separate from splitting the dev@ list.)
> I checked and it does not happen in some other projects so it does look 
> possible.
> Before I go and talk to infra, I do need to show its the PMC wanting to make 
> changes.

That (getting traffic off Jira and thereby lowering the _duplicated_ traffic to 
dec@) is actually the major change that interests me. I am ready to +1 a change 
that reduces the duplication without doing anything else more then necessary. 
Are you willing to start with a smaller proposal?

1. Turn off auto-mirroring of all PR comments (which now starts once a ticket 
is mentioned) from GH to Jira. Perhaps it could be manually triggered 
per-comment by mentioning the ticket, or some other more "throttled" way, but 
of course we need to talk to INFRA to see what is possible.

and

2. Put PR comments on a separate pr@ list to record them.

I suspect that will reduce the dev@ traffic enough that we may not have to do 
anything else. No more PR comment ping-pong might mean no new issues@ list.

> I want to get to tickets as soon as possible. At the moment we have some 
> ideas and next we can get some agreed general directions.
> e.g. new API in addition to a ported existing one?; or changes within the 
> existing one?
> Tickets work best for getting taking a proposal through the details.  We need 
> the proposal first. Otherwise tickets are a record of ideas with unclear 
> commitment to progress.  Too many tickets dilutes discussion

I think our confusion is exactly over what a "proposal" is. From my POV, we 
already have bunch of proposals, just at different stages of detail. (see below 
re: concreteness)

As for the issue you specifically give as an example-- I'm a bit surprised. I 
had understood us to be specifically talking about a new API. I am much less 
interested in evolving the old one radically. To be clear, I don't mean that I 
want to throw it away or anything insane like that, just that in the new 
proposal space we have no reason to worry about backward compatibility. Of 
course we'll want to start abstractly with the current API because it is 
successful and encodes a lot of hard-earnt experience. But it's a new API that 
we are talking about in my mind.

All that having been said, I'm not able to step up with a bunch of volunteer 
hours right now ($job is becoming progressively less interested in semweb and 
less willing to allocate time for suchlike), so if the community feels that a 
stark new API is too ambitious, fair enough.

> You (ajs6f) put forward some general ideas (Nov 21) in other Model APIs and 
> SPARQL - how about moving those into some thing more concrete , not necessary 
> complete (!), so we can see where it leads to?

I don't understand what you want to see here before filing a ticket. Can you 
point at an example that is "more concrete, [but] not necessary complete" so I 
can get the sense of it? That would really help me.

Adam

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

On 09/12/2019 16:26, ajs6f wrote:

I'm not sure why I would want to use a clunky and less-functional (no reply-to 
to comment on PR, non-formatting-aware) email list instead of the more 
powerful_and_  more pleasant GH system.


No one is asking you to.
It is not either-or.

GH tools remain untouched as they are today.
>> PR discussion is done on GH

> any comment on a PR creates at least three email messages in my inbox,

One of the copies, the useful message, you get is direct from GH, not 
via ASF (assuming you have GH notifications on)


1. Turn off auto-mirroring of all PR comments (which now starts once a ticket is mentioned) from GH to Jira. 


Yes
>> all PR traffic to pr@

>2. Put PR comments on a separate pr@ list to record them.

Yes
>> all PR [email] traffic to pr@


The only difference here is whether JIRA goes to issues@.
Anyone can combine their email into one folder (as they can separate it 
today). The difference is really on the archives.


The one thing we still JIRA for because there isn't "issues" on GH
(and they are weak as a long term record IMO).

Andy