I think the user assignment state could be a reasonable proxy to working-on
for those that want to do that?
On Tue, Jul 3, 2018 at 12:28 PM Andrzej Białecki <
andrzej.biale...@lucidworks.com> wrote:
>
> On 3 Jul 2018, at 17:42, Steve Rowe wrote:
>
> I forgot to mention on this thread that the
> On 3 Jul 2018, at 17:42, Steve Rowe wrote:
>
> I forgot to mention on this thread that the “In Progress” status, and the
> buttons to control that (“Start Progress”/“Stop Progress”) were removed from
> the LUCENE/SOLR workflow because:
>
> a) Leaving the progress buttons caused the patch
Don't use it, so I just ignored it.
On Tue, Jul 3, 2018 at 9:01 AM, Adrien Grand wrote:
> I find the progress status and buttons a bit annoying since I don't use
> them. But I don't want to break someone's workflow if they are using it.
>
>
> Le mar. 3 juil. 2018 à 17:42, Steve Rowe a écrit :
I find the progress status and buttons a bit annoying since I don't use
them. But I don't want to break someone's workflow if they are using it.
Le mar. 3 juil. 2018 à 17:42, Steve Rowe a écrit :
> I forgot to mention on this thread that the “In Progress” status, and the
> buttons to control
I forgot to mention on this thread that the “In Progress” status, and the
buttons to control that (“Start Progress”/“Stop Progress”) were removed from
the LUCENE/SOLR workflow because:
a) Leaving the progress buttons caused the patch review buttons to be hidden;
and
b) I thought the Progress
> On Jun 28, 2018, at 7:48 PM, Steve Rowe wrote:
>
>>> ok and these Lucene Fields, two checkboxes, New and Patch Available... I
>>> just don't think we really use this but I should raise this separately.
>>
>> I think we should remove these. In a chat on Infra Hipchat, Gavin offered
>> to do
The new workflow is now enabled for LUCENE and SOLR JIRA projects.
The new workflow differs in a few respects from my previous summary - see
details inline below:
> On Jun 19, 2018, at 1:53 PM, Steve Rowe wrote:
>
> Summary of the workflow changes:
>
> 1. The “Submit Patch” button will be
Hi Adrien,
Thanks for the review!
In the literal sense, “cancelling patch review” will transition an issue's
status from “Patch Available” to “Open”. Since the Yetus PreCommit-Admin
Jenkins job only queues an issue’s patches to be reviewed when the issue is in
“Patch Available” status, this
Thanks Steve for taking care of it, the proposal makes sense to me. I'm not
100% sure what cancelling patch reviews implies, could you give examples of
when we should do it?
Le mer. 20 juin 2018 à 23:52, Steve Rowe a écrit :
> Hi David,
>
> Thanks for the review!
>
> I agree that it would be
Hi David,
Thanks for the review!
I agree that it would be nice to be able to (re-)enable patch review
independently from uploading a (new) patch. I’ll go mention your idea on
INFRA-16094.
--
Steve
www.lucidworks.com
> On Jun 20, 2018, at 5:30 PM, David Smiley wrote:
>
> +1 Sounds good
+1 Sounds good Steve; thanks for working with Gavin and Infra to improve
our workflow.
It'd be nice if, after cancelling a patch review, I could re-enable it. It
appears the only way to do this is to re-attach the patch? Any way it's a
minor issue. I just did some fooling around on INFRATEST
The LUCENE and SOLR JIRA projects’ workflow was changed to support automatic
patch validation via Apache Yetus[1], but there have been objections to the new
workflow and button labels - see INFRA-16094[2].
Under INFRA-16094, Gavin McDonald has produced a new workflow for LUCENE/SOLR
that
Hi Steve,
thanks for the support.
I spent some time yesterday experimenting and testing, and adding a new
patch to the mentioned Jira issues ( which are already in a "Patch
Available" status) and I definitely saw the jobs being queued by Jenkins (
Hi Alessandro,
Thanks for bringing these issues to light, I didn’t know about them.
I’ve seen patches take up to 18 hours prior to triggering a validation job, but
I’ve never seen one take longer than that.
For both these JIRAs, I suspect that Yetus’s partial/experimental support for
linked
Hi,
I was taking a look to the way a patch is validated automatically in the
Solr Jira,
from the documentation[1] it seems when the patch is submitted an automated
Jenkins job is going to run within 12 hours ( if the naming convention is
respected ):
This is the Jenkins job :
There will be a few false positives for these two JIRA queries (commits
that didn't fully fix the issue) but the three I listed above are there:
Check for Git commit:
project in (SOLR, LUCENE) AND status in (Open) and fixVersion is not empty
and text ~ "in lucene-solr's branch refs/heads/" order
Here are three that I just happened upon and was semi familiar with:
* SOLR-8097
* SOLR-9058
* SOLR-8878
Looks like they just need to be resolved properly and fix the fixVersion.
there might be just as many open issues w/o a fixVersion that warrant equal
> review/edits.
Yea that is probably
: I wasn't suggesting a blanket resolve of issues. There are a few that I
: looked at that should have been resolved and weren't. This would require
: some manual effort.
can you give some examples?
I was reading "resolved" as "FIXED" but if you're talking about issues
that could/should be
> TLDR: I don't think it's worth any time/effort to worry about fixVersion
> for open issues.
>
Thats fair and your explanation makes a lot of sense.
I'm not sure why you think it would be a good idea to blanket resolve
> issues with older fix versions -- that seems to be confusing cause with
>
TLDR: I don't think it's worth any time/effort to worry about fixVersion
for open issues.
: project in (SOLR,LUCENE) and status in (Open) and fixVersion IS NOT EMPTY
:
: Does it make sense that there are so many issues that are open and have a
: fixVersion that is not empty?
Yes, there are
I performed the following JIRA search and found ~955 issues:
project in (SOLR,LUCENE) and status in (Open) and fixVersion IS NOT EMPTY
Does it make sense that there are so many issues that are open and have a
fixVersion that is not empty?
I think these issues fall into a few categories (may
http://jirasearch.mikemccandless.com/search.py?index=jira
Silly yet cool milestone ;)
Mike McCandless
http://blog.mikemccandless.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
On Wed, May 18, 2011 at 10:53 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: just a few words. I disagree here with you hoss IMO the suggestion to
: merge JIRA would help to move us closer together and help close the
: gap between Solr and Lucene. I think we need to start identifying us
On Tue, May 17, 2011 at 9:23 PM, Steven A Rowe sar...@syr.edu wrote:
On 5/17/2011 at 3:02 PM, Chris Hostetter wrote:
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them
I didn't know that it was decided that top-level modules issues go under the
Lucene project. That indeed reduces some of the confusion (as long as users
will adhere to it, but I guess it's also up to us to enforce it).
So Lucene project becomes everything that is not precisely Solr, i.e. not
On Tue, May 17, 2011 at 10:23 PM, Steven A Rowe sar...@syr.edu wrote:
On 5/17/2011 at 3:02 PM, Chris Hostetter wrote:
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them
: I didn't know that it was decided that top-level modules issues go under the
: Lucene project. That indeed reduces some of the confusion (as long as users
: will adhere to it, but I guess it's also up to us to enforce it).
And as noted: moving a Jira issue from SOLR-LUCENE (or vice versa) is
: just a few words. I disagree here with you hoss IMO the suggestion to
: merge JIRA would help to move us closer together and help close the
: gap between Solr and Lucene. I think we need to start identifying us
: with what we work on. It feels like we don't do that today and we
: should work
+1 to Chris.
Even if the code is partially shared and project is the same, the end
products are completely different.
Merging lists/jira will force niche developers/users to manually sift
through heaps of irrelevant emails/issues.
On Thu, May 19, 2011 at 00:53, Chris Hostetter
Hi
Today we have separate JIRA projects for Lucene and Solr. This, IMO, starts
to become confusing and difficult to maintain. I'll explain:
* With modules, we now have components in the Lucene JIRA project for
different modules (some under modules/* some under lucene/contrib/*). Will
we have the
On May 17, 2011, at 2:22 PM, Shai Erera wrote:
Can we merge the two?
+1. Due to history and other possible pain points, I don't know that it's the
right practical idea at the end of the upcoming discussion, but it's certainly
a good idea.
- Mark Miller
lucidimagination.com
Lucene/Solr User
Can we merge the two?
gut reaction says +1, but after thinking about how it would work, i'm +0
Would we just stop accepting new tickets on one system, but still keep
track of both? for how long?
Would we move open issues from SOLR to LUCENE? migrate the comments/history/etc
In the end I
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them distinct -- partly from a pain of migration
standpoint on our end, but also from a user expecations standpoint -- i
think
On 5/17/2011 at 3:02 PM, Chris Hostetter wrote:
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them distinct -- partly from a pain of migration
standpoint on our end, but
34 matches
Mail list logo
