process question.

[Claude Warren <cl...@xenei.com>]

I haven't been around for awhile so I have a process question.
How many reviews are required before code can be merged?

Claude

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

Re: process question.

[Andy Seaborne <an...@apache.org>]

Claude,

For merging to main, we are moving towards "rebase and merge" away from 
"Create a merge commit". Squashing and tidy up is probably better done 
on the PR before the integration into main.

This is for keeping the long term history for main cleaner.

It may make sense to use a merge commit when history should preserve new 
functionality coming in - e.g. something large and significant we'd want 
to record.

Choose which you feel is appropriate but "rebase and merge" does produce 
more noise in the log history.

     Andy

On 23/11/2023 15:22, Bruno Kinoshita wrote:
> I think it depends. Sometimes I approve things that look good to me, but
> you might still want to request an extra review from Andy or Rob as they
> know the code base a lot better.

And this seems to be working.

A review has two aspects

- are there any wider issues? (e.g. it has a new dependency)- "process" 
has been followed
- review the code.

If a PR is ready, and only changes a clearly restricted area of code 
with no changes outside some subtree or small maven module, and passes 
the build - it doesn't bring everything down! - then consider merging it.

In the jargon "RTC", with modest "CTR" if it hangs around too long.
Always RTC would be ideal but we do have to be practical given the 
people-resources available.

There are github actions to run the build on a cloned repo or "mavn 
clean verify" locally.

Anyone - no just committers - can comment on PRs.

CTR = "Commit Then Review"
RTC = "Review Then Commit"


> 
> In the same manner, if you modify the UI and Rob, Andy, or anybody else
> reviews it, I am always happy to be added as a second reviewer for
> UI/JavaScript if needed.
> 
> For the documentation in jena-site, though, pull requests are held back
> until we have the code they talk about released, so that the documentation
> is not ahead of what users are able to use.
> 
> On Thu, 23 Nov 2023 at 13:16, Claude Warren <cl...@xenei.com> wrote:
> 
>> I haven't been around for awhile so I have a process question.
>> How many reviews are required before code can be merged?
>>
>> Claude
>>
>> --
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
> 

Re: UI improvements Was: process question.

[Bruno Kinoshita <br...@gmail.com>]

Thank you Marco!!!

On Thu, 30 Nov 2023, 10:34 Marco Neumann, <ma...@gmail.com> wrote:

> Hi Bruno,
> Ok I will try the github issue approach here. dev@ would be too noisy I'd
> say. BTW well done with the new UI work for fuseki!
>
> Best,
> Marco
>
>
> On Wed, Nov 29, 2023 at 5:17 PM Bruno Kinoshita <br...@gmail.com>
> wrote:
>
> > Hi Marco,
> >
> > For things like this an issue in GitHub (I think we have labels for
> fuseki
> > and/or UI) would work IMO. And I think what you suggest is a good idea!
> >
> > Some time ago we migrated to this JavaScript web application for Fuseki
> and
> > a slightly new UI. Slightly as we intentionally didn't change much of the
> > old behavior. That's so we could give it some time and make sure we
> didn't
> > break any existing features (I think we didn't).
> >
> > Now I think it is a good time to start planning changes like this one, or
> > even bigger ones (have a UI configuration, allow other languages, dark
> > mode, improve the Query panel with tabs or other features, etc.).
> >
> > If you have a small feature like this one I think it is easy to discuss
> > over GitHub. But for bigger things (e.g. replace YASGUI with another
> > component, completely change how we manage datasets, security in UI,
> etc.)
> > then I'd say discussions in the dev@ as Andy pointed are better as not
> > everyone watches the GitHub issues.
> >
> > Cheers,
> >
> > Bruno
> >
> > On Wed, 29 Nov 2023 at 15:30, Marco Neumann <ma...@gmail.com>
> > wrote:
> >
> > > So for example we sometimes work with hundreds of files for uploads via
> > the
> > > fuseki UI.
> > >
> > > While it is great that the users get feedback about the progress of the
> > > upload for each file, one has to scroll down to the last item to
> confirm
> > > that the process is actually finished.
> > >
> > > It would be great to have an indication at the top of the upload page
> > about
> > > the status of the "upload all" process as finished, failed or failed
> with
> > > completion etc.
> > >
> > > Marco
> > >
> > >
> > > On Wed, Nov 29, 2023 at 10:55 AM Andy Seaborne <an...@apache.org>
> wrote:
> > >
> > > > Github issues for feature-scale things.
> > > > Ideally with associated pull request.
> > > >
> > > > General discussions, dev@
> > > >
> > > >      Andy
> > > >
> > > > On 29/11/2023 09:18, Marco Neumann wrote:
> > > > > Bruno,
> > > > > how do you gather input/ideas for UI improvements?
> > > > >
> > > > > Best,
> > > > > Marco
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > ---
> > > Marco Neumann
> > >
> >
>
>
> --
>
>
> ---
> Marco Neumann
>

Re: UI improvements Was: process question.

[Marco Neumann <ma...@gmail.com>]

Hi Bruno,
Ok I will try the github issue approach here. dev@ would be too noisy I'd
say. BTW well done with the new UI work for fuseki!

Best,
Marco


On Wed, Nov 29, 2023 at 5:17 PM Bruno Kinoshita <br...@gmail.com>
wrote:

> Hi Marco,
>
> For things like this an issue in GitHub (I think we have labels for fuseki
> and/or UI) would work IMO. And I think what you suggest is a good idea!
>
> Some time ago we migrated to this JavaScript web application for Fuseki and
> a slightly new UI. Slightly as we intentionally didn't change much of the
> old behavior. That's so we could give it some time and make sure we didn't
> break any existing features (I think we didn't).
>
> Now I think it is a good time to start planning changes like this one, or
> even bigger ones (have a UI configuration, allow other languages, dark
> mode, improve the Query panel with tabs or other features, etc.).
>
> If you have a small feature like this one I think it is easy to discuss
> over GitHub. But for bigger things (e.g. replace YASGUI with another
> component, completely change how we manage datasets, security in UI, etc.)
> then I'd say discussions in the dev@ as Andy pointed are better as not
> everyone watches the GitHub issues.
>
> Cheers,
>
> Bruno
>
> On Wed, 29 Nov 2023 at 15:30, Marco Neumann <ma...@gmail.com>
> wrote:
>
> > So for example we sometimes work with hundreds of files for uploads via
> the
> > fuseki UI.
> >
> > While it is great that the users get feedback about the progress of the
> > upload for each file, one has to scroll down to the last item to confirm
> > that the process is actually finished.
> >
> > It would be great to have an indication at the top of the upload page
> about
> > the status of the "upload all" process as finished, failed or failed with
> > completion etc.
> >
> > Marco
> >
> >
> > On Wed, Nov 29, 2023 at 10:55 AM Andy Seaborne <an...@apache.org> wrote:
> >
> > > Github issues for feature-scale things.
> > > Ideally with associated pull request.
> > >
> > > General discussions, dev@
> > >
> > >      Andy
> > >
> > > On 29/11/2023 09:18, Marco Neumann wrote:
> > > > Bruno,
> > > > how do you gather input/ideas for UI improvements?
> > > >
> > > > Best,
> > > > Marco
> > >
> >
> >
> > --
> >
> >
> > ---
> > Marco Neumann
> >
>


-- 


---
Marco Neumann

Re: UI improvements Was: process question.

[Bruno Kinoshita <br...@gmail.com>]

Hi Marco,

For things like this an issue in GitHub (I think we have labels for fuseki
and/or UI) would work IMO. And I think what you suggest is a good idea!

Some time ago we migrated to this JavaScript web application for Fuseki and
a slightly new UI. Slightly as we intentionally didn't change much of the
old behavior. That's so we could give it some time and make sure we didn't
break any existing features (I think we didn't).

Now I think it is a good time to start planning changes like this one, or
even bigger ones (have a UI configuration, allow other languages, dark
mode, improve the Query panel with tabs or other features, etc.).

If you have a small feature like this one I think it is easy to discuss
over GitHub. But for bigger things (e.g. replace YASGUI with another
component, completely change how we manage datasets, security in UI, etc.)
then I'd say discussions in the dev@ as Andy pointed are better as not
everyone watches the GitHub issues.

Cheers,

Bruno

On Wed, 29 Nov 2023 at 15:30, Marco Neumann <ma...@gmail.com> wrote:

> So for example we sometimes work with hundreds of files for uploads via the
> fuseki UI.
>
> While it is great that the users get feedback about the progress of the
> upload for each file, one has to scroll down to the last item to confirm
> that the process is actually finished.
>
> It would be great to have an indication at the top of the upload page about
> the status of the "upload all" process as finished, failed or failed with
> completion etc.
>
> Marco
>
>
> On Wed, Nov 29, 2023 at 10:55 AM Andy Seaborne <an...@apache.org> wrote:
>
> > Github issues for feature-scale things.
> > Ideally with associated pull request.
> >
> > General discussions, dev@
> >
> >      Andy
> >
> > On 29/11/2023 09:18, Marco Neumann wrote:
> > > Bruno,
> > > how do you gather input/ideas for UI improvements?
> > >
> > > Best,
> > > Marco
> >
>
>
> --
>
>
> ---
> Marco Neumann
>

Re: UI improvements Was: process question.

[Marco Neumann <ma...@gmail.com>]

So for example we sometimes work with hundreds of files for uploads via the
fuseki UI.

While it is great that the users get feedback about the progress of the
upload for each file, one has to scroll down to the last item to confirm
that the process is actually finished.

It would be great to have an indication at the top of the upload page about
the status of the "upload all" process as finished, failed or failed with
completion etc.

Marco


On Wed, Nov 29, 2023 at 10:55 AM Andy Seaborne <an...@apache.org> wrote:

> Github issues for feature-scale things.
> Ideally with associated pull request.
>
> General discussions, dev@
>
>      Andy
>
> On 29/11/2023 09:18, Marco Neumann wrote:
> > Bruno,
> > how do you gather input/ideas for UI improvements?
> >
> > Best,
> > Marco
>


-- 


---
Marco Neumann

Re: UI improvements Was: process question.

[Andy Seaborne <an...@apache.org>]

Github issues for feature-scale things.
Ideally with associated pull request.

General discussions, dev@

     Andy

On 29/11/2023 09:18, Marco Neumann wrote:
> Bruno,
> how do you gather input/ideas for UI improvements?
> 
> Best,
> Marco

UI improvements Was: process question.

[Marco Neumann <ma...@gmail.com>]

Bruno,
how do you gather input/ideas for UI improvements?

Best,
Marco


On Thu, Nov 23, 2023 at 3:22 PM Bruno Kinoshita <br...@gmail.com>
wrote:

> I think it depends. Sometimes I approve things that look good to me, but
> you might still want to request an extra review from Andy or Rob as they
> know the code base a lot better.
>
> In the same manner, if you modify the UI and Rob, Andy, or anybody else
> reviews it, I am always happy to be added as a second reviewer for
> UI/JavaScript if needed.
>
> For the documentation in jena-site, though, pull requests are held back
> until we have the code they talk about released, so that the documentation
> is not ahead of what users are able to use.
>
> On Thu, 23 Nov 2023 at 13:16, Claude Warren <cl...@xenei.com> wrote:
>
> > I haven't been around for awhile so I have a process question.
> > How many reviews are required before code can be merged?
> >
> > Claude
> >
> > --
> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
>


-- 


---
Marco Neumann

Re: process question.

[Bruno Kinoshita <br...@gmail.com>]

I think it depends. Sometimes I approve things that look good to me, but
you might still want to request an extra review from Andy or Rob as they
know the code base a lot better.

In the same manner, if you modify the UI and Rob, Andy, or anybody else
reviews it, I am always happy to be added as a second reviewer for
UI/JavaScript if needed.

For the documentation in jena-site, though, pull requests are held back
until we have the code they talk about released, so that the documentation
is not ahead of what users are able to use.

On Thu, 23 Nov 2023 at 13:16, Claude Warren <cl...@xenei.com> wrote:

> I haven't been around for awhile so I have a process question.
> How many reviews are required before code can be merged?
>
> Claude
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>