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 :)
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
