Re: [E-devel] e17 release stuff
Agreed with both Mekius and Toma.
What Hisham said can be summarized as now that we delayed we can
delay a bit more, this can lead to infinite, similar to we do half,
then half of the half...
On Tue, Jan 6, 2009 at 3:29 AM, Toma tomha...@gmail.com wrote:
Spot on Mekius. If we had a 6 month roadmap and an alpha release, we'd
have quite a bit of PR and certainly a bit of personal drive. Even
with ewl having releases it gives me drive to try to get the new theme
into the next major version. Im sure other devs would be energised by
a roadmap and release.
Toma.
On 1/6/09, Nick Hughart mek...@mekius.net wrote:
On Mon, 5 Jan 2009 23:40:42 -0500
Hisham Mardam Bey hisham.mardam...@gmail.com wrote:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove
the idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do
without them so would flag them (all, or at least most of them)
as optional.
I'd disagree with you here. A nice fm is really important to the
end users. Using external file browser is just an ugly way (imo)
and would 1) make less experienced users ask lots of questions
about how to deal with files when using E (and why (and how)
should they bother installing external fm) and 2) probably distro
packagers are going to pack E with Thunar or something and I don't
like that. I'm aware that the fm is probably one of the hardest
things to do in E17, but it is too important to just... not finish
it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
This is true, but it's also a misconception of the public that all this
time was spent just working on E17. This is hardly the case and many
people are already using the EFL and are mostly awaiting a release so
they have a stable target to develop against. E17 has been a long time
coming for sure, but I think people discount the amount of code that
has been written and the small number of dedicated developers we have.
And the use of the term vaporware is crap as well. Vaporware doesn't
exist at all. E17 and the EFL both exist in a very real way and the
lack of a stable release doesn't change that. If all the code was
closed up and no one could use it, I could see people coming to this
conclusion. Fact is people can use E17 because we have released it via
CVS/SVN. Anyone who calls it vaporware is a moron.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
This is true. People may have been more willing to accept bugs and
such, but it would have also put us in a position of offering a lot
more documentation and support for users who couldn't debug to save
their life, let alone explain their issue clear enough. By releasing
a development version via a source repository you attempt to attract
more developers then users so you can free yourself from answering user
questions 24/7. Of course a lot of users have started using E17 and
that's fine, but they hopefully realize that what they are using is not
finished. People packaging doesn't help that, but we can at least
focus more on development then support.
Now with that said, an initial release will be good as soon as most of
the bugs are ironed out. Feature wise I think we can sacrifice some of
the more advanced and difficult to implement features for the initial
release. For the release, we will need more documentation, tutorials,
etc. It will also require some form of support, but the long time
CVS/SVN users can help with that hopefully.
In any case, I think the biggest thing a release will do is generate a
bit of PR for E and hopefully bring a new rush of developers/users who
are willing and able to help out wherever they can. If anything we will
have a release that can be packaged and users can easily install. This
will lower the amount of build questions that seem to consume so much
of our support time now. So this could be
Re: [E-devel] e17 release stuff
On Tue, 6 Jan 2009 09:06:38 -0200 Gustavo Sverzut Barbieri
barbi...@profusion.mobi babbled:
actually what hisham said was:
we've taken this long. people will expect something good out of that much time
spent. if we rush things now just to slap out a release with stuff missing or
done badly or buggy - we will be ridiculed for having produced such a pile of
crap after so long. so let's not cut corners just to save a few weeks - do it
right - as in the scheme of things... its not that much time considering how
long it's been.
Agreed with both Mekius and Toma.
What Hisham said can be summarized as now that we delayed we can
delay a bit more, this can lead to infinite, similar to we do half,
then half of the half...
On Tue, Jan 6, 2009 at 3:29 AM, Toma tomha...@gmail.com wrote:
Spot on Mekius. If we had a 6 month roadmap and an alpha release, we'd
have quite a bit of PR and certainly a bit of personal drive. Even
with ewl having releases it gives me drive to try to get the new theme
into the next major version. Im sure other devs would be energised by
a roadmap and release.
Toma.
On 1/6/09, Nick Hughart mek...@mekius.net wrote:
On Mon, 5 Jan 2009 23:40:42 -0500
Hisham Mardam Bey hisham.mardam...@gmail.com wrote:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove
the idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do
without them so would flag them (all, or at least most of them)
as optional.
I'd disagree with you here. A nice fm is really important to the
end users. Using external file browser is just an ugly way (imo)
and would 1) make less experienced users ask lots of questions
about how to deal with files when using E (and why (and how)
should they bother installing external fm) and 2) probably distro
packagers are going to pack E with Thunar or something and I don't
like that. I'm aware that the fm is probably one of the hardest
things to do in E17, but it is too important to just... not finish
it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
This is true, but it's also a misconception of the public that all this
time was spent just working on E17. This is hardly the case and many
people are already using the EFL and are mostly awaiting a release so
they have a stable target to develop against. E17 has been a long time
coming for sure, but I think people discount the amount of code that
has been written and the small number of dedicated developers we have.
And the use of the term vaporware is crap as well. Vaporware doesn't
exist at all. E17 and the EFL both exist in a very real way and the
lack of a stable release doesn't change that. If all the code was
closed up and no one could use it, I could see people coming to this
conclusion. Fact is people can use E17 because we have released it via
CVS/SVN. Anyone who calls it vaporware is a moron.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
This is true. People may have been more willing to accept bugs and
such, but it would have also put us in a position of offering a lot
more documentation and support for users who couldn't debug to save
their life, let alone explain their issue clear enough. By releasing
a development version via a source repository you attempt to attract
more developers then users so you can free yourself from answering user
questions 24/7. Of course a lot of users have started using E17 and
that's fine, but they hopefully realize that what they are using is not
finished. People packaging doesn't help that, but we can at least
focus more on development then support.
Now with that said, an initial release will be good as soon as most of
the bugs are ironed out. Feature wise I think we can sacrifice some of
the more advanced and difficult to
Re: [E-devel] e17 release stuff
I quote Hishman and Rasterman totally. EFM is absolutely not ready for any
Joe the user man. Of course I need to package my distro with Thunar for now,
the user cannot use EFM yet, but I'm surely looking forward to an usable
EFM. Really, the file manager is more than important at this point. When
people enables the desktop icons, for example, folders as well as devices
appear on the user's screen. Now, since EFM is not completed and I don't
think anyone could use it, in my distro (as well as in E-Live or any other
E7 distro) there's a 3rd party FM, Thunar. When people double clicks on a
folder on the desktop, EFM opens of course. So they get confused and post in
the forum: when I open a folder from the desktop a weird window opens, it
is not the normal FM... I can't use it, I cannot copy paste easily, cannot
see and edit advanced file properties... what happened?
That is, people gets confused. So, I decided to disable by default EFM from
my distro. But this means people cannot have desktop icons. And here they
conplain again... always better than having them confused by the existence
of both EFM and Thunar.. or leaving them alone, dealing with an incomplete
FM. So, honestly, it's better IMHO to take some more time and complete all
that has to be completed. We cannot leave the work half-finished.
Happy new year everyone,
Luca D.M.
2009/1/6 The Rasterman Carsten Haitzler ras...@rasterman.com
On Tue, 6 Jan 2009 09:06:38 -0200 Gustavo Sverzut Barbieri
barbi...@profusion.mobi babbled:
actually what hisham said was:
we've taken this long. people will expect something good out of that much
time
spent. if we rush things now just to slap out a release with stuff missing
or
done badly or buggy - we will be ridiculed for having produced such a pile
of
crap after so long. so let's not cut corners just to save a few weeks - do
it
right - as in the scheme of things... its not that much time considering
how
long it's been.
Agreed with both Mekius and Toma.
What Hisham said can be summarized as now that we delayed we can
delay a bit more, this can lead to infinite, similar to we do half,
then half of the half...
On Tue, Jan 6, 2009 at 3:29 AM, Toma tomha...@gmail.com wrote:
Spot on Mekius. If we had a 6 month roadmap and an alpha release, we'd
have quite a bit of PR and certainly a bit of personal drive. Even
with ewl having releases it gives me drive to try to get the new theme
into the next major version. Im sure other devs would be energised by
a roadmap and release.
Toma.
On 1/6/09, Nick Hughart mek...@mekius.net wrote:
On Mon, 5 Jan 2009 23:40:42 -0500
Hisham Mardam Bey hisham.mardam...@gmail.com wrote:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove
the idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do
without them so would flag them (all, or at least most of them)
as optional.
I'd disagree with you here. A nice fm is really important to the
end users. Using external file browser is just an ugly way (imo)
and would 1) make less experienced users ask lots of questions
about how to deal with files when using E (and why (and how)
should they bother installing external fm) and 2) probably distro
packagers are going to pack E with Thunar or something and I don't
like that. I'm aware that the fm is probably one of the hardest
things to do in E17, but it is too important to just... not finish
it.
But it's mostly working for joe-the-user. Sure, having things
like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot
of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
This is true, but it's also a misconception of the public that all
this
time was spent just working on E17. This is hardly the case and many
people are already using the EFL and are mostly awaiting a release so
they have a stable target to develop against. E17 has been a long
time
coming for sure, but I think people discount the amount of code that
has been written and the small number of dedicated developers we have.
And the use of the term vaporware is crap as well. Vaporware doesn't
exist at all. E17 and the EFL both exist in a very real way
Re: [E-devel] e17 release stuff
On Thu, Jan 1, 2009 at 2:26 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: ok. i just added some of the things discussed in the efm thoughts thread a few weeks ago: http://trac.enlightenment.org/e/wiki/Release does anyone have anything to add? i'd like focus to pretty much revolve around what's on that list. there are other things being done that are parallel to that list (things some of us are paid to do or are on other project timelines), but otherwise for e17 that list is pretty much the core of what's to be done. some of them are broad items that can encompass a lot of work (make dialogs even if big, work on small screens). i may have missed a few things along the way - again. if you have anything - add it to that page (then mail about it - we can remove it or modify it). but this is what needs doing. if you want to see an e17 release - lets get this stuff done! I did basic categorization of enlightenment items and also remove the idea to drop 16bpp engines as we'll use it in our projects. most showstopper atm is file manager items, I think we can do without them so would flag them (all, or at least most of them) as optional. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make less
experienced users ask lots of questions about how to deal with files when
using E (and why (and how) should they bother installing external fm) and 2)
probably distro packagers are going to pack E with Thunar or something and I
don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, 5 Jan 2009 23:24:46 -0200 Gustavo Sverzut Barbieri
barbi...@profusion.mobi babbled:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make less
experienced users ask lots of questions about how to deal with files when
using E (and why (and how) should they bother installing external fm) and 2)
probably distro packagers are going to pack E with Thunar or something and I
don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
but these are rather trivial to add - the point is not how many things on the
list but time vs value after implementation. a lot of things are just small do
it right things - others are big fat time-sinks.
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make less
experienced users ask lots of questions about how to deal with files when
using E (and why (and how) should they bother installing external fm) and 2)
probably distro packagers are going to pack E with Thunar or something and I
don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
--
Hisham Mardam-Bey
http://hisham.cc/
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, 5 Jan 2009 23:40:42 -0500 Hisham Mardam Bey
hisham.mardam...@gmail.com babbled:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make
less experienced users ask lots of questions about how to deal with files
when using E (and why (and how) should they bother installing external fm)
and 2) probably distro packagers are going to pack E with Thunar or
something and I don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
agreed. and the fm needs to be functional and useful. small things are easy but
core improvements need to be done.
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, 5 Jan 2009 23:40:42 -0500
Hisham Mardam Bey hisham.mardam...@gmail.com wrote:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove
the idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do
without them so would flag them (all, or at least most of them)
as optional.
I'd disagree with you here. A nice fm is really important to the
end users. Using external file browser is just an ugly way (imo)
and would 1) make less experienced users ask lots of questions
about how to deal with files when using E (and why (and how)
should they bother installing external fm) and 2) probably distro
packagers are going to pack E with Thunar or something and I don't
like that. I'm aware that the fm is probably one of the hardest
things to do in E17, but it is too important to just... not finish
it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
This is true, but it's also a misconception of the public that all this
time was spent just working on E17. This is hardly the case and many
people are already using the EFL and are mostly awaiting a release so
they have a stable target to develop against. E17 has been a long time
coming for sure, but I think people discount the amount of code that
has been written and the small number of dedicated developers we have.
And the use of the term vaporware is crap as well. Vaporware doesn't
exist at all. E17 and the EFL both exist in a very real way and the
lack of a stable release doesn't change that. If all the code was
closed up and no one could use it, I could see people coming to this
conclusion. Fact is people can use E17 because we have released it via
CVS/SVN. Anyone who calls it vaporware is a moron.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
This is true. People may have been more willing to accept bugs and
such, but it would have also put us in a position of offering a lot
more documentation and support for users who couldn't debug to save
their life, let alone explain their issue clear enough. By releasing
a development version via a source repository you attempt to attract
more developers then users so you can free yourself from answering user
questions 24/7. Of course a lot of users have started using E17 and
that's fine, but they hopefully realize that what they are using is not
finished. People packaging doesn't help that, but we can at least
focus more on development then support.
Now with that said, an initial release will be good as soon as most of
the bugs are ironed out. Feature wise I think we can sacrifice some of
the more advanced and difficult to implement features for the initial
release. For the release, we will need more documentation, tutorials,
etc. It will also require some form of support, but the long time
CVS/SVN users can help with that hopefully.
In any case, I think the biggest thing a release will do is generate a
bit of PR for E and hopefully bring a new rush of developers/users who
are willing and able to help out wherever they can. If anything we will
have a release that can be packaged and users can easily install. This
will lower the amount of build questions that seem to consume so much
of our support time now. So this could be very good for everyone, but
like you said, we need to make sure it's pretty damn good or the
backlash could be brutal. Even if we do make a quality release, I
expect a lot of crap flinging from all angles just because people like
to hate beautiful things :)
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
Spot on Mekius. If we had a 6 month roadmap and an alpha release, we'd
have quite a bit of PR and certainly a bit of personal drive. Even
with ewl having releases it gives me drive to try to get the new theme
into the next major version. Im sure other devs would be energised by
a roadmap and release.
Toma.
On 1/6/09, Nick Hughart mek...@mekius.net wrote:
On Mon, 5 Jan 2009 23:40:42 -0500
Hisham Mardam Bey hisham.mardam...@gmail.com wrote:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove
the idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do
without them so would flag them (all, or at least most of them)
as optional.
I'd disagree with you here. A nice fm is really important to the
end users. Using external file browser is just an ugly way (imo)
and would 1) make less experienced users ask lots of questions
about how to deal with files when using E (and why (and how)
should they bother installing external fm) and 2) probably distro
packagers are going to pack E with Thunar or something and I don't
like that. I'm aware that the fm is probably one of the hardest
things to do in E17, but it is too important to just... not finish
it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
This is true, but it's also a misconception of the public that all this
time was spent just working on E17. This is hardly the case and many
people are already using the EFL and are mostly awaiting a release so
they have a stable target to develop against. E17 has been a long time
coming for sure, but I think people discount the amount of code that
has been written and the small number of dedicated developers we have.
And the use of the term vaporware is crap as well. Vaporware doesn't
exist at all. E17 and the EFL both exist in a very real way and the
lack of a stable release doesn't change that. If all the code was
closed up and no one could use it, I could see people coming to this
conclusion. Fact is people can use E17 because we have released it via
CVS/SVN. Anyone who calls it vaporware is a moron.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
This is true. People may have been more willing to accept bugs and
such, but it would have also put us in a position of offering a lot
more documentation and support for users who couldn't debug to save
their life, let alone explain their issue clear enough. By releasing
a development version via a source repository you attempt to attract
more developers then users so you can free yourself from answering user
questions 24/7. Of course a lot of users have started using E17 and
that's fine, but they hopefully realize that what they are using is not
finished. People packaging doesn't help that, but we can at least
focus more on development then support.
Now with that said, an initial release will be good as soon as most of
the bugs are ironed out. Feature wise I think we can sacrifice some of
the more advanced and difficult to implement features for the initial
release. For the release, we will need more documentation, tutorials,
etc. It will also require some form of support, but the long time
CVS/SVN users can help with that hopefully.
In any case, I think the biggest thing a release will do is generate a
bit of PR for E and hopefully bring a new rush of developers/users who
are willing and able to help out wherever they can. If anything we will
have a release that can be packaged and users can easily install. This
will lower the amount of build questions that seem to consume so much
of our support time now. So this could be very good for everyone, but
like you said, we need to make sure it's pretty damn good or the
backlash could be brutal. Even if we do make a quality release, I
expect a lot of crap flinging from all angles just because people like
to hate beautiful things :)
[E-devel] e17 release stuff
ok. i just added some of the things discussed in the efm thoughts thread a few weeks ago: http://trac.enlightenment.org/e/wiki/Release does anyone have anything to add? i'd like focus to pretty much revolve around what's on that list. there are other things being done that are parallel to that list (things some of us are paid to do or are on other project timelines), but otherwise for e17 that list is pretty much the core of what's to be done. some of them are broad items that can encompass a lot of work (make dialogs even if big, work on small screens). i may have missed a few things along the way - again. if you have anything - add it to that page (then mail about it - we can remove it or modify it). but this is what needs doing. if you want to see an e17 release - lets get this stuff done! -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
