Page MenuHomePhabricator

Project Roadmap
Open, Incoming QueuePublic

Description

This ticket if for deciding what should be in the project roadmap. It was created from T6740.
If there is already a clear idea and no discussion, we can create it and close this ticket.
If you disagree with anything in this ticket please comment.

Where
The project roadmap would be a wiki article on the site.

Who/When
Who is going to maintain it? I think it should be reviewed when there is a release. The release manager could do it but it is already a lot of work (that is why we should reduce other work if possible)
Also someone has to start a first draft.

CONTENTS
I am going to take raster email to have a rough idea of a first draft.
I don't think other people expressed much about this. If they did tell me where. If you didn't please do

Project vision/philosophy

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)

To summarize : fancy themes, e/efl working on desktop but also everything that has a screen, efficient, fast and fancy.

Support other programming languages through interfaces

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

Make it easy to create, share, download an app whatever your platform

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.

Have a filemanager builtin for e

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.

Make the ui easier to use

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.

Make a distribution to show off enlightenment

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.).

Make more apps

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.

indefini created this task.Mar 10 2018, 5:22 PM
jayji added a subscriber: jayji.Mar 14 2018, 3:27 AM
raster added a subscriber: raster.Mar 30 2018, 9:12 PM

first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

Here's what I want :)

  • elementary : the possibility to make your own widgets easily and possibly share them.
  • edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.
  • engine : more opengl/vulkan api support, opengl win engine.
  • enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.
  • less bugs :)

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

I think you should write more precisely what you want this roadmap to be.
The first part about project vision is exactly what you said, but the rest is more like goals (and not "about us/philosophy") discussed by raster.
This is an overall project roadmap. Imho, it's not particularly made for releases and work but more for seeing where the project wants to go.
I discussed about a roadmap/ticket for each release in the original ticket T6740.

jayji added a comment.Apr 6 2018, 11:52 PM

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

This is exactly how I feel about the roadmap :)

first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

Here's what I want :)

  • elementary : the possibility to make your own widgets easily and possibly share them.
  • edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.
  • engine : more opengl/vulkan api support, opengl win engine.
  • enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.
  • less bugs :)

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

I think you should write more precisely what you want this roadmap to be.
The first part about project vision is exactly what you said, but the rest is more like goals (and not "about us/philosophy") discussed by raster.
This is an overall project roadmap. Imho, it's not particularly made for releases and work but more for seeing where the project wants to go.
I discussed about a roadmap/ticket for each release in the original ticket T6740.

Nothing in any of this is remotely a roadmap at all. "Project Goals" fine. Roadmap no. And it doesn't help in the slightest stir up interest, get people on board, better structure the project, provide expectations, create reasonable timeframes, provide a synopsis of what people should help with, or improve communication and decision making. It much more feels like notes taken by a teacher of students brainstorming for the class project, when in reality, the teacher has already decided what the project will be.

At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.

Anyhow, your list of what you want is good.
What I want:
A real roadmap (Along with a lot more formal structure in place).

Nothing in any of this is remotely a roadmap at all. "Project Goals" fine. Roadmap no.

This ticket does not really describe a roadmap. Maybe I should change the title but, it says that it is for deciding what it is in the roadmap. What I wrote is just a draft from raster's email, because you have to start somewhere.
So I want to ask you if it is possible to write something like a skeleton of what you really want. If you don't, or someone else doesn't, this ticket will stagnate.

And it doesn't help in the slightest stir up interest, get people on board, better structure the project, provide expectations, create reasonable timeframes, provide a synopsis of what people should help with, or improve communication and decision making. It much more feels like notes taken by a teacher of students brainstorming for the class project, when in reality, the teacher has already decided what the project will be.

I think the current text (for the project overall roadmap) can:

  • stir up interest and get people on board : because of the goals and the vision.
  • provide expectations in the long term
  • provice a synopsis of what people should help with in the long term : also it can but it's more like features

It cannot:

  • better structure the project
  • create reasonable timeframes
  • provide expectations in the short term
  • provide a synopsis of what people should help with in the short term
  • improve communication and decision making.

That's why I proposed to do a roadmap per release in the original ticket. Each release roadmap would and should provide what the project roadmap can't.

At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.

I agree. I think most people are not interested in management and can endure the problems that comes with no structure.
The original ticket has no activity for a month so I will update it soon to say what should be decided or given up etc.

Maybe most people want a roadmap, but they don't feel the need to participate to it? or they might propose changes to it later?

Well after all the noise about needing/wanting a roadmap, it's disappointing to see how little desire there really is when it comes down to participating in the content. Do people just want me to tell them what to do and issue orders? My experience is that that doesn't work well as people will work on what is a priority or is interesting to them when/if they are willing to. What I hoped to gather is some of that information, because otherwise it'll just end up my personal TODO list. :)

But it's also really vague as to what people want a roadmap to say. Should it be general goals and things to work on or more of a schedule? I hoped that this would explore that. The roadmaps I have seen are more of a wishlist/TODO list and they may give a goal like - would like X for version Y. As we had been doing timed releases, I don't think that feature X for version Y is what we want and we should go back to timed releases as soon as it's feasible to do so. So long-term I just see a rodmap as a TODO list of things that would benefit the project, users, developers or development. Thus what I did was try start the conversation with that - a rough TODO list.

Here's what I want :)

I think that's a great start - people putting their desires down and either no one objecting, or some disagreement and then discussion on why and what to do. Perhaps some prioritization at some point. I'm thumbs up except for 2 of your items:

  • edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

  • enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

create reasonable timeframes,

That is unlikely to happen. If people spend whatever time they have on things you cannot have a timeframe. Even if people are paid fulltime this just doesn't happen. And it's not E or EFL alone. Look how long "Wayland will be our desktop next release" happened to many projects and it took multiple years instead. Look how long Firefox has been working on moving to rust and their new engine and just never finishing when they hoped. Look how many years "kdbus would be coming soon" and still hasn't. This is just how things go everywhere. You get my point. I don't like to make promises I can't keep, so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

It much more feels like notes taken by a teacher of students brainstorming for the class project, when in reality, the teacher has already decided what the project will be.

At this point that's almost insulting. To both @indefini and me. The whole point of this ticket to to have people actively participate, and you basically are not doing so. You have nothing to say about what a roadmap should have for you, nor what tasks are important to you etc.

What I want: A real roadmap

Then describe what you want. I have described above what I have seen described as "roadmaps".

(Along with a lot more formal structure in place).

We have a lot already. Perhaps you just don't like it, but we do have it. Perhaps you could elaborate to make this conversation valuable?

What I wrote is just a draft from raster's email, because you have to start somewhere.

Indeed. Things have to start somewhere. That was the whole point. Start a conversation.

That's why I proposed to do a roadmap per release

And that I think is something down the road after a longer term bigger picture "roadmap" is discussed. And as it would change continually e.g. from release to release, it's a conversation to keep having all the time and I think it's wise like you said already to separate that out as a separate task.

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

  • edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

  • enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

  • edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

  • enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management. That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management.

Then where are they? why did they not subscribed to this ticket and said "I want to do it, I want to maintain this project roadmap".

That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management.

Then where are they? why did they not subscribed to this ticket and said "I want to do it, I want to maintain this project roadmap".

That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

I'm not complaining here -- The problem is, going back to even reading the original ticket you created -- Time based or released based road maps are not of interest to those responding, including raster. Which is why I said -- people can't agree on what, when, how. We can do this wish list that is this ticket basically is -- and that is fine -- I just don't feel it improves structure or management.

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

I'm not complaining here -- The problem is, going back to even reading the original ticket you created -- Time based or released based road maps are not of interest to those responding, including raster. Which is why I said -- people can't agree on what, when, how. We can do this wish list that is this ticket basically is -- and that is fine -- I just don't feel it improves structure or management.

Yes people don't agree and that's normal, not a problem we cannot fix. This is why there is discussion to find a consensus or convince one another. People cannot radically change the way they work or the way they think in an instant.
If you feel this ticket doesn't improve structure, but released based roadmaps do, you can discuss on the original ticket.

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I just don't feel it improves structure or management.

And exactly as @indefini said - you are totally unwilling to work on it but just complain. I asked 2 key questions above you didn't bother to respond to which would move things forward and just went back into complaining.

> What I want: A real roadmap
Then describe what you want. I have described above what I have seen described as "roadmaps".

and

> (Along with a lot more formal structure in place).
We have a lot already. Perhaps you just don't like it, but we do have it. Perhaps you could elaborate to make this conversation valuable?

@stephenmhouston: Stop complaining. Stop telling lies that fit your narrative. Be part of the solution, not be the problem.

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

Aaaah ok. The real problem is eet was designed for write-once, read many times, so writing is slow as it re-writes and re-compresses the whole file. if it only wrote/re-compressed the bits that changed it might be much faster. edje_cc doesn't have a "rewrite" mode either. just a "write it all out". To accomplish this, this end of things would need to be tackled. It's both in eet and edje_cc and it might be tricky and require compromises.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

They forked and heavily modified to "reduce size" and so they only want to work on what is relevant for tizen and not anything else. a "WM lib" would be large and have to address lots of uses and thus would be of little to no interest to that kind of path. Keeping compatibility is going to be a nightmare. I think it'd be in the end a waste of time as the only users would end up being us. That at least is my conclusion. It'd be a mountain of work, a mountain of ongoing work, and for just E ... :) I think EFL has about the right split of splitting stuff out of the WM into something generically useful. :)

I think I agreed with the struggling part

Well I don't think there is a struggle to get agreement in lots of areas. I think it's a struggle to get people to stop banging whatever drum they have and actually be helpful at all. you already pointed out. There is a lot of "complain" without any movement to "then what do we do?". At least you and me are having a productive discussion that actually agrees on various things already and is exploring more.

In the end maybe it's ok if just a few people make decisions about this?

Well that is what has happened in the past and the problem is now: "I don't like your decisions". A few decided on timed releases - INCLUDING me. That fell apart a bit hoping to get eo/interfaces done for a specific release. That's kind of been ongoing as that elephant doesn't move along fast. I and some others also decided on the model that trusted developers get commit access and review is done afterwards maybe with changes or reverts on the odd occasion the commit is an issue vs review for untrusted devs. I like that model as it speeds things up for core devs who do get things 99% right and once in a while mess up, yet keeps barriers in place for those not yet trusted to get things right. Review doesn't fix this. I have reverted or fixed patches that have gone through review as they broke things badly and I'm not sure the error rate is any lower there, so I think on balance we have something fast, efficient, yet with enough controls in place. I like fast and efficient. I dislike wasting time. Review takes up a lot of time and when the input hours vs reward value is not there, I like to skip it. Look at how many patches just end up in bikeshedding and end up going nowhere. I think this is devil you know vs devil you don't and neither path is better or really worse.

Reality is any decisions are not going to be universally pleasing to everyone. It is always going to be that way in any group large enough. I don't think the goal should be to please everyone. The goal should be to make things work as best as possible for the best "price" in time/effort etc.. There is always room for discussion on that and tweaking where needed. It doesn't mean that just because things can change that such changes would be better, it may just be replacing the devil you know with the devil you don't. But discussing at least brings out the argument.

I think that's probably far enough down that path without concrete information.

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.
And he says that you don't seem interested in release roadmaps because you wrote in the original ticket that you wouldn't gor for a per release roadmap.
I don't think he wants to tell lies :) this is just some misunderstanding :)

In the end maybe it's ok if just a few people make decisions about this?

Well that is what has happened in the past and the problem is now: "I don't like your decisions". A few decided on timed releases - INCLUDING me. That fell apart a bit hoping to get eo/interfaces done for a specific release. That's kind of been ongoing as that elephant doesn't move along fast. I and some others also decided on the model that trusted developers get commit access and review is done afterwards maybe with changes or reverts on the odd occasion the commit is an issue vs review for untrusted devs. I like that model as it speeds things up for core devs who do get things 99% right and once in a while mess up, yet keeps barriers in place for those not yet trusted to get things right. Review doesn't fix this. I have reverted or fixed patches that have gone through review as they broke things badly and I'm not sure the error rate is any lower there, so I think on balance we have something fast, efficient, yet with enough controls in place. I like fast and efficient. I dislike wasting time. Review takes up a lot of time and when the input hours vs reward value is not there, I like to skip it. Look at how many patches just end up in bikeshedding and end up going nowhere. I think this is devil you know vs devil you don't and neither path is better or really worse.

I think we already had discussions about have reviews or not.
I wrote in the original ticket comments that we could just encourage reviews if people felt the need for it.
Basically if you are a commiter you have the choice to ask for a review or not.
You would still have the flexibility to move fast and break stuff :)

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.

That was part of the same response...

That's why I proposed to do a roadmap per release

And that I think is something down the road after a longer term bigger picture "roadmap" is discussed. And as it would change continually e.g. from release to release, it's a conversation to keep having all the time and I think it's wise like you said already to separate that out as a separate task.

I am obviously interested in both time based releases and roadmaps in general and time based roadmaps are what we were doing - releases on a 12 weeks cycle (approximately) and time based releases are just that. The roadmap is a schedule. That is how all the time based release projects I know work. patch/feature makes it or it doesn't each cycle. Otherwise it's a general roadmap for tasks/things being done or needing to be done and they make it or not for a release.

I think we already had discussions about have reviews or not.

But it keeps being brought up here vaguely. As I said and you say - what we have already for years had is just what you describe. Devs with commit access can commit. They can ask for review too if they are not sure.

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.
And he says that you don't seem interested in release roadmaps because you wrote in the original ticket that you wouldn't gor for a per release roadmap.
I don't think he wants to tell lies :) this is just some misunderstanding :)

Don't let facts get in the way of crazy accusations and insults...

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:50 AM
zmike edited projects, added efl; removed Restricted Project.Jun 11 2018, 8:58 AM