On Thu, Dec 19, 2013 at 1:31 AM, Robert Newson <rnew...@apache.org> wrote:
> "The bigcouch branch will proceed from its current state to fully > working state without any code coming into it from rcouch" > > I thought this much was clear from our discussions on the weekend. The > plan was to rebase each of the bigcouch and rcouch branches to current > couchdb master, in the hope that it would reduce the amount of > conflicts at the end. If, as we proceed, it's necessary to do so > again, we can, though I personally want to avoid that as much as > possible. > > Perhaps you are better able to build and test an rcouch that has the > bigcouch work merged into but I don't feel the same about the > converse, even with all of Cloudant helping. It's too much to ask. > > B. > > My expectations were different after the discussion and the creation of COUCHDB-1999. It is still unclear how you hope to have any working rebase if the branches continue to diverge. I would have expected some positive pollution on each branches to make sure that the integration branch could be done without much friction. It generally helps to obtain rapide results and let other users and developers to start to use this branch. In // some can also start to merge some parts from the integration branch in the master. My time is also limited and I don't work for cloudant. I personally don't want to lose much time at the end to figure how to merge /rebase big patches. Sometimes ago we asked the same for another big patch coming and it makes sense imo. > On 18 December 2013 23:59, Benoit Chesneau <bchesn...@gmail.com> wrote: > > On Wed, Dec 18, 2013 at 9:06 PM, ASF IRC Services < > > asf...@wilderness.apache.org> wrote: > > > >> Members present: jan____, deathbear, awenkhh, nslater, rnewson, > >> chewbranca, Kxepal > >> > >> ---------------- > >> Meeting summary: > >> ---------------- > >> > >> 1. Preface > >> > >> 2. 1.6 release > >> a. garren / deathbear to package fauxton for 1.6.0 release manually > >> (jan____, 2) > >> > >> 3. big merge plans > >> a. https://issues.apache.org/jira/browse/COUCHDB-1999 (Kxepal, 3) > >> > >> 4. couchhack > >> a. http://titanpad.com/GLRtWxjGmS (Kxepal, 4) > >> > >> 5. i18n > >> > >> > >> -------- > >> Actions: > >> -------- > >> - garren / deathbear to package fauxton for 1.6.0 release manually > >> (jan____, 19:13:45) > >> > >> IRC log follows: > >> > >> > >> # 1. Preface # > >> > >> > >> # 2. 1.6 release # > >> 19:09:37 [Kxepal]: afaik the only blocker thing for the release is > fauxton > >> bits > >> 19:10:07 [Kxepal]: can we help somehow with them? /cc garren deathbear > >> chewbranca > >> 19:10:30 [chewbranca]: what's the actual blocking issue? is there a > ticket > >> open? > >> 19:10:37 [jan____]: right, I think garren wanted to package things last > >> saturday, but that didn’t seem to have happened. > >> 19:10:52 [jan____]: concurrently nslater has been working on automating > >> the thing, but I don’t think that has landed yet > >> 19:10:53 [Kxepal]: or we'll wait nslater for completely fauxton > >> integration with autotools? there is special branch with some work > around > >> 19:11:01 [jan____]: chewbranca: it is the build to share/www/fauxton > step > >> that is missing > >> 19:11:16 [Kxepal]: > >> https://github.com/apache/couchdb/tree/1964-feature-fauxton-build > >> 19:11:22 [jan____]: (or the automatic doing of the same as part of the > >> build process, whichever arrives first) > >> 19:11:39 [nslater]: don't wait for me > >> 19:11:45 [nslater]: i'm probably not going to get it finished this year > >> 19:11:45 [chewbranca]: gotcha, so basically including ./bin/grunt > couchdb > >> in the makefile? > >> 19:11:53 [nslater]: i go on vacation at the end of this week > >> 19:11:53 [Kxepal]: chewbranca: I'm not sure that there is special JIRA > >> issue for this topic, but it was mentioned several times in ML > >> 19:11:59 [nslater]: and i am flat out with holiday stuff > >> 19:11:59 [nslater]: sorry about that > >> 19:12:07 [jan____]: chewbranca: it is more complicated that that > >> 19:12:07 [nslater]: just do another manual release into the source > >> 19:12:15 [deathbear]: So I don't know where garren is at with packaging > >> things > >> 19:12:29 [nslater]: deathbear chewbranca i have a branch where i am > >> working on this stuff > >> 19:12:31 [deathbear]: he might have wanted to get his proxy stuff in, > >> otherwise I would do it for you guys > >> 19:12:44 [nslater]: i have the bulk of it in but it needs more work. > it's > >> not gonna get done for this release > >> 19:12:59 [nslater]: Kxepal so please do not consider this a blocker, and > >> request that garren do a manual update > >> 19:13:15 [Kxepal]: nslater: ok > >> 19:13:45 [jan____]: #action garren / deathbear to package fauxton for > >> 1.6.0 release manually > >> 19:13:46 [nslater]: chewbranca deathbear please track work here > >> https://issues.apache.org/jira/browse/COUCHDB-1964 > >> 19:13:59 [nslater]: or on the branch, already linked > >> 19:14:14 [nslater]: > >> https://github.com/apache/couchdb/commits/1964-feature-fauxton-build > >> 19:14:15 [nslater]: ^ my commits over couchhack > >> 19:14:37 [deathbear]: ok > >> 19:14:52 [nslater]: i'd like to talk to you both at some point to make > >> sure the full integration works for you > >> 19:14:54 [nslater]: and i am doing it ideomatically, etc > >> 19:15:02 [nslater]: i gotta dash now. sorry! > >> 19:15:22 [deathbear]: Garren and I are both online like.. uuh whatever > >> time is 4 hours ago for you. > >> 19:15:37 [nslater]: hehe > >> 19:15:39 [deathbear]: nslater he's going on vacation soon, so ping us > >> tomorrow > >> 19:16:07 [nslater]: deathbear probably in the new year now > >> 19:16:14 [nslater]: as i say, i got two weeks of vacation > >> 19:16:29 [deathbear]: oh well sweet. less stress for me :D > >> 19:16:30 [nslater]: hehe > >> 19:19:51 [Kxepal]: ok, we have a plan(: hope djc will also have a time > to > >> prepare release in this year. moving forward? > >> 19:20:40 [jan____]: +1 > >> > >> > >> # 3. big merge plans # > >> 19:21:03 [Kxepal]: #link > >> https://issues.apache.org/jira/browse/COUCHDB-1999 > >> 19:21:51 [jan____]: ACTION parties like it is 1999 > >> 19:22:35 [Kxepal]: the issue above has simple schema of merge process. > it > >> seems that both bigcouch and rcouch will be continuously merged into > >> separate integration branch which will holds all changes for pre-1.6 > >> release state > >> 19:22:58 [jan____]: that is correct. > >> 19:24:00 [jan____]: there are a few incompatible changes in rcouch and > >> bigcouch and it is no good for either of them to wait for the other > because > >> of extra work, so we hope to minimise issues by doing an upfront rebase > >> with master and then periodic integration in a merge branch before > things > >> go into master > >> 19:24:15 [jan____]: that is on the procedural end, the actual issues are > >> discussed in the 16 or so linked issue > >> 19:24:20 [jan____]: s > >> 19:24:43 [rnewson]: That's not quite what we agreed. > >> 19:25:05 [rnewson]: The bigcouch branch will proceed from its current > >> state to fully working state without any code coming into it from > rcouch. > >> 19:26:19 [jan____]: …I wasn’t done typing :) > >> 19:26:20 [Kxepal]: rnewson: the schema says that so it be for both > >> branches, but periodically these work will be merged into integration > branch > >> 19:26:27 [jan____]: but thanks for filling in > >> 19:26:50 [Kxepal]: but let's wait for Jan reply since this is my > >> assumptions(: > >> 19:27:20 [jan____]: either branch can choose to pull things in from the > >> integration branch, but can avoid dealing with incompatiblities > >> 19:27:51 [rnewson]: :/ still don't think we agreed to that. > >> 19:28:39 [jan____]: until we are at a point where both rcouch and > bigcouch > >> are merged but don’t necessarily work together. the idea is that we > make it > >> easy for both cloudant and rcouch to make sure all is merged and working > >> and then apache couchdb as a team worries about getting it all together > >> 19:28:52 [jan____]: rnewson: sorry if I repeated it wrongly, please > clear > >> things up > >> 19:30:05 [rnewson]: I tried to clarify that we wouldn't be merging both > >> contributions at the same time. that is, into an integration branch > which > >> is then pulled down to master. > >> 19:30:20 [rnewson]: There needs to be a commit on couchdb master than > >> includes one contribution, then another that includes the other. > >> 19:30:37 [rnewson]: unless, of course, we can eliminate all concerns > that > >> the combination works correctly ahead of time. > >> 19:30:50 [jan____]: ok, then the image we came up with on the whiteboard > >> didn’t include that fact > >> 19:31:05 [jan____]: I’m just the messenger here :) > >> 19:32:43 [rnewson]: I don't want to tie the meeting up, I'll just state > >> that I (and, by extension, Cloudant) need to complete our contribution > of > >> our work into a recent-ish couchdb/master branch without any other > changes > >> being introduced. After that point, I guess it doesn't matter how it's > >> merged to master. > >> 19:32:50 [jan____]: rnewson: thanks for the clarification, I’ll try and > >> update 1999 accordingly > >> 19:33:44 [rnewson]: Ideally, from my point of view, that means merging > our > >> branch to master first, which is why Cloudant is arranging for our core > >> team to meet in Seattle for a week of hacking in January. > >> > > > > Not sure if I understand it correctly. But are we still agree to merge on > > the integration branch when the code is OK to be merge from both part? > Also > > I don't follow the reasoning about that. While I appreciate all the work > > and time investment done by cloudant, we are speaking about the couchdb > > project here. And imo for a project perspective it is a way better to > make > > sure that this "final point" you want to achieve will be easy to merge at > > the end. And more important that it fits everyone needs and let everyone > > from the ream and the community involved in the merge making sure that > > everything work and that new features can be added in couchdb at the same > > time with the minimum friction. So maybe I misunderstood what you mean > > there, but I thought we were agree on the above, and can't see how it can > > work if you don't do any rebase/merge/cherry-picking from time to time in > > the branch you're working on. Can you clarify that? - benoit > > > > > >> 19:33:56 [rnewson]: anyway, I've said my bit, continue with meeting. > >> 19:34:33 [jan____]: thanks! > >> 19:37:03 [jan____]: any more questions? > >> 19:37:54 [Kxepal]: nothing from me about the topic > >> > >> > >> # 4. couchhack # > >> 19:41:32 [Kxepal]: so, jan____, how it was?(: > >> 19:41:48 [jan____]: CouchHack Vienna took place friday-monday last > weekend > >> with rnewson, nslater, vmx, lgierth, benoitc, dch and myself. dch ran > the > >> show, thanks so much for pulling it all together. > >> 19:42:02 [jan____]: it was pretty cool to meet in person, we should > >> absolutely do this more often > >> 19:42:41 [jan____]: we decided it was most important to talk about the > >> merges and that’s what we ended up doing. At least my understanding > about > >> how this is all supposed to be going down has greatly increased > >> 19:43:24 [Kxepal]: #link http://titanpad.com/GLRtWxjGmS > >> 19:43:39 [Kxepal]: ^^^ important notes about > >> 19:44:02 [jan____]: and then Vienna was a nice background for evening > >> activities, though a bit cold :) > >> 19:44:32 [jan____]: There were some more topics discussed on Friday and > >> Monday that I missed due to travels, but vmx and dch should be able to > fill > >> in > >> 19:46:18 [Kxepal]: oh..great! I wished be there, but suddenly I couldn't > >> 19:46:34 [awenkhh]: ? > >> 19:46:40 [jan____]: Kxepal: too bad, there will be many more in the > future > >> 19:46:48 [jan____]: awenkhh: meeting in progress > >> 19:46:49 [awenkhh]: hi > >> 19:47:10 [awenkhh]: ??? oh I am in the wrong timezone .... sorry! > >> 19:47:18 [awenkhh]: I thought 21:00 Berlin > >> 19:47:33 [jan____]: yeah, no :) > >> 19:47:35 [jan____]: Kxepal: next topic? > >> 19:48:09 [Kxepal]: I haven't any. may be awenkhh has something to > discuss? > >> 19:48:09 [awenkhh]: I could say / write a bit about i18n > >> 19:48:32 [Kxepal]: great! > >> 19:48:32 [awenkhh]: well > >> > >> > >> # 5. i18n # > >> 19:49:02 [awenkhh]: I am really happy that there are already many > >> translators in various languages > >> 19:49:04 [awenkhh]: awesome! > >> 19:49:36 [awenkhh]: actually I have the feeling, that we are not making > >> that huge progress but that's ok > >> 19:49:40 [awenkhh]: it's the beginning > >> 19:49:55 [awenkhh]: I am thinking about how to motivate the > participating > >> people > >> 19:50:03 [awenkhh]: ... a bit more > >> 19:50:05 [awenkhh]: on the other hand > >> 19:50:18 [awenkhh]: it's really time consuming if one wants to make it > good > >> 19:50:47 [awenkhh]: so if there are any ideas ... I would love to hear > >> them :) > >> 19:50:54 [Kxepal]: it's hard work to translate things. you have not only > >> know how to translate, but also understand things you're translating to > not > >> loose their meaning > >> 19:51:02 [awenkhh]: yeah exactly > >> 19:51:18 [awenkhh]: one thing I would like to ask; > >> 19:51:47 [awenkhh]: when will be a good point to include the creation of > >> the docs in the various languages to the build process? > >> 19:52:32 [awenkhh]: and ... > >> 19:52:47 [awenkhh]: Kxepal are you still in that boat? :) > >> 19:53:02 [jan____]: awenkhh: as soon as we get to figuring it out. I > think > >> January is earliest to talk about that > >> 19:53:02 [Kxepal]: awenkhh: I think when at least to one language > >> translation will be done. it's worthless to ship half german half > english > >> docs > >> 19:53:24 [Kxepal]: imho, but there could be another point of view > >> 19:53:24 [awenkhh]: jan____ Kxepal both true ... > >> 19:53:39 [awenkhh]: no no ... that's fine > >> 19:54:09 [awenkhh]: ok > >> 19:54:47 [awenkhh]: so I will think about how we could attract 1.) more > >> translators and 2.) motivate the existing ones to go forward > >> 19:55:09 [awenkhh]: maybe we could propose some easy deadlines ... like > a > >> road map > >> 19:55:32 [awenkhh]: not sure if that's cool or if we say "it's done when > >> it's done" > >> 19:56:10 [jan____]: I think shipping some translated docs is better than > >> none, it should encourage contributors to get things out faster > >> 19:56:39 [jan____]: also, if someone is reading some translated docs and > >> finds untranslated bits, they may jump in and help, if we put pointers > >> everywhere > >> 19:57:02 [Kxepal]: good point > >> 19:57:17 [awenkhh]: I am planning some time during the upcoming holidays > >> for translation > >> 19:57:40 [Kxepal]: I think we could add link to pootle from docs like we > >> have one for github > >> 19:57:42 [awenkhh]: soi maybe we have soon the German docs half done or > so > >> ... then we could do it like jan____ proposed > >> 19:58:12 [awenkhh]: Kxepal yeah good point! > >> 19:58:17 [jan____]: awenkhh: I think as soon as the introduction > chapters > >> are done, things could go live > >> 19:58:33 [jan____]: and then have links from all untranslated pages to > the > >> translation ponints > >> 19:58:40 [awenkhh]: jan____ ... that will be soon :) > >> 19:58:55 [awenkhh]: sound like a good plan! > >> 19:59:25 [jan____]: awenkhh: that could also be communicated as a > barrier > >> for in-progress translations to hit before they get published > >> 20:00:03 [awenkhh]: sry ... what do you mean here? barrier? > >> 20:00:18 [Kxepal]: we're also have to decide where host online > translated > >> html docs > >> 20:00:33 [jan____]: awenkhh: I think we shouldn’t publish docs that have > >> half a chapter done > >> 20:00:33 [Kxepal]: RTD lacks of such feature > >> 20:00:35 [jan____]: or just a few bits > >> 20:00:50 [jan____]: Kxepal: let’s leave that for later > >> 20:00:57 [Kxepal]: jan____: ok > >> 20:00:58 [awenkhh]: jan____ ok ... got it ... > >> 20:01:24 [jan____]: there should be a defined criterion for when a > >> translation starts to get published and ideally that is as fast as > possible > >> 20:01:39 [jan____]: so I’d suggest picking something like an > introduction > >> chapter and make that the first bit that needs to be translated > >> 20:02:09 [awenkhh]: imho when a chapter is translated, it can be > published > >> 20:02:24 [awenkhh]: as you said - half chapters is uncool > >> 20:02:26 [jan____]: as far as further strategeis to encourage people to > >> translate is: make a translation day, pick a friday afternoon or > something > >> i18n@ agrees on, where everybody meets in IRC and just works on things > >> for an hour or three > >> 20:02:39 [jan____]: we did that a few times for cleaning up the wiki > >> 20:02:47 [jan____]: awenkhh: yeah, that too > >> 20:02:55 [awenkhh]: ahhh ... cool idea ! > >> 20:03:10 [awenkhh]: that will bring the people closer together > >> 20:03:17 [awenkhh]: cool! > >> 20:03:26 [awenkhh]: I will organise that > >> 20:03:34 [jan____]: awenkhh: excellent > >> 20:04:12 [awenkhh]: ok - thats what I have for this topic > >> 20:04:32 [jan____]: thanks! > >> 20:04:39 [jan____]: Kxepal: anything else? > >> 20:04:47 [awenkhh]: yep :) > >> 20:05:09 [Kxepal]: jan____: nothing more I see and time is getting out > >> 20:05:19 [awenkhh]: more brainstorming for how to spread the word about > >> CouchDB > >> 20:05:39 [awenkhh]: i did not manage to write it together so we could > >> leave it for now > >> 20:05:54 [awenkhh]: sorry that I miss the beginning of this meeting! > >> 20:05:57 [awenkhh]: missed > >> 20:06:17 [Kxepal]: awenkhh: that's marketing thing and nslater is on it > - > >> you may consult with him when he get from vaccantions (: > >> 20:06:17 [Kxepal]: ASFBot: meeting end > >> > >> >
