Version 1

    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.