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
>
>
