Backlog - Reordered Top->Down

[André Santi Oliveira]

Things which were in the backlog were organized (top->down) using criteria:

  - Fix Version(s)
  - Priority
  - Type


If you don't agree with the order of some things which are there, feel free
to move around but I would like to understand the why to myself be able to
organize better next time. We have a lot of things "not tagged" which I put
on the bottom of the backlog, but it does not means are less important.
just means I was not able to classify still.

I still need to understand how do you classify things in terms of versions.
In my head I have the workflow which is things are being done then we tag
to say "it will be delivered in this version for sure", but it's just a
detail for now as I said I'm still understanding the whole process and how
do you work.


Cheers,
André

Re: Organize JIRA Board

[André Santi Oliveira]

Hi,

I've some questions...

- Are sprints created based on what? release, month, another thing?
- Epics like 0.13.0 RELEASE are removed after the release is done? Why
don't we have previews versions available in Epics?


In terms of permissions that I have... I realize there are more options
available than before, like edit a ticket, epics, etc, but there are
limitations like:
- I cannot change the status of stories (like these ones
https://issues.apache.org/jira/browse/MAHOUT-2024,
https://issues.apache.org/jira/browse/MAHOUT-1956 which I would like to
close as they were already merged
- I'm not able to create new sprints as it's saying I need Manage Sprints
permission. Of course, I'll try to solve the two ones which are open before
to create a new one, but it's still a limitation a can see in advance


Thanks in advance,
André


On Wed, Feb 28, 2018 at 10:46 PM, André Santi Oliveira 
wrote:

> The access is working well and thanks for the tips.
>
> My first approach, for some cases, will be to contact people to get more
> information before to take actions on the ticket.
> Like that, I can see if comments, re-assign or other actions will be
> necessary.
>
> I'll check what I can do in this case of the overlap. Maybe it'll be
> necessary to contact other groups but I'm ready to help on that as well.
>
> In case you don't agree with the actions I'm taking, please feel free to
> give feedback as I'm totally open to it.
>
>
> Cheers,
> André
>
> On Wed, Feb 28, 2018 at 2:11 PM, Andrew Palumbo 
> wrote:
>
>> Andre,
>>
>>
>> I agree with Trevor, this would be great.  You've been added to the
>> contributor role. A couple of quick notes:
>>
>> > - Tickets with status "open" and assigned by people (probably the
>> default
>> > when we create tickets)
>>
>>
>> We don't have a default asignee currently; the default when creating a
>> ticket is "unassigned"
>>
>> >   - Sprint from 2016 still open with no content inside
>> >   - Sprint name not matching with initial/end date
>>
>> We've been unable to delete some of the sprint boards, since they some
>> happen to overlap other projects, due to the way that ASF Jira is
>> configured.  This is something that we've had to co-ordinate with INFRA for
>> ,so you may need to discuss some issues with them.
>>
>>
>> This would be a great help for the project.
>>
>>
>>
>> Thanks very much.
>>
>>
>> --andy
>>
>>
>> 
>> From: Trevor Grant 
>> Sent: Friday, February 23, 2018 3:46:13 PM
>> To: Mahout Dev List
>> Subject: Re: Organize JIRA Board
>>
>> Hi Andre,
>>
>> That sounds great.
>>
>> We need to talk to INFRA about how to get you permissions.
>>
>> Will let you know shortly,
>>
>> tg
>>
>>
>> On Thu, Feb 22, 2018 at 11:59 PM, André Santi Oliveira <
>> asobra...@gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > I'm interested in collaborating with Mahout project and I've followed
>> the
>> > process to build Mahout from the source and so far it looks like
>> everything
>> > is working well.
>> >
>> > Then I jumped into your JIRA board and it looks like you need some help
>> to
>> > organize that part. Simple things I saw which could be organized like:
>> >
>> >   - Tickets with pull requests available but not linked to the ticket
>> >   - Tickets with status "open" and assigned by people (probably the
>> default
>> > when we create tickets)
>> >   - Sprint from 2016 still open with no content inside
>> >   - Sprint name not matching with initial/end date
>> >   - and so on...
>> >
>> > I really like this part of organizing things and I believe I can start
>> help
>> > on that. But to help you with this I need a specific access to JIRA
>> (more
>> > than a simple user that can just create tickets and put comments).
>> >
>> > Let me know what you think and if you need more information to trust me
>> on
>> > that.
>> >
>> >
>> > Cheers,
>> > André
>> > https://github.com/ASOBrasil
>> >
>>
>
>

Re: Spark 2.x/scala 2.11.x release

[Pat Ferrel]

LGTM


From: Andrew Palumbo  
Reply: dev@mahout.apache.org  
Date: March 2, 2018 at 3:38:38 PM
To: dev@mahout.apache.org  
Subject:  Re: Spark 2.x/scala 2.11.x release

I've started a gdoc for a plan.


https://docs.google.com/document/d/1A8aqUORPp83vWa6fSqhC2jxUKEbDWWQ2lzqZ1V0xHS0/edit?usp=sharing


Please add comments, criticision, and alternate plans on on the doc.


--andy


From: Andrew Palumbo 
Sent: Friday, March 2, 2018 6:11:53 PM
To: dev@mahout.apache.org
Subject: Re: Spark 2.x/scala 2.11.x release

Pat, could you explain what you mean by the "Real Problem"? I know that we
have a lot of problems, but in terms of this release, what is the major
blocker?

From: Pat Ferrel 
Sent: Friday, March 2, 2018 5:32:58 PM
To: Trevor Grant; dev@mahout.apache.org
Subject: Re: Spark 2.x/scala 2.11.x release

Scopt is so not an issue. None whatsoever. The problem is that drivers have
unmet runtime needs that are different than libs. Scopt has absolutely
nothing to do with this. It was from a false theory that there was no 2.11
version but it actually has 2.11, 2.12, 2.09, and according to D a native
version too.

Get on to the real problems and drop this non-problem. Anything that driver
needs but is not on the classpath will stop them at runtime.

Better to say that we would be closer to release if we dropped drivers.


From: Trevor Grant  
Reply: dev@mahout.apache.org  

Date: March 2, 2018 at 2:26:13 PM
To: Mahout Dev List  
Subject: Re: Spark 2.x/scala 2.11.x release

Supposedly. I hard coded all of the poms to Scala 2.11 (closed PR unmerged)
Pat was still having issues w sbt- but the only dependency that was on 2.10
according to maven was scopt. /shrug



On Mar 2, 2018 4:20 PM, "Andrew Palumbo"  wrote:

> So We could release as is if we can get the scopt issue out? Thats our
> final blocker?
>
> 
> From: Trevor Grant 
> Sent: Friday, March 2, 2018 5:15:35 PM
> To: Mahout Dev List
> Subject: Re: Spark 2.x/scala 2.11.x release
>
> The only "mess" is in the cli spark drivers, namely scopt.
>
> Get rid of the drivers/fix the scopt issue- we have no mess.
>
>
>
> On Mar 2, 2018 4:09 PM, "Pat Ferrel"  wrote:
>
> > BTW the mess master is in is why git flow was invented and why I asked
> that
> > the site be in a new repo so it could be on a separate release cycle.
We
> > perpetuate the mess because it’s always to hard to fix.
> >
> >
> > From: Andrew Palumbo  
> > Reply: dev@mahout.apache.org  <
> > dev@mahout.apache.org>
> > Date: March 2, 2018 at 1:54:51 PM
> > To: dev@mahout.apache.org   >
> > Subject: Re: Spark 2.x/scala 2.11.x release
> >
> > re: reverting master, shit. I forgot that the website is not on
> `asf-site`
> > anymore. Well we could just re-jigger it, and check out `website` from
> > features/multi-artifact-build-MAHOUT-20xx after we revert the rest of
> > master.
> >
> >
> > You're right, Trevor- I 'm just going through the commits, and there
are
> > things like
> > https://github.com/apache/mahout/commit/c17bee3c2705495b638d81ae2ad374
> > bf7494c3f3
> >
> >
> >
> > [https://avatars3.githubusercontent.com/u/5852441?s=200=4]<
> > https://github.com/apache/mahout/commit/c17bee3c2705495b638d81ae2ad374
> > bf7494c3f3>
> >
> >
> > MAHOUT-1988 Make Native Solvers Scala 2.11 Complient closes apache/ma…
·
> > apache/mahout@c17bee3<
> > https://github.com/apache/mahout/commit/c17bee3c2705495b638d81ae2ad374
> > bf7494c3f3>
> >
> > github.com
> > …hout#326
> >
> >
> >
> > (make Native Solvers Scala 2.11 compliant) and others peppered in, Post
> > 0.13.0. It still may be possible and not that hard, to cherrypick
> > everything after 0.13.0 that we want. But I see what you're saying
about
> it
> > not being completely simple.
> >
> >
> > As for Git-Flow. I dont really care. I use it in some projects and in
> > others i use GitHub-flow. (basically what we've been doing with merging
> > everything to master).
> >
> >
> > Though this exact problem that we have right now is why git-flow is
nice.
> > Lets separate the question of how we go forward, with what commit/repo
> > style, and First figure out how to back out what we have now, without
> > loosing all of the work that you did on the multi artifact build.
> >
> >
> > What do you think about reverting to 0.13.0, and cherry picking commits
> > like Sparse Speedup:
> > https://github.com/apache/mahout/commit/800a9ed6d7e015aa82b9eb7624bb44
> > 1b71a8f397
> > or checking out