Re: [Vala] Vala Bugfix Hackathon

["Andrés G. Aragoneses" <knocte gmail com>]

pancake escribió:
> Michael 'Mickey' Lauer wrote:
> > Am Freitag, den 20.11.2009, 17:36 +0100 schrieb Michael 'Mickey' Lauer:
> >  
> > > How can we move on with the hackathon?
> > >
> > > I guess the central question is who apart from Jürg (who seems to be
> > > very busy these days) has the knowledge to educate us how to fix certain
> > > things in an upstream-acceptable way? These people are critical to such
> > > a hackathon, hence we need them to dictate a date that would work.
> > >     
> >
> > Okay, if noone of the elders are volunteering to help us moving Vala
> > forward, then this pretty much kills the idea of the hackathon.
> >
> > Too bad.
> >
> >   
> Yes, it's really sad to see that no one of the main developers can
> review patches,
> reply mails or so...
>
> I have more unreported bugs of vala-core, because I'm really losing the
> interest
> of publishing them if there is no interest to fix them (...)
>
> I really think a hackaton can solve this situation, but we need a reply
> from Jürg
> to reorganize the current dead situation of the project where only vapi
> commits
> are appearing in mainstream.
>
> Another solution would be to create a comunity branch of the main git
> repo and
> apply all those fixes there.

(Just my 2cents)
It's really sad that I'm starting to get interested a lot in this
project, and it's precisely now when it smells stalled because of a very
low bus factor. (I proposed a way to fix method overloading in an email
some days ago, and I didn't get enough feedback to be sure that my
approach is going to be reviewed/approved/committed or it's not wanted
at all...)

In this type of cases, I would advocate for the following approach to
get the ball rolling again:
- Create a branch, like you mention above, called "experimental" or
something.
- Be less strict with the patches that land to this branch, wrt the
implementation (because there's not enough time/developers to review
them, so a sign-off from a not-so-core developer would be ok), but be
more strict wrt including a unit test for the bug fixed or feature
implemented.
- If there are regressions because of this approach, don't blame the
technique, but just blame the absence of unit tests for the things that
regressed.
- Make unstable (odd number versioned) versions of vala out of this
branch, so it gets testing.

At least this way the project doesn't seem dead. Any feedback welcome.

        Andres



> For the hackaton... well I think there are many things we can do without
> vala-core
> devels. It's quite fun to hack on the source of vala, and I have managed
> to fix
> some problems in this way. I dont really think that i'm good with it,
> but maybe
> sharing those issues by irc we can try to solve these problems by our own.
>
> I think that the main points for the hackaton would be:
>
>  - Complete the documentation of the language (non-c#, non-java tutorial)
>    - there are some things not explained in the tutorial, like the stack
> allocated arrays, etc..
>    - we can probably start writing a book about vala, like the
> parrot/rakudo people is doing
>      http://rakudo.org/node/58
>  - Documentation for CCodes
>  - Fix VAPIs (I have seen some typos like 'Ccode' and I have some local
> updates for curses.vapi f.ex..)
>  - Review/report bug reports
>  - Submit patches to solve the bugs
>
> I'm missing something here?
>
> --pancake