Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2016-04-14

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:20 josferna joined #gluster-dev
01:28 EinstCrazy joined #gluster-dev
01:32 EinstCrazy joined #gluster-dev
01:57 luizcpg joined #gluster-dev
02:01 EinstCrazy joined #gluster-dev
02:09 ira joined #gluster-dev
02:10 mjrosenb joined #gluster-dev
02:11 mjrosenb not sure if this is any better a place to ask, but I built gluster on freebsd, and now it seems to not work because it is trying to load glusterd.so even though it never built that shared object (or any shared object for that matter)
02:53 kdhananjay joined #gluster-dev
03:03 nishanth joined #gluster-dev
03:07 overclk joined #gluster-dev
03:15 Gaurav_ joined #gluster-dev
03:27 kotreshhr joined #gluster-dev
03:33 atinm joined #gluster-dev
03:40 shubhendu joined #gluster-dev
03:47 kdhananjay joined #gluster-dev
03:51 aravindavk joined #gluster-dev
03:59 itisravi joined #gluster-dev
04:02 jiffin joined #gluster-dev
04:20 sakshi joined #gluster-dev
04:23 poornimag joined #gluster-dev
04:27 suliba joined #gluster-dev
04:27 aspandey joined #gluster-dev
04:31 mjrosenb joined #gluster-dev
04:32 kkeithley joined #gluster-dev
04:36 [o__o] joined #gluster-dev
04:40 primusinterpares joined #gluster-dev
04:55 bfoster joined #gluster-dev
04:56 rafi joined #gluster-dev
04:57 ndk joined #gluster-dev
04:57 mchangir joined #gluster-dev
05:04 karthik___ joined #gluster-dev
05:04 nbalacha joined #gluster-dev
05:07 asengupt joined #gluster-dev
05:15 ppai joined #gluster-dev
05:16 kdhananjay joined #gluster-dev
05:19 jiffin joined #gluster-dev
05:19 ndarshan joined #gluster-dev
05:21 rraja joined #gluster-dev
05:30 hgowtham joined #gluster-dev
05:30 Apeksha joined #gluster-dev
05:30 Manikandan joined #gluster-dev
05:31 hchiramm joined #gluster-dev
05:33 luizcpg joined #gluster-dev
05:34 Bhaskarakiran joined #gluster-dev
05:37 vmallika joined #gluster-dev
05:46 ashiq joined #gluster-dev
05:48 pkalever joined #gluster-dev
05:52 prasanth joined #gluster-dev
05:52 atalur joined #gluster-dev
06:00 pranithk joined #gluster-dev
06:01 nishanth joined #gluster-dev
06:02 itisravi_ joined #gluster-dev
06:03 shubhendu_ joined #gluster-dev
06:03 decay_ joined #gluster-dev
06:06 rastar joined #gluster-dev
06:07 sankarshan_away joined #gluster-dev
06:15 ashiq joined #gluster-dev
06:16 anoopcs joined #gluster-dev
06:19 rraja joined #gluster-dev
06:27 Saravanakmr joined #gluster-dev
06:27 s-kania joined #gluster-dev
06:28 spalai joined #gluster-dev
06:34 hchiramm joined #gluster-dev
06:38 asengupt joined #gluster-dev
06:50 Chr1st1an joined #gluster-dev
07:04 pur_ joined #gluster-dev
07:10 cholcombe joined #gluster-dev
07:16 ggarg joined #gluster-dev
07:53 Debloper joined #gluster-dev
08:14 semiosis joined #gluster-dev
08:14 semiosis joined #gluster-dev
08:16 aravindavk joined #gluster-dev
08:22 josferna joined #gluster-dev
08:32 atinm rastar, hey, did you see my email which test generates the core ?
08:32 atinm s/email/email on
08:49 pranithk overclk: hey is it a good time to talk to you about http://review.gluster.org/#/c/13833​/5/xlators/storage/posix/src/posix.c ?
09:05 overclk pranithk: maybe after a while.
09:07 overclk pranithk, kotreshhr: in short the main point is that this is not enabled by default
09:08 overclk pranithk, kotreshhr: and even if it's enabled, then there's a cap on size for which an object is scrubbed on-demand.
09:08 pranithk overclk: okay ping me...
09:12 Manikandan joined #gluster-dev
09:18 rastar atinm: many factors for that
09:18 atinm rastar, would be able to reply to that email explaining it?
09:19 rastar atinm: yes
09:19 atinm rastar, basically I am clueless which test has caused it and what to look at
09:19 rastar atinm: is the bt not useful?
09:33 asengupt joined #gluster-dev
09:34 pkalever joined #gluster-dev
09:36 pranithk joined #gluster-dev
09:37 ashiq joined #gluster-dev
09:41 spalai joined #gluster-dev
09:45 ggarg joined #gluster-dev
09:48 Apeksha joined #gluster-dev
10:04 rastar atinm: it is a segfault in memcpy and not because of null pointers
10:04 rastar atinm: mostly len wasn't right
10:05 rastar atinm: I can't figure out how that could happen
10:05 rastar atinm: it was a ec test
10:05 rastar atinm: can't tell which one
10:05 ira joined #gluster-dev
10:18 atinm rastar, and my changes are not related too :(
10:18 rastar atinm: yes :(
10:19 rastar atinm: I am explaining reasons in mail, but in short, test infra changes and not backported because they depend on others to back port that has not happended properly yet.
10:20 rastar atinm: I am trying to find out what test it was
10:20 atinm rastar++
10:20 glusterbot atinm: rastar's karma is now 31
10:20 rastar atinm: mark that bad, meanwhile retrigger
10:20 atinm rastar, thanks for taking your time to look into it
10:20 rastar atinm: this should pass
10:24 kkeithley1 joined #gluster-dev
10:25 Debloper joined #gluster-dev
10:28 ashiq joined #gluster-dev
10:38 rastar joined #gluster-dev
10:53 dlambrig_ joined #gluster-dev
10:54 bfoster joined #gluster-dev
11:07 shyam joined #gluster-dev
11:17 prasanth joined #gluster-dev
11:28 * kkeithley_ hopes klshm remembers to bump the op_version to 3.7.11 if necessary
11:29 * kkeithley_ also hopes ndevos remembers to bump the op_version to 3.8.0 when that time comes.
11:32 nbalacha joined #gluster-dev
11:36 mchangir|away joined #gluster-dev
11:37 foster__ joined #gluster-dev
11:45 ndevos kkeithley_: thats only needed for new options, and it should be at 308000 already...
11:51 kkeithley_ There's a GD_OP_VERSION_3_7_12 and GD_OP_VERSION_4_0_0 defined in libglusterfs/src/globals.h, but no GD_OP_VERSION_3_8_0 (on the master branch)
11:52 ndevos kkeithley_: oh, ok, I'll file a bug for that and make sure the options for 3.8 features get the 3.8.0 op-version
11:52 ndevos kkeithley_: can you add a 3.8.0 version to bugzilla?
11:52 kkeithley_ sure
11:53 kkeithley_ No news from kshlm about 3.7.11!
11:53 Apeksha joined #gluster-dev
11:54 * kkeithley_ wonders why we have GD_OP_VERSION_3_7_12 but not GD_OP_VERSION_3_7_11
11:58 kkeithley_ Are we going to keep doing the 3.X.0, 3.X.1, 3.X.2, ... thing in bugzilla? Or are we ready to have just a single 3.8 version for all bugs?
11:58 kkeithley_ For all bugs against 3.8.x?
11:59 Apeksha_ joined #gluster-dev
12:00 post-factum and end up having over 9000 bugs against one version?
12:03 kkeithley_ yes, that would be one of the consequences.
12:04 post-fac1um joined #gluster-dev
12:05 bfoster1 joined #gluster-dev
12:06 ndevos itisravi_, kdhananjay, jiffin: throttling xlator has moved to "next release" - https://github.com/gluster/glusterweb/commi​t/e27b0f100f54726227992cafab2bfc4ad27e2696
12:09 jiffin ndevos: I saw it on "Experimental" category instead of "Moved out to the next minor or major release" in the roadmap page https://www.gluster.org/community/roadmap/3.8/
12:10 itisravi_ ndevos: okay
12:10 ndevos jiffin: press F5?
12:11 jiffin ndevos: gotcha, but it is not part of the table
12:12 ndevos jiffin: no, thats not needed, we need to move that table and other features to a new page at one point
12:12 jiffin ndevos: K
12:15 xavih joined #gluster-dev
12:20 sac joined #gluster-dev
12:20 poornimag joined #gluster-dev
12:23 pranithk ndevos: what do you mean by next minor release in https://www.gluster.org/community/roadmap/3.8/ ? 3.8.1 or 3.9?
12:23 ndevos pranithk: 3.9 or 4.0, whatever comes first
12:24 ndevos pranithk: anyting not ready (at least experimental) by the time 3.8 is released, gets moved to the next release
12:24 pranithk ndevos: Why should we delay users a feature which can be given in 2 months after  3.8.0. by 6-7 months? Why suffer for extra 4 months? This is exactly  what we did for sharding and arbiter. It took  few .x releases for them  to even be in a shape to start testing them. And now both of them are in  a state that we can put them in production, thanks to some great  community testing.
12:24 pranithk ndevos: Is there no provision for that?
12:25 kkeithley_ Major.Minor.Teeny
12:25 kkeithley_ Major.Minor.Teeny-Release
12:26 ndevos pranithk: it is why we planned to do regular releases, if it is not ready for 3.8, what could possibly guarantee that it gets production quality ready during 3.8?
12:27 kkeithley_ pranithk: that's part of why Ric suggested we go to a four month cadence for community releases.  If you miss this one, then you don't have to wait as long
12:27 ndevos pranithk: if it would have been a critcal feature for 3.8, developers should have been given enough time to work on it
12:28 ndevos kkeithley_: I think Ric was talking about the RHGS release cycle, I do not remember suggesting we should try to get that done for community releases too
12:29 kkeithley_ oh, okay. I wasn't sure which one he proposed that for.
12:29 pranithk ndevos: It will get production ready during the cycle because we did that for 2 of the features in the past
12:29 pranithk ndevos: It is by experience
12:29 post-factum joined #gluster-dev
12:30 pranithk ndevos: for sharding, arbiter...
12:30 ndevos pranithk: I dont trust the experience here, it is not even experimental ready for 3.8, and that is a requirement for getting into 3.8.
12:31 pranithk ndevos: I do not disagree. But it still makes users not get the functionality for extra 6 months atleast which I don't want to happen
12:32 ndevos pranithk: sorry, but things that are not ready should not get included
12:33 ndevos pranithk: if you like more regular releases, we could go to a 4 month release cycle, if that makes sense
12:36 pranithk ndevos: thinking
12:38 pranithk ndevos: Tell me what prevents a new feature to be included in one of the .x releases? How do we come to that decision of including/not including something in a .x release?
12:38 pranithk ndevos: At least from technical standpoint I don't see any problems. Op-version is solid and allows it
12:38 pranithk ndevos: So it all boils down to stability IMO
12:39 ndevos pranithk: right, and stable releases should not introduce new features :)
12:39 pranithk ndevos: Stable features should not become unstable
12:39 pranithk ndevos: Your standpoint if I understand correctly is that new features make stable releases unstable
12:39 ndevos pranithk: indeed, we call those regressions
12:40 pranithk ndevos: So why do you think all new features are a cause for potential regressions?
12:40 ndevos pranithk: any change we make in the stable release have a chance on introducing regressions
12:41 pranithk ndevos: Gluster is good that way too, things are consolidated inside translators which can be disabled
12:41 ndevos pranithk: we also want to give a clear message to our users, and not confuse them with when features get introduced
12:42 ndevos pranithk: the whole point of stable releases is only improving stability, otherwise we could just stick to building packages from the master branch
12:44 pranithk ndevos: Ah! okay, I think we both are arguing for the same. Stability. It is just that in afr at this moment, we need to introduce small new features for stability. I do not see a way to get them in users hands sooner with the release model we have. If it gets pushed to 3.9. It won't be picked up for trial at least till we go to 3.9.2 which is 8-10 months from now. It is just too slow.
12:45 pranithk ndevos: Constant gripes about afr has been, too slow self-heal or too fast self-heal. You will see problems about this on gluster-users too frequently
12:46 * ndevos is on the phone...
12:47 hchiramm joined #gluster-dev
12:49 pranithk ndevos: How can we solve user's problems sooner by these features? 10 months is too long Niels. I want these features to get into user's hands sooner. ~3-4 months from now.
12:57 shyam joined #gluster-dev
12:58 pranithk|mtg ndevos: In meeting for 30 minutes...
12:58 jiffin joined #gluster-dev
12:58 ndevos pranithk|mtg: ok, we'll catch up in a bit
12:59 kkeithley_ It seems to me that if a new feature "isn't ready" for 3.8, then it doesn't ship in 3.8.0.  I don't think that precludes adding it later, e.g. in 3.8.3, as experimental.  We do have a precedent for doing that.
13:00 kkeithley_ Have it been decided that we don't do that any more?
13:01 kkeithley_ s/Have/Has/
13:05 dlambrig_ joined #gluster-dev
13:13 kbyrne joined #gluster-dev
13:17 ndevos kkeithley_: adding features in stable releases breaks things, we have way to many precedents of that too
13:18 ndevos pranithk|mtg: if we release 3.8 at the end of May (1.5 months), releasing 3.9/4.0 6 months later makes it 7.5 months of waiting in total?
13:19 ndevos pranithk|mtg: I think we just need better planning, and more stricter release management, no delays if features are no ready
13:21 karthik___ joined #gluster-dev
13:22 rafi1 joined #gluster-dev
13:22 ira joined #gluster-dev
13:23 kkeithley_ 3.8 is already six months late. If we had shipped 3.8 on schedule, we'd be talking about this feature not being in 3.9 instead. And it's still not ready now! So when will it _really_ be ready? We could (emphasis on could) consider shipping 3.9 earlier than six months, if it's for the purpose of getting this feature out into the hands of the public.
13:24 ndevos I agree. If there are enough features ready in a few months, we can consider doing a 3.9 by then
13:25 kkeithley_ Whatever we end up doing, we have to stop delaying releases. Because everyone else who has things that _are_ in 3.8 and wants them in the hands of the public have been waiting....
13:25 ndevos https://www.gluster.org/community/roadmap/3.8/  currently lists 27 features, that is skipping the "at risk" and "next version" ones
13:26 ndevos more regular releases keep it much more consumable for users too
13:26 nbalacha joined #gluster-dev
13:28 kkeithley_ Delaying releases is also a burden on the maintainers of the older releases. 3.5.x would have been EOL six months ago, and we'd be ready to EOL 3.6 now.  The effort to keep doing releases on those branches is not inconsequential.
13:36 pranithk ndevos: I generally see bugs popping up from .2 releases so that is 2 months from the .0 release. So 2 more months...
13:37 ndevos pranithk: that is not an encouraging point to get a feature included in a stable relaese at a later time
13:38 ndevos pranithk: we hope to have little maintenaince on stable branches, adding features that are not stable need more work for the maintainers, and can give users the wrong perceptions
13:40 nigelb joined #gluster-dev
13:41 pranithk ndevos: We have done this for 3.7.x already, what new perceptions are you talking about?
13:41 ndevos pranithk: perceptions that a stable release is stable, we have broken 3.7 several times when we introduced new features
13:42 pranithk ndevos: what new features broke 3.7?
13:42 pranithk ndevos: The reason 3.7 releases were broken are because we do not have a release process in place which tests enough things
13:42 kotreshhr joined #gluster-dev
13:42 ndevos pranithk: what is the reason 3.7.10 broke?
13:42 pranithk ndevos: Not because of new features.
13:43 pranithk ndevos: ipv6
13:43 ndevos pranithk: and how was that not a feature?
13:43 pranithk ndevos: ipv6 is not a translator, it is infra level change that can't be turned off
13:43 ndevos pranithk: and also something with snapshot... some directories in glusterd were missing
13:44 ndevos pranithk: *any* change can introduce problems, stable releases should really only get safe fixes
13:45 post-fac1um joined #gluster-dev
13:45 pranithk ndevos: We can only know if something is safe after the fact that nothing broke. We don't have enough infra at the moment to term something is safe.
13:46 ndevos pranithk: sure, we need more testing in the master branch, and that is what a feature should introduce as well
13:47 ndevos pranithk: without regular testing, features will not be stable, and even simple patches can break seemingly unrelated things
13:47 pranithk ndevos: Even an innocent looking one line fix can also cause serious regression. There is no such thing called safe fix
13:47 pranithk ndevos: exactly!
13:47 ndevos pranithk: ... your point on getting new features in a stable release is not getting any stronger?
13:48 pranithk ndevos: so we shouldn't do any releases based on the point that there is no safe fix?
13:48 ndevos pranithk: I would really like to have a requirement for backports to a stable branch, demanding like two weeks testing in the master branch
13:49 ndevos pranithk: only backport patches that have been tested well enough, hence the requirement for each change to add a test-case
13:49 pranithk ndevos: That is a good initiative that needs to improve testing infra we have.
13:50 pranithk ndevos: Give such rule for new feature too. How much time should it be baked in upstream before it is backported to 3.8.x
13:50 ndevos pranithk: we have distaf in the glusterfs repo now, and that should be used for nightly/periodic testing on real hardware
13:50 pranithk ndevos: I agree, with you on that. How much time should a feature be baked in upstream before it can be ported to 3.8.x
13:51 ndevos pranithk: the rule depends on what testing the master branch gets... that is still a work in progress
13:51 pranithk ndevos: We both want safe fixes to be ported to 3.8.x. Now the discussion is how can we deem a patch safe
13:52 pranithk ndevos: I am sure 2 weeks testing on master before a patch is ported to 3.8.x is a number we feel safe. Is there a method to this?
13:52 ndevos pranithk: only very few patches would be safe, even simple changes that got reviewed by different maintainers have broken 3.7 - each patch is a risk
13:53 ndevos pranithk: only when we improve our tests, both regression tests and distaf feature tests, that gives more confidence
13:54 pranithk ndevos: This has been a discussion, in gluster we do not have a good criteria for what is stable and what is not.
13:54 ndevos pranithk: in addition to that, we need tests that do in-place-updates between versions, 3.8.0 to 3.8.1 etc.
13:54 pranithk ndevos: yeah true
13:55 pranithk ndevos: on call
13:55 ndevos pranithk: we're working on improving the tests, so hopefully the regression tests get stable, and regular distaf testing for scalability and features
14:00 rafi joined #gluster-dev
14:01 rraja joined #gluster-dev
14:02 post-factum joined #gluster-dev
14:02 atalur joined #gluster-dev
14:03 asengupt joined #gluster-dev
14:03 rastar joined #gluster-dev
14:03 ira joined #gluster-dev
14:06 nishanth joined #gluster-dev
14:07 hchiramm joined #gluster-dev
14:09 nbalacha joined #gluster-dev
14:19 pranithk ndevos: back
14:20 pranithk ndevos: I am trying to help there too. I am trying to get memory-leaks identified quickly. I recently had a conversation with rastar. I have a meeting with one of the juniors about converting statedump to xml/json
14:21 pranithk ndevos: Then the next step is to add distaf function which can find if there are leaks
14:21 kotreshhr joined #gluster-dev
14:22 ndevos pranithk: kkeithley_ has a longlivety (sp?) environment that should be usable for that
14:22 ndevos pranithk: I do not know how a relatively short running distaf test would be able to detect leaks reliably
14:22 pranithk ndevos: yeah but this work is around a month-2 months work based on what I gathered
14:22 pranithk ndevos: the way to do it is like this:
14:23 ndevos pranithk: interesting, maybe you can share some notes+plans about that on gluster-devel?
14:23 pranithk ndevos: create a volume. Run your workload and delete all the files/dirs and take statedump. Run the workload again and delete all files again. Now take statedump. There shouldn't be any differences
14:25 ndevos pranithk: maybe, unless you have some journaling/changelog kind of thing? but yeah, I guess that general approach should work mostly
14:26 pranithk ndevos: for this first step is xml/json based statedumps for easy parsing
14:26 pranithk ndevos: next step is distaf changes to do the above
14:26 ndevos pranithk: of course, and maybe be able to show diagrams of the xml/json too :)
14:27 pranithk ndevos: yeah that is the plan.
14:27 pranithk ndevos: It will also be able to compare memory usage per xlator, per data type between two releases side-by-side etc.
14:28 pranithk ndevos: that is my plan...
14:28 ndevos pranithk: I would love to have something that we can put on https://ci.centos.org/view/Gluster/
14:29 pranithk ndevos: okay...
14:29 pranithk ndevos: brb
14:29 ndevos pranithk: try to get it in a release often, and have it incremental improvements, I'm happy to setup a job for it on the CentOS CI
14:31 mchangir joined #gluster-dev
14:34 pranithk ndevos: So what is the baking time for a small new feature upstream, before it can be pulled in a .x release?
14:38 ndevos pranithk: I would say none, we need to be more strict and only allow features in new x.y releases, not stable releases
14:39 pranithk ndevos: What about the features that are for stability?
14:39 pranithk ndevos: like throttling
14:40 pranithk ndevos: 10 months is too long Niels. Even if you want 2-3 months of baking on upstream it is fine.
14:40 ndevos pranithk: none, a feature is a feature
14:40 pranithk ndevos: I can't accept that answer
14:40 pranithk ndevos: That is just too slow
14:41 ndevos pranithk: when I count, the next release would be 7-8 months away, not 10
14:41 pranithk ndevos: which is still double the time I would like it to take
14:41 ndevos pranithk: well, it is also sad that the deadline for features is missed :-/
14:42 ndevos pranithk: we should not allow exceptions for features, and risk stability of a stable release
14:44 ndevos pranithk: deadlines were given in advance, and after discussing with all feature owners/developers, if after that the deadlines get missed, well, that is sad, but we should stick to the plan
14:50 pranithk ndevos: Okay. I absolutely hate this model of development. WIth that good night. Cya.
14:52 pk1 joined #gluster-dev
14:52 pk1 ndevos: wait
14:52 pranithk joined #gluster-dev
14:52 ndevos oh, I'm still there!
14:52 pk1 ndevos: If something as complex as kernel has 3 month release window. Why can't gluster have?
14:53 ndevos pk1: if we would have active maintainers that can provide releases, we probably could
14:53 pk1 ndevos: 6 months is absolutely sucky.
14:53 Apeksha joined #gluster-dev
14:53 ndevos pk1: also the kernel has some stable versions, making it possible for users to stay on a 'supported' version for a long(er) time
14:54 ndevos pk1: I'm not against doing releases quicker, but the 6 month cycle we planned already got delayed 6 months, we need more maintainers that feel a responsibility to get releases out
14:55 pk1 ndevos: now you are talking. Here is what I absolutely hate about gluster release process at the moment.
14:55 pk1 ndevos: there is no clear distinction between stable branches and baking branches
14:55 pk1 ndevos: If I want Lindsay or serkon to try new things I don't want them to wait for 6 months
14:56 pk1 ndevos: They are giving valuable feedback early and often. I want those things to mature as quickly as possible
14:56 mchangir joined #gluster-dev
14:56 ndevos pk1: yeah, we're abusing the stable branches at the moment, and I am of the optionion that it is very wrong
14:56 pk1 ndevos: Yes, me too.
14:56 pk1 ndevos: So the existing model is either breaking a stable branch or coming in the way of maturing a new feature
14:57 pk1 ndevos: At the moment you are looking for a stable branch I am looking for maturing a new feature. Hence the conflict of interests
14:57 hagarth should we rescind the ability for regular maintainers to push patches to release branches?
14:57 ndevos pk1: yeah, and breaking stable branches gave us much bad credit, I hope we can get it better with 3.8
14:58 hagarth I am personally not very happy with the number of patches getting merged into 3.7.x
14:58 pk1 hagarth: ndevos: I think we need a clear demarkation of stable vs maturing branches
14:59 ndevos pk1: yes, I also like users to test new features and give feedback, shorter release times would be helpful for that
14:59 shyam joined #gluster-dev
14:59 hagarth but more branches would need more maintainers
14:59 ndevos pk1: when we have more regular releases, the release-* branches really should become a stable version, security+bugfix only
15:00 pk1 ndevos: exactly and serkon wants to test multi-threaded self-heal as soon as possible. I can't tell him come back after 6 months and we can give that to you.
15:00 hagarth how about having "master" as the maturing branch and create releases from there?
15:00 pk1 hagarth: Here is the thing.
15:00 ndevos pk1: some users accept to test from the master branch, we do have nightly build RPMs for them
15:00 pk1 ndevos: They like to put things in production if things are okay too ...
15:01 hagarth pk1: more reasons to keep master stable
15:01 pk1 ndevos: keeping a branch stable has its perks and cons as well
15:02 ndevos pk1: more regular releases in the case, or have the feature included as experimental and improve it during the life of the release
15:03 ndevos hagarth: keeping the master branch stable is a tough task, nightly updates would not be allowed to break things, I do not think we can commit to that
15:03 hagarth ndevos: the latter is what we are seeing with sharding, tiering etc. in 3.7.x
15:04 ndevos hagarth: yes, and accepting features as experimental is where the line is drawn, if not experimental in x.y.0, its moved to the next release
15:04 pk1 hagarth: We need stable branches and feature branches.
15:04 pk1 ndevos: Yes moving to next release is 6 months which is too big
15:04 hagarth pk1: unless we have more people volunteering to maintain branches, I am not in favor of creating more burden on anybody
15:05 pk1 hagarth: We can run the feature branch like we ran 3.7.x
15:05 ndevos pk1: we need to find a solution for users that want a stable version for their storage, and something that evolves faster
15:05 pk1 hagarth: we can run stable branch by a single release lead
15:05 ndevos pranithk: maybe like, 3.8 is considered stable, 3.9 follows shortly and is more experimental, 4.0 is stable again, etc...
15:05 pk1 hagarth: Based on feature branch testing by users, we can backport them to stable branch
15:06 hagarth pk1: the latter model is broken. Nobody backports to a branch by a single release lead. I would not want our release leads to be frustrated by lack of action in their branches.
15:06 pk1 hagarth: that might work!
15:06 pk1 ndevos: Sorry, yes that might work
15:07 pk1 hagarth: I think the life-cycle has to be master->feature-branch->stable-branch
15:07 hagarth pk1: we need more involvement from everyone to let our plans be successful. else we can plan, but will find it hard to execute :-/.
15:07 EinstCrazy joined #gluster-dev
15:07 ndevos pranithk: I still do not like to see backports of features to stable branches, that is still dangerous
15:08 pranithk ndevos: hagarth: brb
15:08 ndevos pk1: if a feature gets stable in a "feature branch", that gives a good confidence in the next version
15:08 hagarth ndevos: if we have a shorter cycle for 3.9 .. we might not even want to create a branch
15:08 hagarth just keep tagging along in master
15:09 hagarth we could keep those tags stable and recommend users to adopt releases corresponding to those tags
15:09 hagarth the overhead of maintaining a branch is substantial
15:09 ndevos hagarth: I do not think so, that would mean we can not break anything in master, or make real huge changes
15:10 hagarth ndevos: yes, ideally we should not break compatibility changes in the lifetime of 3.9.x
15:10 hagarth ndevos: for example, compatibility between 3.7.x and 3.8.x is broken now in master
15:10 hagarth ndevos: but we would in any case need to fix that for 3.8.x
15:10 shaunm joined #gluster-dev
15:11 hagarth so we have to be more careful while developing code to not break compatibility even on master
15:11 ndevos hagarth: yeah, but when we provide users with builds from the master branch, this would be a critical problem, we should not go there
15:11 hagarth ndevos: we need to improve our development and review process. It is a departure from the norm and I think we can make it work.
15:13 ndevos hagarth: I think we can make it work "mostly", but as soon as we break the storage deployed by a user, we'll have a big problem
15:15 hagarth ndevos: why do we have to break on master? we need to tighten the norms for acceptance there. if it breaks on master, it will break on the release branch too.
15:15 hagarth we will spend an inordinate amount of time trying to stabilize the release branch if we let the mainline be affected easily.
15:16 ndevos hagarth: I'm sure we'll break things without intending to, and at least a glusterd to 2.0 move will be difficult
15:17 hagarth if we declare 3.9 as a feature release train, would serious users want to use that in production?
15:17 ndevos according to pk1, yes, users want to run new features in production
15:17 * shyam throws his hat into the fray! (having read the chat logs till now)
15:17 hagarth ndevos: yes, they are doing so at a known risk by adopting bleeding edge.
15:18 hagarth here is a possible scheme of things in my mind:
15:18 shyam I agree that we should not be doing feature backports to stable branches, too much risk in destabilizing the branch per se
15:18 hagarth 1. 3.8 goes out in June
15:18 hagarth 2. 3.9 a feature release goes out in September
15:18 ndevos hagarth: I think the current release+experimental is a nice approach, we could shorten the release time and only provide longer term 'support' for some releases
15:19 hagarth ndevos: yes, that's what I feel too
15:19 hagarth 3. 4.0/3.10 stable happens in December
15:20 shyam hagarth: It would be better if the cadence was regular, the feature -> stable is 2 months as per the above
15:21 hagarth 3 months
15:21 shyam Why not every 3 months
15:21 shyam hagarth: Hmmm... ok
15:21 hagarth september - june = 3 ;)
15:21 ndevos do a release every 3 months, and only call one every 6 months stable?
15:21 shyam Yup :)
15:21 shyam yes, and only support stable (that is important)
15:22 hagarth ok, what is the purpose of a feature release? ostensibly to get more feedback?
15:22 shyam The thing is we also want the users to pick out the non-stable/experimental releases, so that they can provide us with feedback, that can help stablize it. Will that happen?
15:22 ndevos yes, that is the main purpose
15:22 shyam yes
15:23 * ndevos needs to catch a train, will read the logs later
15:23 * shyam possibly needs to break for lunch soon
15:23 hagarth maybe we should move this discussion to maintainers
15:24 hagarth so that everybody has a chance to chime in
15:24 shyam hagarth: ok, you beat me to it ;)
15:24 hagarth :)
15:24 ndevos yes, we definitely need a summary shared with others
15:24 hagarth we will let pk1 propose a scheme ;)
15:24 hagarth continuing with our trend of having AIs on folks not around ;)
15:25 hagarth #action - pk1 to send a proposal about possible changes to release scheme on maintainers ML
15:25 hagarth :)
15:28 atalur joined #gluster-dev
15:29 pranithk hagarth: there?
15:29 hagarth pk1: yes
15:30 pkalever joined #gluster-dev
15:30 pranithk hagarth: I like this approach.
15:30 pranithk hagarth: stable release. take the next release for features that need stabilitzation
15:31 pranithk hagarth: next release after feature-release is again stable release.
15:31 pranithk hagarth: We can even have users vote saying a feature is stable etc.
15:32 pranithk hagarth: Like Lindsay did that with sharding
15:32 pranithk hagarth: Where we termed 3.7.9 stable with sharding
15:32 pranithk hagarth: when this happens it can go into next stable release
15:35 hagarth pranithk: right
15:35 hagarth pranithk: can you put a quick draft about this proposal and send it on maintainers?
15:35 pranithk hagarth: I can do that after going home. Still in office. It will be too late. So may be tomorrow.
15:36 hagarth pranithk: no hurry ..quick referred to you not needing to spend a lot of time doing the proposal :)
15:36 pranithk hagarth: okay, will do it tonight/tomorrow...
15:37 hagarth pranithk: cool, thank you!
16:13 post-factum oh, those feature-based releases...
16:13 post-factum iirc, linux kernel abandoned that approach with 2.6 release
16:21 ppai joined #gluster-dev
16:33 penguinRaider joined #gluster-dev
16:38 ndevos post-factum: it seems to be a time-based approach, where every odd (or even) release is used for feature testing
16:39 ndevos it is not very helpful for anyone to have more than 10 features per release, who would be able to decently test that?
16:41 spalai joined #gluster-dev
16:42 spalai1 joined #gluster-dev
16:45 post-factum ndevos: oh, ok
16:47 kbyrne joined #gluster-dev
16:47 rastar joined #gluster-dev
17:02 shubhendu_ joined #gluster-dev
17:07 dlambrig_ joined #gluster-dev
17:09 aspandey joined #gluster-dev
17:09 gem joined #gluster-dev
17:14 ashiq joined #gluster-dev
17:18 hagarth joined #gluster-dev
17:19 kkeithley_ Release Early, Release Often. Isn't that the Open Source mantra? We're over six months late with 3.8. Why? Because there's always one more Must Have feature that it would be nice to have in. We have a six month release cadence. Everyone knows this. If you want your feature in _this_ release, then make sure it's ready, on time. Downstream depends on having a steady stream of upstream releases, a steady stream with a small/medium/la
17:25 kotreshhr joined #gluster-dev
17:25 kkeithley_ As for adding new features in during the lifetime of a Minor version i.e. 3.8.x? My only concern is that  we don't break anything by adding the new feature. If you can guarantee it won't won't break things, then okay. If you promise it won't break, and then it does, you lose all your karma. One awshit wipes out all the attaboys.
17:27 kotreshhr left #gluster-dev
17:33 ashiq joined #gluster-dev
17:33 rastar joined #gluster-dev
17:34 gem joined #gluster-dev
17:35 shyam joined #gluster-dev
17:38 kbyrne joined #gluster-dev
17:39 bfoster joined #gluster-dev
17:45 post-factum why not picking one or two lts per two years and make new release each 3 months regardless of merged features?
17:49 rafi joined #gluster-dev
17:51 hchiramm joined #gluster-dev
17:52 gem joined #gluster-dev
17:56 kkeithley_ post-factum: fine by me. The Community needs to agree/decide that that's what we're doing.  Previously it has decided we will do a release every six months.
18:06 rafi joined #gluster-dev
18:37 luizcpg joined #gluster-dev
18:37 luizcpg left #gluster-dev
18:44 post-factum vote :)?
18:58 hagarth joined #gluster-dev
18:59 jiffin joined #gluster-dev
19:00 rafi joined #gluster-dev
19:08 shubhendu_ joined #gluster-dev
19:10 rafi joined #gluster-dev
19:12 nishanth joined #gluster-dev
19:16 dlambrig_ joined #gluster-dev
19:27 pranithk joined #gluster-dev
19:31 dlambrig_ joined #gluster-dev
19:32 rafi joined #gluster-dev
19:38 shyam joined #gluster-dev
20:38 dlambrig_ joined #gluster-dev
20:44 suliba joined #gluster-dev
20:44 Gaurav_ joined #gluster-dev
20:48 hchiramm joined #gluster-dev
20:57 penguinRaider joined #gluster-dev
21:54 penguinRaider joined #gluster-dev
21:54 dlambrig__ joined #gluster-dev
22:01 kknoppf5_ joined #gluster-dev
22:23 bfoster joined #gluster-dev
22:45 kknoppf5_ joined #gluster-dev
22:46 kknoppf5_ hi, trying to find documentation or info about node_state.info

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary