On Tue, 21 Aug 2018 10:48:19 -0500 Stephen Houston <smhousto...@gmail.com> said:
> First off - There were a lot of emails about the proposal process with > instructions on how it works - as well as phab ticket and slowvote with > instructions for how it works there as well. From Raster's email it seems > he still didn't read the instructions because he still voted thinking he WTF? read netstar's email and the ticket. no instructions. > was voting for "the least bad option", when in actuality not voting meant > approval. This isn't a bureaucracy of choosing what can be worked on. All read the emails i responded to... the "FAQ". they sound just like "you need to put in a proposal for any major work that isn't simple bug fixing etc.". not doing so is not in the release plan and by implication will not be accepted as a result as it's "needed" (that is the word used - "need" == must == required). > you had to do was put forth proposals of what you wanted to work on (and > you still can), and the proposals are automatically in the "Accepted" > category with no bureaucracy involved. Thus the only purpose for the vote > being to make sure that the rest of the community doesn't have a huge > problem with any of the work that would move it to "Unaccepted" (thus you that's certainly not what the mail reads like. a huge success with the voting implies that it's significant feedback giving guidance etc. as to what to do. thus voting has significant participation. i've already seen the responses on the ticket https://phab.enlightenment.org/T7283 "How do I add items to the voting?" "You cannot. The proposal window is closed for this round of voting. 5 weeks from now there will be a second round of voting to include additional features which are proposed at that time.". So have to wait 5 weeks to propose something to know if it will be accepted so you can do some thing you want to do? this is why i am calling it bureaucracy. be it a vote for or against - it's the same - an approval process. > voted and commented if you did). It would take a lot to get a proposal > unaccepted, obviously. All proposals were accepted - It wasn't a choose a > proposal vote ... It was "this is what has been proposed, and of course we > will accept all proposals unless enough of the community finds a proposal > disgusting enough to vote against it or say no". then explain the polls https://phab.enlightenment.org/V36 and https://phab.enlightenment.org/V37 ? a proposal isn't accepted until people have gotten their "veto" votes in to say no, so, it is an approval process nevertheless (that is broken as you can only veto 1 thing and you can't remove that once given accidentally). > Second - Raster, if you remember we had IRC meetings ran by you where the > community got really involved and we discussed and voted on some key > issues. You agreed to handle the release process in place of Stefan since > he was going out of town. Then you just kind of disappeared and there was because you were being arseholes to me when i was trying to get some semblance of quality in place for a release. that 100+ unbisectable branch dropped with no notice and everything was broken on all my machines (other people too). i spent a full day trying to bisect and unable to narrow down what change did it. i bring it up and that this is a bad way to do things and someone who knows what might have caused it needs to narrow it down or it gets reverted so release can go forward... and all it turned into was a "fuck you raster. you were mean to cedric". doing a release means sometimes being mean and saying no. it meansa telling people off when they do something bad so they don't do it again (and others don't). cedric did nothing to help find it and walked off (which is what i feared was going to happen and i was right). i spent some time trying to narrow down what it might be other than going through commits and eventually realized with gl off it worked and started asking others to confirm - it took me days to figure that out. go read that thread. go read the end where i was going on holiday (which i said i would first half of july when we discussed doing a release) and i wanted an alpha out before i did that, but the above just made me throw in the towel and walk away because everyone (almost) was up in arms. the decision to revert if no fix comes through so we could get something out and little else was being done was pushed back against. there was minimal activity on something that was incredibly showstopper-like. if dropping 100+ commits from a branch without notice that don't compile or run (see previous thread) is considered fine and instead you have a go at the person trying to get problems fixed and discourage them from happening in the future, then why bother doing a release? instead you guys send the message as "be nice to cedric" despite this being a pretty big failure by someone who should absolutely know much better. i'm not going to herd cats that just turn around and bite you for doing the herding. you were part of this yourself. you would have seen my response of "going on holiday and i have a good mind not to come back at all". you got the notice. you were one of the causes. instead of focusing on the issue you decided to make it personal and go after me. the problem is that this kind of thing should not happen. big branches of work should not land without adequate notice. i dread the landing of any big branches because again and again everything goes to hell when they land to varying degrees (multiple bugs all at once and sometimes serious ones). a big pile of work has to then be dug through to find the cause. work shouldn't be done to be unbisectable. it should not be an example to emulate. it should be one to point out and say: "that there? do not do that". now you are trying to turn this around and blame me for your (and others) behavior that led me to not revert and be unable to do an alpha release and just walk off in disgust. so we're getting to fork in the path. either i go and leave e/efl behind, or the kind of shit like above stops happening. the snide remarks from mike about "you skipped the review process" with implications that that is required stop. the attitude from mike of "well my commit that broke things is fine and your commit that fixed it that may have then broken the other thing i was trying to fix needs a revert" as if his commits have priority and he can break things, but others moving things back to the state they were in before that are bad and need a revert? the incredibly poor judgement call of putting in "if user == raster" into enlightenment code last year and never even an acknowledgement that "that was a mistake" ... the arrogance oozing out of all of this, and so on. i've been clashing with mike lately and this is not going to go well. things like "We've just completed our first round of voting (https://phab.enlightenment.org/T7283). The process was a success overall" which whitewash something to have legitimacy that it clearly does not (see the repeated responses about confusion and the inability to undo a vote - comments not by me even). so e/efl community is pissing me off severely of late. some people specifically (you included - see above about the branch dump, and now you've irked me again by trying to point the finger at me when i clearly couldn't do an alpha in that state etc.). so i go, "you go" (plural you) or this gets sorted out. if i go, it's to part with e/efl for good. > no involvement from you so, all of the sudden, we had to pick up the slack > on the release process and do what we could. What we found was a process > that really worked - Triaging phab tickets appropriately using tags, code > review being handle by all, both submitting code for review and > reviewing/landing, triaging feature tickets for future releases as to not > obscure the work needing to be done for 1.21 release. We did a lot of work > in a short amount of time to really improve the release process and work > with what he had. From our experience this worked so well that we > expounded on that and set forth a plan for the 1.22 release that included > this proposal process. this is how all the previous releases were done. stefan went through tickets and brought them up on the mailing list. ensured they have a proper severity (high, showstopper etc.) and asked people to look into them, handles responses on them as needed. code was not submitted for review but that doesn't make much of a difference one way or another. he also did abi checker runs, did distchecks and more. i did the distchecks too, ran test suites, looked at coverity issues and fixed them so our coverity issue score went down every release for years. devilhorns and others i remember did this too. this is the first release in many years where the coverity bug rate per 1k lines of code went up. review doesn't seem to make a difference. reviewed patches went in that broken the build (specifically make doc for example). > >From my perspective - and the perspective of a lot of people involved - the > recent structure and process of how we are handling the code base, > releases, features, bugs, etc..., has been wildly successful indeed. I > encourage you to look at code review and see just how many patches have > been submitted and accepted and how well that process has gone. I > encourage you to look at how phab was triaged to provide a clear goal that > we were able to achieve in a short time to release 1.21. I feel confident > that expounding on this process we used to get the release out and using it > for the entire life cycle of 1.22 development, it will only become even > more successful. > > If you would like to offer "big pushback" or you "seriously dislike" where > things are going - I encourage you to try to understand it first - which > I'm sure you did from the way you misunderstood the proposal process. I > hope we can talk about this all amicably and come to an agreement going > forward. you can see above that this email thread + tickets say "you need to propose and wait up to 5 weeks or however long until the next vote to know if it might be vetoed". "need to" is a requirement. a must. that is the language used. the vote was called very successful which i would say is misleading at its beast. it seems to legitimize something that is pretty broken. taken as a whole it is describing a bureaucratic process that takes weeks that is needed to do any work on efl. i dislike the tone and its direction because of this. thus i push back. a heads up on things people are doing - great. a todo list for people to pick items from when deciding what to do and they don't have something of their own? great. a 5 week wait to see if you can start something (maybe less but up to 5 weeks)... no. a requirement to do this? no. > On Tue, Aug 21, 2018 at 10:25 AM Christophe Sadoine <ch...@indefini.org> > wrote: > > > On Tue, 21 Aug 2018 at 09:17, Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > > > > On Mon, 20 Aug 2018 08:15:48 -0400 Mike Blumenkrantz > > > <michael.blumenkra...@gmail.com> said: > > > > > > > Hello, > > > > > > > > We've just completed our first round of voting ( > > > > https://phab.enlightenment.org/T7283). The process was a success > > overall, > > > > > > what on earth.... a success overall? how can you claim this? 2 polls. 1 > > had one > > > vote, one had 2 votes. in total 3 votes. they don't allow multiple > > choices. the > > > voting against was confusing to 50% of the people voting... and tbh i > > voted > > > only for the lease bad option because i disliked them all... > > > > I agree the voting was a bit weird. > > And I think there should only be a vote against a proposal if a > > consensus cannot be reached. > > People could just comment on the proposal task there if they are against > > it. > > I only see a need for voting if one wants to know what other > > developers would like to have the most for the next release. > > > > > > Q: Why proposals? > > > > A: Previously, EFL releases were like a giant pile of unrelated and > > > > uncoordinated work. There was no oversight and nobody knew what anyone > > else > > > > was doing. This methodology provides solutions to these issues and > > allows > > > > for a framework within which contributors can work cooperatively on > > > > features for each release. > > > > > > yet the community was happy and functioned. we got along like friends. > > had our > > > arguments and spats but functioned. > > > > I think that is where most people would argue that it is/was not > > functioning. > > Maybe it was before, but it looks like it isn't anymore... > > > > > i for one will happily approve any patches/work that is of value and has > > been > > > done well that is brought to my attention. proposal or not (if it's a > > patch > > > submitted). if someone wanted to add something they needed or wanted and > > it was > > > not proposed - more power to them. they are enjoying themselves doing > > what they > > > wanted. > > > > if someone wants to add something that was not proposed, it is fine! > > Just communicate about it... they can say "hey I am working on this, > > what do you think" that is just more communication right? I think this > > is what proposals are for. > > But like I said before I don't see why there should be a voting > > session against the proposals. There should be good reasons to be > > against a proposal first. voting seems too arbitrary. > > > > > a todo list for people to pick from if they are short on ideas or see > > things > > > there they'd prefer to work on is what is useful. this bureaucracy is > > not. i am > > > seriously disliking where you want to push things and consider this a > > big push > > > back. > > > > I think it is more or less what we agreed before in irc meetings, > > isn't it? maybe I've missed some. > > If you have a big feature that will change efl it seems normal to have > > a task (proposal) to discuss about it. (and small features do not need > > proposals) > > For example if there had been a proposal for the gadgets you could > > have said from the start you were against it (maybe you did and I > > missed it) instead of when it landed. > > Because they did what you described exactly, they worked on something > > they wanted and merged it. > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
