Re: WOLips bugfixes and new features planning
Re: WOLips bugfixes and new features planning
- Subject: Re: WOLips bugfixes and new features planning
- From: Maik Musall via Webobjects-dev <email@hidden>
- Date: Tue, 24 Nov 2020 17:04:04 +0100
Hi again,
I’m happy to report that we’re preparing invoices to several people and
companies among you totalling about 5000 EUR, and there are still more
offerings that we can take up later if this isn’t enough. I started with the
most specific where I had a contact and a precise amount to bill.
Further, I sent a long email summarizing what we want to have done to the
WOLips developer, Dariusz Michura. He will probably also show up in this list
or in the Slack community at some point.
As far as I have received specific areas of interest attached to the provided
budget, I combined those infos and passed them along, so everyone who wanted
specific things addressed can have a reasonable expectation to actually see
that done once we’re through this. Please be ready to respond to new activity
in the related github issues or pull requests, if there are any, and watch the
commits coming in to provide feedback to Dariusz if necessary.
Maik
> Am 18.11.2020 um 10:02 schrieb Maik Musall via Webobjects-dev
> <email@hidden>:
>
> Hi everyone,
>
> we’ve had a long period of procrastinating about how to prioritize issues and
> the way to proceed, so I’m making a proposal here and need your feedback on
> it. It seems to me that Wolfy’s input in the email from July cited below is
> the best starting point, because all other lists of things we have are much
> less coherent/complete/up to date [1][2][3]. From that, I’d say that the
> component editor with binding validation, it’s upgrade to the e4 platform,
> and bugfixes in that is prio 1, and everything else is up to be voted upon.
>
> We need a sample application complex enough that most of the relevant parts
> of WOLips is touched when working on it, so that the plugin developer has an
> actual piece of code to test WOLips on. It should be something using most of
> the components and EOF. Who volunteers to identify one and prepare it for
> this task?
>
> Then we need to collect the actual money from everyone who agreed to
> contribute, which so far were: Selbstdenker AG (the company I work at), Hugi
> Þórðarson, Henrique Prange, Paul Hoadley, Philippe Rabier, Mark Morris,
> Markus Stoll, Theodore Petrosky, Michael Kondratov, Martino Limido, and
> Miguel Angel Torres Avila. From all of you (and obviously everyone else who
> decides to participate in this) I need an email (public or private)
> mentioning the amount you are willing to spend, a VAT number (if applicable),
> and optionally a note explaining on which part of this effort it is to be
> spent. We will then send back an invoice with that amount which you can pay,
> and have the plugin developer start working on it. Payments will be possible
> via SEPA transaction or PayPal. We will then pay the developer from that
> money.
>
> I’m hoping that with those notes attached to the money we’ll already have
> some priorities that we can assign to the remaining topics. If most of the
> money comes in without appropriation and enough of that is left after
> completing prio 1, we can somehow vote on it. Either way I’ll update you here
> about how things are proceeding.
>
> If some money is left over after this is finished, we can pay it back to the
> contributors, invest it into new features or other improvements, save it for
> future fixes and adaptations, or whatever else we come up with.
>
> What do you think?
>
> Maik
>
>
> [1] github.com/wocommunity/wolips/issues
> <https://github.com/wocommunity/wolips/issues?q=is:issue+is:open+sort:updated-desc>
> [2] wiki.wocommunity.org/pages/viewpage.action?pageId=43155458
> <https://wiki.wocommunity.org/pages/viewpage.action?pageId=43155458>
> [3] Google Docs Tabelle (1Vny…I2M)
> <https://docs.google.com/spreadsheets/d/1VnyixuTJN_bVVHhISC2mP4XdRLUnzcRFb63hIBD4I2M/edit#gid=10545987>
>
>
>> Am 07.07.2020 um 21:47 schrieb Wolfgang Hartmann via Webobjects-dev
>> <email@hidden <mailto:email@hidden>>:
>>
>> Although I am not working anymore with webobjects but with more recent
>> technologies I was still the one who did the last updates on the
>> wolips-project. And therefore here is my opinion about the discussion of
>> work to be done on the wolips-plugin:
>>
>> As you can see in the commit-history for my account "Wolfy42"
>> (https://github.com/wocommunity/wolips/graphs/contributors
>> <https://github.com/wocommunity/wolips/graphs/contributors>) there was some
>> annual necessary. The reason for that was that the wolips-plugin is based on
>> the completely outdated eclipse e3-platform. Since around 2012 all new
>> versions of eclipse are based on the e4-plaform. Eclipse knowns that not all
>> plugins are actively maintained and the upgrade to the e4-platform can be a
>> lot of work and therefore there are a lot of compatibility-layers which
>> could be applied so that also old plugins are capable of running in new
>> releases of the platform. That was the annual work I was doing in the
>> wolips-project.
>>
>> But this compatibility-layer is also the reason why the plugin is rather
>> slow and that it is possible that there is more annual work necessary. Every
>> year there is a new version of eclipse with the possibility to break a lot
>> of old plugins ...
>>
>> I think it would be relevant to break down the parts of wolips and consider
>> which part should be maintained or updated. I think the major parts of the
>> wolips-project are:
>>
>> * The Component-Editor with the Binding-Validation: I think this is the most
>> relevant part and should be completely updated with a current HTML-Editor
>> and it should be upgraded to the e4-platform. And the race-conditions in the
>> binding-validator should be fixed. If you look at the amount of
>> "synchronized"-keywords in the binding-validation-code it should be consider
>> to rewrite it from scratch. The ruleset how the bindings have to be
>> validator can still be reused
>> * Hot-Code-Replacement (=automatic component-class-reloading) after changing
>> the components. This is a very relevant part and should be automatically
>> available without the need of third-party-technologies like JRebel
>> * The EO-Modeler: This is still a relevant part when working with existing
>> projects but there are other good database-domainmodel-modeling-tools out
>> there. It should be considered if one of them should be extended to just
>> generate the .plist-files and .java-files necessary. Maybe even the
>> cayenne-modeler could help here because I consider cayenne to be a modern
>> version of EOF
>> * The EO-Reverse-Engineer-Tool: This should be completely ignored because no
>> new project should be started with EOF. If someone still wants to use
>> webobjects than at least the database-layer should be based on cayenne or
>> JPA-Hibernate.
>> * All the "wizards": The only wizard necessary is the one to generate new
>> Components (all the .wod, .woo, .api and .java-files necessary). All other
>> wizards are irrelevant
>> * All the "refactorings": The only one relevant is the one to rename a
>> component (=rename all the files/folder in one step). The other ones are not
>> relevant.
>>
>> Although webobjects is long dead and not maintained for 12 years now there
>> are still some great and maintained projects built with webobjects out there
>> and therefore it is relevant to have a a good development-environment.
>> Although sometimes I had the feeling that my eclipse was hating me it is
>> still a good IDE.
>>
>> Best Regards,
>> Wolfy
>> Von: Paul Hoadley via Webobjects-dev <email@hidden
>> <mailto:email@hidden>>
>> Gesendet: Freitag, 3. Juli 2020 11:33
>> An: Hugi Thordarson <email@hidden <mailto:email@hidden>>
>> Cc: WebObjects-Dev <email@hidden
>> <mailto:email@hidden>>
>> Betreff: Re: WOLips bugfixes and new features planning
>>
>> On 2 Jul 2020, at 20:25, Hugi Thordarson via Webobjects-dev
>> <email@hidden <mailto:email@hidden>>
>> wrote:
>>
>>> Many of the issue reporters are still with us. I suggest announcing a short
>>> grace period where people can look at their own issues (and other issues,
>>> of course) and add the "keep" label to issues they want to keep. When that
>>> grace period expires, all unlabeled issues are closed. Worst case scenario:
>>> We have to re-open a closed issue. Most users probably get an e-mail
>>> notification when their issues are closed anyway so they can complain at
>>> that time :).
>>
>> I support this approach. Issues that aren't actionable for any of the
>> reasons you describe should be closed.
>>
>>> Regarding funding, I would be very willing to operate on some sort of a
>>> "per feature/issue" basis. I.e. I'd dedicate a fixed amount of money to the
>>> resolution of an issue. Perhaps that also solves the problem of
>>> prioritization? I'm guessing the issues most valuable to the community will
>>> end up being the ones with most funding attached to them.
>>
>> My preference would be prioritised list + pool of money → work on the list
>> until the money runs out (just because it's simpler). But I'd participate in
>> your system too if you want to run it.
>>
>>> Regarding specific issues, there's one issue I'm *really* interested in:
>>> I've attempted to do WOLips development on some occasions but always gave
>>> up since I didn't get everything to work (the docs are kind of
>>> convoluted/outdated).
>>>
>>> Perhaps I'm just stupid, but if not; I believe we would benefit greatly
>>> from having a functional, up-to-date step-by-step guide for how to do
>>> development on WOLips. Teach a man to fish and all that :).
>>
>> This would be good.
>>
>>
>> --
>> Paul Hoadley
>> https://logicsquad.net/ <https://logicsquad.net/>
>> https://www.linkedin.com/company/logic-squad/
>> <https://www.linkedin.com/company/logic-squad/>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden
>> <mailto:email@hidden>)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden <mailto:email@hidden>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden
> <mailto:email@hidden>)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden <mailto:email@hidden>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden