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: 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
- 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
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
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: 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.
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
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,.
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
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.
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.
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.
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.