ALR: Hello, all.

ALR: And welcome to another edition of "ShrinkWrap Resolvers Community Meeting."

- galderz has disconnected (Ping timeout: 260 seconds)

ALR: We'll be awaiting Karel, who might be tied up a little bit coming back from an appointment.

kpiwko: ALR: I'm here

ALR: And look at that.

ALR: Roll call to aslak

ALR: And I'll also see if I can find Dan, who'd wanted to join in.

- ge0ffrey has disconnected (Quit: http://blog.athico.com/search/label/planner)

ALR: Of course this is open to any and all who'd like to participate.

- mojavelinux has joined the room

ALR: As if on cue, ladies and gentlemen, mojavelinux

jose_freitas: clap clap clap clap

ALR: So today's agenda is mainly in getting together a Roadmap for ShrinkWrap Resolvers

ALR: Also known as SWR

ALR: I seeded this article: https://community.jboss.org/docs/DOC-17600

ALR: Issue tracker is in the newly-provisioned JIRA key SHINKRES: https://issues.jboss.org/browse/SHRINKRES

- galderz has joined the room

- galderz has disconnected (Changing host)

- galderz has joined the room

kpiwko: ALR:aslak: which version is now in Arquillian? 1.1.0-alpha-1, right?

ALR: 1.0.0.Final has not yet gone.

ALR: But any changes to be made are really targeted at least for 1.1.0-x yeah

kpiwko: ALR: ok

ALR: So with regards to SWR, we now have 2 maintenance branches.

ALR: I think to get a first 2.0.0-alpha-1 release out, the most primary task is in unifying "next" into "master" and killing "next".

mojavelinux: 1.0.0-beta-5

mojavelinux: Arquillian CR7 -> SWR 1.0.0-beta-5

ALR: mojavelinux: Yes, which is why we've created the maintenance branches.

kpiwko: ALR: yes, we should get rid of "next". I did a rebase recently on master, so it should be easy to do

ALR: mojavelinux: So Arquillian could receive updates like the BOM and depchain modules.

ALR: kpiwko: I noted that.  Let me see how easy that could go.

ALR: kpiwko: Merge came cleanly, yes

ALR: kpiwko: Running a build.

ALR: kpiwko: Are there any other tasks you'd like to see done before 2.0.0-alpha-1?

kpiwko: I think we should not release a broken api

ALR: Keep in mind that for alpha series I tend to keep the release requirements very minimal.

ALR: kpiwko: Even in the name of incrementally changing it throughout alpha?

kpiwko: ALR: in that case, let me search for jira

ALR: Sure.

- lfryc has disconnected (Quit: Leaving)

ALR: (It's a question on my part, really. I personally don't have much issue with releasing APIs known to change in alpha.  I *do* have issue with releasing broken software, but the testsuite is green/blue).

kpiwko: ALR: there is only one task to be done, that is triage SHRINKRES because some of the issues are fixed in next

kpiwko: ALR: my note about broken simply means that trying to activate is profile simply does nothing at all

kpiwko: *activate a profile

ALR: OK, something exposed and not working we could either:

ALR: 1) Make work

ALR: 2) Disable/comment

ALR: Test failures on merging next into master, so that's a blocker as well.

- struberg has joined the room

kpiwko: I'd go for disable 2/

* ALR opens an issue.

ALR: kpiwko: I would as well.

ALR: kpiwko: Open a JIRA to disable profiles and set it to Blocker on 2.0.0-alpha-1 ?

kpiwko: ALR: I will do that

ALR: kpiwko: The other blocker is this one, then: https://issues.jboss.org/browse/SHRINKRES-14

jbossbot: jira [SHRINKRES-14] Merge "next" into "master" [Open (Unresolved) Task, Blocker, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKRES-14

kpiwko: ALR: I'll will do a cherry-pick migration from "next" to "master", because comments have to be changed to reflect new issue names

ALR: kpiwko: I'd originally considered that, but:

ALR: 1) merge grabs all for sure

ALR: 2) You can interactive rebase later and change only the commit names

ALR: 3) We really don't need to do that with JIRA redirection in place

mojavelinux: yep, you can rewrite any commit message

ALR: s/names/messages

kpiwko: ah, interactive rebase, I've never done that

mojavelinux: it's extremely powerful

ALR: Get to know it, get to love it.

mojavelinux: perform when moving code between branches

mojavelinux: not something you want to do once you push to an official branch

mojavelinux: got a reference for karel?

mojavelinux: I had one up the other day, but lost it

ALR: Well, interactive rebase is a really broad subject to get a reference for.

mojavelinux: btw, note that github is offering free training for git over the next couple weeks...something I think we should take advantage of

mojavelinux: https://github.com/training/free

ALR: When I was learning it I learned first "squashing commits":

ALR: Or "renaming commits"

mojavelinux: right, I meant specifically for rewriting the messages, I'll find it in my history

ALR: Basically:

ALR: git rebase -i HEAD~x

ALR: Where "x" is the number of commits prior head you wanna rebase

ALR: Or you could simply pass in a commit SHA instead of "head and the few previous"

ALR: It'll launch a text editor asking what you wanna do with each commit listed.

mojavelinux: http://progit.org/book/ch6-4.html

ALR: Defaulting to "pick"

mojavelinux: yep, you got it

kpiwko: ALR: mojavelinux: no reason to that deep in detail... :-)

ALR: Change "pick" to "r" for "rewrite message"

ALR: Then save.

ALR: Presto bango

kpiwko: mojavelinux: thanks for the book reference

- jean_ has joined the room

ALR: kpiwko: as mojavelinux says, just don't rebase anything in upstream/master

ALR: You'll know if you do because it'd require a force on push.

mojavelinux: right, the real objective of rebase is to clean up a contribution

ALR: So basically avoid force pushing to upstream/master and we're all good.

mojavelinux: and a contribution is something that comes from a working dev branch

kpiwko: sure thing

ALR: As I said, in this case I don't think we need to do any of that.

mojavelinux: I *wish* github would support this in the UI

ALR: As kpiwko already rebased next upon master

mojavelinux: f*ing merge commits

ALR: And the JIRA issue numbers are gonna be redirected

kpiwko: ok

ALR: If you do it right, you get no merge commits, mojavelinux. :-)

ALR: So: do we find https://community.jboss.org/docs/DOC-17600 accurate?

kpiwko: yes, including alpha-1 release date

ALR: That's a week out from today.

- rachmatowicz has disconnected (Read error: Connection reset by peer)

mojavelinux: i was speaking about the github UI "the green button", but anyway, that's a side discussion

kpiwko: mojavelinux: that's why I don't use the green button at all

ALR: mojavelinux: That was kinda my joke; doing it "right" doesn't include BGB. :-P

ALR: (Big Green Button)

mojavelinux: there's nothing wrong with the idea of having a button...why not save time...except that it doesn't have a rebase option...if it did, it would be a *good thing*

ALR: Because then you can't run tests on the merged result before they go upstrea,.

ALR: *upstream

mojavelinux: again, that's just a matter of *how* the green button works...it could work that way, it just doesn't (pre-commit hooks)

mojavelinux: anyway, I get what you are saying, it doesn't work that way, so let's focus

ALR: I get what you're saying too....pre-commit to Jenkins or something.  Interesting.

ALR: So, roadmap.

ALR: Next week focus is to do all blockers in JIRA and get 2.0.0-alpha-1 out.

ALR: Then regroup with some API stuff and re-enable the profiles which we'll disable this week

ALR: Over the coming weeks I see a lot of API debate and possible changes in the works

ALR: So that'll be fun.

ALR: And hopefully lock those API discussions down by mid-April

- struberg has disconnected (Quit: Leaving.)

ALR: When we'll have something we wanna support for the long haul.

kpiwko: sound really good to me

kpiwko: *sounds

mojavelinux: I think we need to start talking a little bit about project pages too

mojavelinux: shrinkwrap has virtually no visibility on the web

mojavelinux: it only has awareness as a result of arquillian promoting it

ALR: mojavelinux: I definitely agree.

ALR: Can that development take place for SWR in the beta series?

mojavelinux: the place to start is simply work out the mission of each sub-project and a description, also an illustrative example

mojavelinux: don't worry about the infrastructure at this point, focus on content first

ALR: And for ShrinkWrap proper, well, that's debatably past-due.

mojavelinux: in this case, I'm focusing on resolvers

mojavelinux: since that's the context and it has zero information

ALR: TBH I was hoping our little side-project in authoring would help seed that information.

ALR: OK, SWR.

mojavelinux: frankly, I think SWR needs a reference guide

ALR: Yes, I'd like that to be done in beta.

ALR: When API is locked.

mojavelinux: I'm currently looking into using either reStructuredText or asciidoc for this purpose

ALR: And we can move from a development code focus into one of docs and usage.

mojavelinux: so, what I propose is just to start creating these raw text documents

mojavelinux: then we can meld them into a publishing system once we sort it out

mojavelinux: btw, both of those choices are viable because they *produce* docbook

ALR: mojavelinux: We've a resource allocation issue there.

mojavelinux: wdym?

ALR: No available labor.

ALR: Which is why I propose to do this in Beta.

mojavelinux: I think it's reasonable that karel can write up something...after all, if you are developing an API, surely you must be able to describe what it does

mojavelinux: but I understand time is short, which is why "write what you can" is the request

mojavelinux: better to write about it when it's fresh

ALR: And why is it necessary to be documenting while prototyping in Alpha?

mojavelinux: I'll create a JIRA and outline a few questions to answer, and the answer to those questions will get this ball rolling

mojavelinux: good question

mojavelinux: let me explain

kpiwko: mojavelinux: I have plans to write something but too many things going on at the moment...

mojavelinux: obivously there are stages

mojavelinux: documentation in alpha serves two purposes

ALR: Right, I don't think anyone is questioning the need for these docs or their intent.

ALR: Only the scheduling of work.

* ALR listening

mojavelinux: 1. makes sure you know where you are aiming, so you don't lose your way

mojavelinux: 2. allows other people to know what you are going for so they can help

mojavelinux: but certainly high level and terse

mojavelinux: in a sense they are the requirements transcribed into purpose

ALR: Good arguments.

mojavelinux: nothing more complex

ALR: 1) Mission Statement on the Wiki can do that I think.

ALR: 2) Combine that with decent JavaDocs as the API is written, and "Getting Started on Development" instructions should serve that need.

ALR: No?

kpiwko: maybe a guide at arquillian.github.com during alpha only?

mojavelinux: yep, like I said, I'll write in a jira what I think needs to be answered, and I don't expect it to be more than 30min of writing

mojavelinux: we'll all help refine

ALR: Oh, in that case sure.

mojavelinux: you've pretty much got it

ALR: I think we can each dedicate a few hours to this.

mojavelinux: yep

ALR: Just not "Project Site" or even anything as extensive as a user guide.

kpiwko: mojavelinux: is markdown compatible with docbook?

mojavelinux: short answer, yes

- struberg has joined the room

mojavelinux: markdown -> pandoc converter -> reStructuredText -> docboook

mojavelinux: it's possible

- struberg has disconnected (Read error: Connection reset by peer)

- struberg has joined the room

mojavelinux: but reStructuredText is currently my recommendation

mojavelinux: if you know markdown, you can learn it in about 5 minutes

struberg: hiho dan !

struberg: glad to have you back

* ALR suggests curbing impls and infrastructure for the moment.

mojavelinux: but if you gave me totally unformatted text, I could work with it ;-)

struberg: did you get gerhards mail regarding the article?

mojavelinux: this is not infrastructure alr

kpiwko: ok, a programmers life is a continuous learning of new frameworks

mojavelinux: this is just syntax so that the information can be communicated w/o "lost in translation"

mojavelinux: reStructuredText is basically markdown+++

ALR: Cool, mojavelinux spec it out.

ALR: JIRA's appropriate if it's related to a release.

- os890_ has joined the room

mojavelinux: oh, and we can type it up on the wiki in github

ALR: Else we've been playing with scheduling SWR on Trello.

ALR: I'll add you to the Group.

mojavelinux: anyway, too much detail here

mojavelinux: hey struberg!

ALR: Anything else on your mind then , kpiwko?

- os890 has disconnected (Ping timeout: 240 seconds)

kpiwko: ALR: nope

- os890_ is now known as os890

- rachmatowicz has joined the room

ALR: kpiwko: OK, so just those two JIRAs (merge next/master, disable profiles) and Dan's gonna get us an issue report for some docs by next week

ALR: And we'll aim for a release.

- rbattenfeld has joined the room

ALR: I think that concludes this meeting, and we'll give the room back to general discussion.