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
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
