On Thu, 01 Mar 2018 19:28:15 +0000 Stephen Houston <smhousto...@gmail.com> said:
Hi! So I was busy with some work and didn't want jump into this in the middle. I also allowed for some feedback from others too. I've read over some of these, and I actually have little to say about the feedback other than "Yup. I pretty much am with you there", so I won't reply to those mails, but I did read and digest them. So, response time: I'm not going to go into history and past, point fingers etc. etc. . I'm going to address how things should be and what my opinions are. 1. Code reverting. I take API breaks seriously. An API break shouldn't happen. It should get caught as soon as possible if it does before anything is built on top and that may mean reverting work that created a break ASAP if that is the most efficient path. More generically here is the order of bad things for git master: #1. Builds break. #2. Building against X breaks (e.g. building terminology or e against efl). #3. The app or lib just crashes or doesn't work in regular usage leaving people with an unusable environment #4. API/ABI breaks (code, data files, theme etc. - we only do these with a lot of careful thought, discussion and weighing up of the pros and cons). #5. A new design or idea/direction that then will be built on top of and if #this design/idea has big issues. git master should be "usable day to day" for developers and "advanced users". It will get bugs and issues but they should be resolved ASAP and avoided as much as possible. The longer bad code stays in, the harder it is to revert or fix as more and more changes are built on top. Time is of the essence. If someone wants to make major changes that change direction, design, etc. etc. then discussing first is a good idea, and realising that it may not be right or perfect and may need to be fixed one way or the other, but the worse it is on the above scale, the more likely it needs to be addressed ASAP. Consider these the rules of engagement. Don't break stuff. If you do then expect swift action to counter it. Don't like that? Then don't break things. 2. Decisions/Management I have to agree with what has been said. I don't think some kind of committee and formal "management" can happen on an OSS project without basically ripping out the heart of that project. Comments have been made about the politics of voting for leaders and how this just creates new issues. My take is this: People who do the work get to call the shots. It is of course affected by history of contribution, knowledge of the project and what it interacts with etc. etc. ... I do not think having some committee of project managers is going to make anything better. I think if anything it just makes things worse by adding overhead. If we made everything code-reviewed ala phab, I think it'd be far worse. development would dwindle and die. I absolutely know that I'd personally just stop if I had to put every commit I do through review. Review is a tool for developers who are not trusted yet or who need to learn or who are not involved deeply enough to be held responsible for their work. Then I believe the cost is justified. What I have seen is commits that were objectively bad (e.g. break API) or were arguably going the wrong way, and those get addressed based on severity etc. but what seems to be the issue is that such work was made without discussion then people get very upset when there is disagreement or their work is pointed out to have had core issues. I don't see how any project management etc. will change this. People need to objectively look at what they do and why others might reject it (via review or revert). I never revert without my log containing good reasons. I revert when the issue is bad enough to require it. I have noticed that often there are commits with major changes with no information in the commit log as to the reasoning behind such changes. So I'm going to add another rule of engagement that people see to be ignoring: * Your commit log must contain information as to WHY you did this. Someone reading the git commit log needs to understand what was going on and WHY. If the patch/diff is trivial then often the log only needs 1 line. Sometimes it's a major change and it needs explanation as to WHY. The less information you provide in your commit, the more likely it is going to be looked on poorly. That also goes for patch submissions+review. It's about communication. Communicate appropriately before you make changes. Communicate with the changes. And be around to communicate after the changes. Without communication things will fall apart. This requires people actively make use of e-mail, IRC, phab tasks, etc. etc. ... as long as there is reasonable amounts of it so people know WHY something is going on. Keep in mind. This has nothing to do with personal goals but to do with the health of a project and it's code base and changes. My priorities are to try protect those. 3. Communication I don't think we need STRUCTURE. I think we need communication. I think people have become awfully bad at this. Here is what people need to do IMHO. a) Bring up ideas, problems, goals, concepts in public. IRC for fast back and forth iteration. e-mail for slower, put up a wiki page for a longer document and description. phab tasks for tracking something in detail. etc. b) Bring up things before spending time on the code. Specifically if it's "non-trivial". Ideas of what trivial and non-trivial are may vary, and be prepared for dissention. c) Keep in mind history. That goes from coding conventions, to design and naming of files, functions, data etc. through to API etc. ... changing such stuff on a whim often has consequences. Communicate about ideas to change this first. 4. Writing down goals This kind of falls under communication but I'll make this explicit. This is probably where I haven't done much. I've hoped people will bring great ideas of their own. Things they believe in and then "sell them" to existing developers and then do them. But I haven't really been clear about what *I* want to see from E and EFL. To be honest it has evolved over time, but I'll quickly jot these down here as a current state: a) E started with making a FANCY UI ... and that is still what it is about. EFL too. to make fancy totally out-there GUI designs possible even with just the change of a theme file being dropped in-place. b) E started as just a WM, but unlike the WM's of the day it did far far more. It basically was a desktop environment minus the actual applications. I still want the same, but now want E to work like a charm on not just desktops, but laptops, tablet convertibles, pure tables, phones etc. etc. with a mouse and keyboard, or touch, or buttons etc. ... with the addition of now being able to provide apps because EFL makes that possible now c) I want E and EFL to be efficient at what they do and yet still not give up being fancy. Deciding on the line to draw here is hard, but c) d) Everyone can argue about languages all day long, but supporting as many as sensibly possible is important for EFL. It opens things up to many more developers. This is why EO/Interfaces is important. To some extent I think it's kind of gone too far and it making using EFL in C far more painful than the legacy API's and this needs to be addressed before any stable release is out. C is still the core language of EFL and E and it shouldn't suck just because a binding is a "little nicer". But still - supporting more developers is important and supporting their languages and operating systems too e) Continuing from above, I'd love to see a trivial "make an E app" scheme with simple tools to start the app project and fill it in with a templated (edi did start with this), and provide at least some languages supported at this point, then the ability to upload, and share that app, and for users to download and install it as a user without root and without having to worry about what OS or distribution they are on. f) I still think E should have the filemanager built in. It's far too useful to not do this. It's pretty much necessary for icons on the desktop and consistent FM UI. If its done in-process or outside is another matter, but it has to be deeply integrated. g) I think we should have a powerful GUI, but there should be some effort to make it easier to use. A lot has organically grown and needs a review and re-do. h) I think at some point we may have to do our own distro that integrates E well and shows it off out-of-the-box. This is a huge amount of work and it's only sane to do piggy-backing off an existing distro (arch, debian, fedora, whatever). But we need to show E off pre-packaged and configured to be just-right. Perhaps some Rpi images where the hardware is fixed and known and maybe a bootable and installable ISO too for x86? To make this ebentually all work out well we need system config tools (gui time/date/ntp/locale config for the OS, gui user management tools, gui package management/system update tools, a gui installer front end etc.). i) fill in more apps. we have a solid terminal emulator. a good video player (does music too but not well). a good photo viewer. there's a media center too which i don't know well enough to say much about. a start of an ide, irc client, a matrix client was being done by indefini, a pdf viewer (needs work), text editor, calculator and more ... some of these apps are well polished now, others need a little more polish, some need some real hard work. we could do with a web browser (re-use blink or ewebkit - ensure it is compiled and shipped so it can be sued as a web view and a browser core). an email client would be nice too. you get the drift. fill in the apps. i'm sure many people have their own ideas and priorities on what they think is important/right. i'm just dropping the above out there. if you want direction and can't submit your own instead, then look at the above and expand on it as logical. but either way: COMMUNICATE. ----- > I've been pondering writing this email for some time now. As others have > mentioned - our community has been trending downwards. Work from Samsung > aside, and those that use E/EFL through Samsung's work -- The developer and > user base has been getting smaller and smaller. That is regular members of > the community contributing work and regular members of the community using > E/EFL as an option for their linux desktops/laptops. The number of > arguments that are now occurring among those of us still left has been > rising. The current state of the project is such that dissenting > opinions/code are not allowed and get reverted or overruled in discussions, > this likely directly related to our structure and our lack of documented > road maps, goals, and plans. > > This project has been around for decades. Many of our developers have > spent blood sweat and tears adding code to this project and working on it. > Many of our developers have poured just as much code into this project as > the next has. The project has become so much more than just one person's > vision or one person's opinion. As it is the project is really not set up > to handle this. There is no clear decision tree. No clear path for what is > and is not accepted. No clear direction of what the goal is to > accomplish. This has been leading to so much animosity, and frankly a > stagnant project that is dwindling instead of growing. Sure plenty of code > gets written, rewritten, or worked on, but the majority of it is not seen > in the product. It is working on rewrites for performance, bug fixes for > corner cases, implementing new apis that are not used anywhere, etc..., > etc..., and all of that is fine and necessary, but other very important > work gets left out. Take Enlightenment from late 2000s - now. A lot of > work has been done. Compositing, Wayland, e_widgets -> Elm, etc..., etc... > But in the last say 10 years... You could pull up versions of Enlightenment > and without a technical sense or from someone following the project, you > would think it is the same... Same menus, same settings, same gadgets, same > shelves, same themes, same look, same interface, etc..., etc... EFL > consistently is worked on and sure is doing really cool new stuff like > Interfaces... but does it matter if no one is even using it? (Samsung > aside). We have 3 or 4 applications that we have always had and there > seems to be very little growth. We have people who have decided to fork > off work or go their own route... see Moksha, Fyne, etc... due to problems > within our community or our vision. This is difficult for a community like > ours to overcome when and if we lose users when we already have few to > begin with. > > I believe it is time that we as a community revisit ourselves and consider > restructuring. Projects can't just be YOLO with no clear laid out > direction or plan. Community based projects can't succeed in an > environment where there is seemingly no project management and discussions > only happen when a feature or change is pushed and one person overrides > it. This project needs to have more project management. Goals need to be > laid out. Road maps need to be developed. Release plans need to be > created and adhered to. This project needs structure, and frankly this > structure needs to come from more than just one person. There needs to be > a team of project managers who determine whether changes, features, or > proposal are accepted, not only one person. There needs to be a team of > project managers determining the direction of the project and developing > road maps for it. This team needs to be represented of our developers, our > corporate interests, and our community user base. Having a team will keep > from personal bias, desires, or egos getting in the way. Once we have some > structure in place, it will become much easier for us to band together to > work towards meeting our goals. > > As it is - It really feels like if we continue on the path we are on, the > future is not bright at all. If we treat this project's goals as whatever > meets the desires or ideas of one or two, that is what it will eventually > become - a project used by one or two. I'm pleading with everyone to put > egos aside, put personal ambitions, personal goals, and related aside and > begin working as a team. The current climate will improve dramatically if > that happens. > > Before you get upset and respond angrily at this email, remember I love > this project and have worked on it for over 15 years and developed > relationships with most of you along the way, and so I am in no way sending > this email with ill intent or to anger or hurt anyone. I'm sending this > email in hopes that we can only improve as we move forward. > > Thanks, > Stephen > ------------------------------------------------------------------------------ > 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
