I agree with you Alessandro. Makes perfect sense for me, and that would be
more realistic way to handle the issues.

- Jungtaek Lim (HeartSaVioR)

2016년 8월 18일 (목) 오전 11:46, Alessandro Bellina
<abell...@yahoo-inc.com.invalid>님이 작성:

> Just a contributors point of view..
> I think the idea to reclaim jiras that are assigned but without progress
> is a good one. After that is done, in order to not end up in the same
> place, I think after a task gets assigned it needs to be given a due date
> (something sane), and updated periodically if it is a long task (e.g. port
> nimbus). The policy being that if after the due date not meaningful
> progress is made, then the assignment should be given away to someone else
> or put back in the unassigned pile.
> Port/merge issues which are assigned, but don't have "ASF GitHub" watching
> them (so no PR it looks like):
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20in%20(java-migration%2C%20jstorm-merger)%20AND%20assignee%20!%3D%20EMPTY%20and%20watcher%20not%20in%20(%22ASF%20GitHub%20Bot%22)
> I think freezing feature development in master is too extreme. Instead, I
> think that as part of the code review checks, if we see changes to a file
> and it is currently under a port task which isn't past due or stalled, then
> the PR should be held back and submitter informed that the file they are
> modifying is truly being ported. This, in turn, puts the ball back on the
> court of the person doing the porting, as it should, and hopefully gives
> the submitter a due date after which they can PR a ported change. If the
> porting task is stalled, I see no reason why the PR shouldn't be considered
> immediately. That said, something tells me this is hard to implement.
> Thanks,
> Alessandro
>
>
>     On Wednesday, August 17, 2016 8:54 PM, Jungtaek Lim <kabh...@gmail.com>
> wrote:
>
>
>  I'm OK to stop feature dev. for storm-core on 1.x branch. As Taylor said
> that was the original plan, and we broke it.
> We even might need to stop feature development for storm-core on 'master'
> if it touches un-ported files, but it would tend to break so I couldn't
> claim that.
>
> Moreover, I propose unassigning all issues regarding port if pull request
> is not open, and go on with 'no assignee' or 'competitive assignee' for
> porting related issues. We had been set assignee for the issues, and
> assignee holds it even though he/she can't or don't work on that for a long
> time.
>
> Before stopping, I'd like to include STORM-2016
> <https://issues.apache.org/jira/browse/STORM-2016> to 1.x version line.
> (target for 1.1.0)
>
> - This will heavily affect to upcoming storm-sql improvements (I'd say that
> without STORM-2016 we even have very hard time to launch storm-sql runner)
> - This will help avoiding to copy libraries (and its transitive
> dependencies) to extlib directory when it's necessary for only some of
> topologies. Clear example is STORM-1881
> <https://issues.apache.org/jira/browse/STORM-1881>.
> - This will give great flexibility to configure user topology jar and
> submit topology.
>
> Thanks,
> Jungtaek Lim (HeartSaVioR)
>
> 2016년 8월 17일 (수) 오후 11:58, P. Taylor Goetz <ptgo...@gmail.com>님이 작성:
>
> > I agree, and that was the original plan.
> >
> > However, the clojure to java migration stalled for a number of reasons
> > (peoples’ $dayjob responsibilities can change often and affect the amount
> > of time they have to contribute to the project — this is to be expected
> and
> > not considered a problem.). Prior to “feature freezing” the 1.x line, I
> > think we should get 1.1.0 released. In my opinion the only remaining
> issue
> > for the release is a resolution to STORM-2006, particularly adding an
> > interface for aggregated metrics.
> >
> > I don’t have a good feel for how long it will take to get the master
> > branch (aka “2.0”) in a releasable state (again it comes down to
> > contributor $dayjobs, which are largely out of anyone’s control). So I
> > think we should plan on supporting 1.x for a while.
> >
> > -Taylor
> >
> > > On Aug 16, 2016, at 10:40 PM, Harsha Chintalapani <st...@harsha.io>
> > wrote:
> > >
> > > Hi All,
> > >          Currently we are undertaken JStorm merger and ongoing
> migration
> > > of existing Clojure code. I am proposing that we should stop any
> feature
> > > development for 1.x branch so that we can make progress on java
> migration
> > > and get it done before adding any further features. If any one
> interested
> > > adding features they can do so on master for 2.0.
> > >            This will give us time to complete the migration and keeps
> the
> > > core code more or less the same . Adding more code to core makes the
> > > migration that much harder.
> > > We should be ok on adding any connectors or so as that can be
> independent
> > > of core and can be easily added to master.
> > >            What you think?
> > >
> > > Thanks,
> > > Harsha
> >
> >
>
>

Reply via email to