qooxdoo-contrib, again

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

qooxdoo-contrib, again

panyasan
This post was updated on .
I’ve made these points before in different posts, but let me summarize them in a way that is maybe a bit unfair, but sums it up to me as an active contributor to qooxdoo-contrib:

As it stands now, I think the contrib system ist broken.

This claim is corroborated, I think, by the fact that there haven’t been very many new contributions since the system was last overhauled, and most contributions are outdated and might not be working with current versions of qooxdoo.

1) using the generator to create up-to-date contribution skeletons doesn’t work, as the skeleton does not create a working contribution [1]
2) the workflow needed to add or update a contribution is needlessly complicated [2]
3) despite the complicated workflow, which requires active involvement of the core devs, there is no system that checks whether newly contributed, updated or existing contrib do even work as planned [3]

If the qooxdoo devs care for contributions from the community, I strongly believe that the system needs an overhaul that needs to combine the strengths of the old Sourceforge-based system with the good ideas of the new system, drops the complexities and adds automated services:

- Provide a one-time authorization for contributors which then can add or update contribs (this was possible under the SF/SVN system). Having to send pull requests for the contrib registry etc. is just a big pain. One idea could be to allow „proven“ contributors access to the contrib registry.
- Drop the checksum stuff.
- Fix the contribution skeleton, don’t drop it. On the contrary, make the contrib skeleton mandatory. This is not a big deal for contributors, and allows automation
- Provide automated building of all contributions and publishing of the contributions in the contrib demo browser.
- (Optionally) automatically alert developers if building fails

Given the excellent tool chain and build process that exists in qooxdoo, this is all possible relatively easy [4]

In my opinion, the qooxdoo developers need to decide: if they place any value on the contributions of the community, they should invest at least some time to make the contrib system appealing and workable. In this case, place yourself in the position of a potential contributor, and evaluate the system not according what suits you best as core developers, but according to what makes it easy and fun to contribute. lf that is not your priority, it would be better to make this clear and not to even advertise the contribs - the current choice of contribs is very poor, since most are outdated, and makes a rather bad impression.

Excuse my rant, but I am increasingly frustrated with the system and I think a big opportunity is missed if things stay the way they are. I am happy to be proven wrong...

Best,
Christian


[1] http://qooxdoo.678.n2.nabble.com/create-application-py-t-contribution-and-quot-trunk-quot-folder-td7586114.html
[2] http://qooxdoo.678.n2.nabble.com/New-contrib-website-td7585740.html
[3] See, for example, my own TokenField contrib, which I never tested as a download, but only locally.
[4] http://qooxdoo.678.n2.nabble.com/contrib-2-0-infrastructure-td7585559.html#a7585579
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

Petr Kobalíček
Guys,

just an idea I asked before, why not to use http://bower.io/ ? It's becoming incredibly popular and a lot of people use it. I think that there is no need to build your own system at this point if the old one is not working, this can save time and can make contributions easier.

Cheers,
Petr


On Wed, Sep 3, 2014 at 9:24 AM, panyasan <[hidden email]> wrote:
I’ve made these points before in different posts, but let me summarize them
in a way that is maybe a bit unfair, but sums it up to me as an active
contributor to qooxdoo-contrib:

As it stands now, I think the contrib system ist broken.

This claim is corroborated, I think, by the fact that there haven’t been
very many new contributions since the system was last overhauled, and most
contributions are outdated and might not be working with current versions of
qooxdoo.

1) using the generator to create up-to-date contribution skeletons doesn’t
work, as the skeleton does not create a working skeleton [1]
2) the workflow needed to add or update a contribution is needlessly
complicated [2]
3) despite the complicated workflow, which requires active involvement of
the core devs, there is no system that checks whether newly contribute,
updated or existing contrib do even work as planned [3]

If the qooxdoo devs care for contributions from the community, I strongly
believe that the system needs an overhaul that needs to combine the
strengths of the old Sourceforge-based system with the good ideas of the new
system, drops the complexities and adds automated services:

- Provide a one-time authorization for contributors which then can add or
update contribs (this was possible under the SF/SVN system). Having to send
pull requests for the contrib registry etc. is just a big pain. One idea
could be to allow „proven“ contributors access to the contrib registry.
- Drop the checksum stuff.
- Fix the contribution skeleton, don’t drop it. On the contrary, make the
contrib skeleton mandatory. This is not a big deal for contributors, and
allows automation
- Provide automated building of all contributions and publishing of the
contributions in the contrib demo browser.
- (Optionally) automatically alert developers if building fails

Given the excellent tool chain and build process that exists in qooxdoo,
this is all possible relatively easy [4]

In my opinion, the qooxdoo developers need to decide: if they place any
value on the contributions of the community, they should invest at least
some time to make the contrib system appealing and workable. In this case,
place yourself in the position of a potential contributor, and evaluate the
system not according what suits you best as core developers, but according
to what makes it easy and fun to contribute. lf that is not your priority,
it would be better to make this clear and not to even advertise the contribs
- the current choice of contribs is very poor, since most are outdated, and
make a rather bad impression.

Excuse my rant, but I am increasingly frustrated with the system and I think
a big opportunity is missed if things stay the way they are. I am happy to
be proven wrong...

Best,
Christian


[1]
http://qooxdoo.678.n2.nabble.com/create-application-py-t-contribution-and-quot-trunk-quot-folder-td7586114.html
[2] http://qooxdoo.678.n2.nabble.com/New-contrib-website-td7585740.html
[3] See, for example, my own TokenField contrib, which I never tested as a
download, but only locally.
[4]
http://qooxdoo.678.n2.nabble.com/contrib-2-0-infrastructure-td7585559.html




--
View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

panyasan
Hi Petr,

I'm also very much in favour of using an existing package manager. Probably it would make more sense to use npm, though, because it is already used to install the grunt-based build tools and contribs are a server-side dependeny (since they are used by the generator).
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

panyasan
If this is not a priority of the qooxdoo devs, maybe we should move ahead and agree on a standard format to publish contribs as npm modules? That would be my personal favorite. Technically, this is very easy, since one can install them using npm and then in config.json point to the location of the Manifest file.

To insure discoverability of the contribs, we could agree on a common prefix of the npm modules (for example "qx-contrib-").

What do others think? Sorry to promote the fragmentation of the contribution architecture, but I don't see anything happening and I don't want to use the current system anymore.

C.
dev
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

dev
Hej C!

> If this is not a priority of the qooxdoo devs, maybe we should move ahead and
> agree on a standard format to publish contribs as npm modules? That would be
> my personal favorite. Technically, this is very easy, since one can install
> them using npm and then in config.json point to the location of the Manifest
> file.

I do not vote for this. I would rather see a qooxdoo module, but with possibility to install it with npm too for those outside the very tiny qooxdoo community. Some kind of double factoring if possible. Maybe it might broaden the user base...

> To insure discoverability of the contribs, we could agree on a common prefix
> of the npm modules (for example "qx-contrib-").

Don't like this at all as it only indicates modules to be usable by qooxdoo. Freedom of name giving!

Publish the modules in already existing contrib catalog and in npm modules catalog instead.

> What do others think? Sorry to promote the fragmentation of the contribution
> architecture, but I don't see anything happening and I don't want to use the
> current system anymore.

Why do you want this fragmentation, if you don't want to use qooxdoo anymore?

Very little is happening to qooxdoo nowadays, which is a pity. Unfortunately, we realize a slow suffocation death of qooxdoo...;-(
Maybe it could have been prevented by a truly open community and project owner with joined forces...who knows. It seems to be too late today.
Our development team is the first to feel sadness about it... In the history many very good tech projects have failed on management.

Stefan

> C.
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586165.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

panyasan
Hi Stefan,

my issue is strictly about maintaining and distributing contributions in a way that is not as cumbersome as the current process (having to clone the registry, send pull-requests, create checksums, wait for merging) that has no added value at all for me as developer. Updating my contribs should be a one-step process, just like it is when using npm. I am not advocating to change the way qooxdoo is distributed, that is a separate issue.

C.
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

Petr Kobalíček
In reply to this post by dev
To be honest I really don't like this npm idea, for me it should be:

npm - server
bower - client

Even if you have to precompile qooxdoo to be used with bower it would be much better than using it as npm with generator. The problem I see is that qooxdoo tries to be for everything, which is simply impossible to achieve for the current dev-team.

Cheers,
Petr

On Wed, Sep 10, 2014 at 11:46 AM, <[hidden email]> wrote:
Hej C!

> If this is not a priority of the qooxdoo devs, maybe we should move ahead and
> agree on a standard format to publish contribs as npm modules? That would be
> my personal favorite. Technically, this is very easy, since one can install
> them using npm and then in config.json point to the location of the Manifest
> file.

I do not vote for this. I would rather see a qooxdoo module, but with possibility to install it with npm too for those outside the very tiny qooxdoo community. Some kind of double factoring if possible. Maybe it might broaden the user base...

> To insure discoverability of the contribs, we could agree on a common prefix
> of the npm modules (for example "qx-contrib-").

Don't like this at all as it only indicates modules to be usable by qooxdoo. Freedom of name giving!

Publish the modules in already existing contrib catalog and in npm modules catalog instead.

> What do others think? Sorry to promote the fragmentation of the contribution
> architecture, but I don't see anything happening and I don't want to use the
> current system anymore.

Why do you want this fragmentation, if you don't want to use qooxdoo anymore?

Very little is happening to qooxdoo nowadays, which is a pity. Unfortunately, we realize a slow suffocation death of qooxdoo...;-(
Maybe it could have been prevented by a truly open community and project owner with joined forces...who knows. It seems to be too late today.
Our development team is the first to feel sadness about it... In the history many very good tech projects have failed on management.

Stefan

> C.
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586165.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

panyasan
Hi Petr,

but as far as I can see, you cannot use contribs without the generator and you cannot include them as client-side dependencies. They are libraries that create compile time dependencies that are sorted out very efficiently by the generator (think of part generation). Isn't bower meant for libraries that are mostly independent of each other that have runtime dependencies? They might depend on each other, but this is outside of the qooxdoo workflow.

Cheers,
Christian
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

John Spackman-3
In reply to this post by Petr Kobalíček
While I am very much in favour of a developing community, I do not believe that a better contrib system will somehow improve the number of contribs from the community, or persuade existing contrib authors to keep their contribs up to date.  Given the size of the community, IMHO the simplest and most natural distribution mechanism is Git and/or SVN - if we had 1,000’s of active contribs (or even just 100’s) then perhaps a more controlled process would be appropriate, but not right now.

Effort should go into developing the community first.

John

On 10 Sep 2014, at 11:03, Petr Kobalíček <[hidden email]> wrote:

To be honest I really don't like this npm idea, for me it should be:

npm - server
bower - client

Even if you have to precompile qooxdoo to be used with bower it would be much better than using it as npm with generator. The problem I see is that qooxdoo tries to be for everything, which is simply impossible to achieve for the current dev-team.

Cheers,
Petr

On Wed, Sep 10, 2014 at 11:46 AM, <[hidden email]> wrote:
Hej C!

> If this is not a priority of the qooxdoo devs, maybe we should move ahead and
> agree on a standard format to publish contribs as npm modules? That would be
> my personal favorite. Technically, this is very easy, since one can install
> them using npm and then in config.json point to the location of the Manifest
> file.

I do not vote for this. I would rather see a qooxdoo module, but with possibility to install it with npm too for those outside the very tiny qooxdoo community. Some kind of double factoring if possible. Maybe it might broaden the user base...

> To insure discoverability of the contribs, we could agree on a common prefix
> of the npm modules (for example "qx-contrib-").

Don't like this at all as it only indicates modules to be usable by qooxdoo. Freedom of name giving!

Publish the modules in already existing contrib catalog and in npm modules catalog instead.

> What do others think? Sorry to promote the fragmentation of the contribution
> architecture, but I don't see anything happening and I don't want to use the
> current system anymore.

Why do you want this fragmentation, if you don't want to use qooxdoo anymore?

Very little is happening to qooxdoo nowadays, which is a pity. Unfortunately, we realize a slow suffocation death of qooxdoo...;-(
Maybe it could have been prevented by a truly open community and project owner with joined forces...who knows. It seems to be too late today.
Our development team is the first to feel sadness about it... In the history many very good tech projects have failed on management.

Stefan

> C.
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586165.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

panyasan
Hi John,

thank you for your input. You are certainly right that community building is very important. It is also a difficult and long-term project. My issue is strictly technical and can be solved technically very easily - make contributing easier, but still provide a central mechanism for discoverability of the contribs. A very small investment that has long-term consequences (even if there are only few contributions).

Ensuring the quality of contribs automatically is also very easy technically, but certainly not required...

Best,

C.
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

John Spackman-3
Hi Christian

But why do we need a new mechanism?  As opposed to just a web page and a Git/SVN url?

As I understand it, the need for a custom contrib mechanism was only because there was (is?) a goal to not require the developer to have Git, SVN, or any other kind of VCS installed - but Qooxdoo has no problem with having other prerequisites (e.g. python, node and npm) so what’s the problem with one more?  Especially as many devs will have Git or SVN installed already.

Regards
John

On 10 Sep 2014, at 11:33, panyasan <[hidden email]> wrote:

> Hi John,
>
> thank you for your input. You are certainly right that community building is
> very important. It is also a difficult and long-term project. My issue is
> strictly technical and can be solved technically very easily - make
> contributing easier, but still provide a central mechanism for
> discoverability of the contribs. A very small investment that has long-term
> consequences (even if there are only few contributions).
>
> Ensuring the quality of contribs automatically is also very easy
> technically, but certainly not required...
>
> Best,
>
> C.
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586171.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

panyasan
This post was updated on .
Hi John,

John Spackman-3 wrote
But why do we need a new mechanism?  As opposed to just a web page and a Git/SVN url?

As I understand it, the need for a custom contrib mechanism was only because there was (is?) a goal to not require the developer to have Git, SVN, or any other kind of VCS installed - but Qooxdoo has no problem with having other prerequisites (e.g. python, node and npm) so what’s the problem with one more?  Especially as many devs will have Git or SVN installed already.
The main reason is discoverability and version management. Of course, you can use any location you want as long as there is a zip file that can be downloaded. You can also inform through this list that you have published a new contribution or updated an existing one. But not everybody is a subscriber, and not everybody wants to touch their config.json each time a small bug is fixed. There is a state of the art for central registries and version management and it is implemented in systems like bower or npm. They take care of these things and they are simple to use - that is why they are so successful. All one would need to do is to integrate them into the contrib registry, for example, and get rid of the cloning and pull request stuff. I would shut up and be happy.

Cheers,
C.


Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

Petr Kobalíček
In reply to this post by panyasan
I know how the generator works, but I think that it's not just an advantage, but also a huge disadvantage. If you check out qooxdoo source code, there is a lot of code nobody needs, but is included, and it's hard to remove it.

I really believe that "qooxdoo" way is no longer needed. Qooxdoo should be split into some packages and every contrib would just include dependencies, it would be also much easier that one contrib depends on other.

But, I know it's not easy, and I know that qooxdoo is rather static than dynamic. For example theming contribs is another issue for me.

In the end I don't know if I will ever use qooxdoo again for a new project, and I'm maybe the only one here who doesn't like generator :-)

On Wed, Sep 10, 2014 at 12:20 PM, panyasan <[hidden email]> wrote:
Hi Petr,

but as far as I can see, you cannot use contribs without the generator and
you cannot include them as client-side dependencies. They are libraries that
create *compile time* dependencies that are sorted out very efficiently by
the generator (think of part generation). Isn't bower meant for libraries
that are mostly independent of each other that have *runtime* dependencies?
They might depend on each other, but this is outside of the qooxdoo
workflow.

Cheers,
Christian



--
View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586169.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

John Spackman-3
In reply to this post by panyasan
Hi Christian

> The main reason is discoverability and version management. Of course, you


I don’t agree that npm is better at version management than Git - IMHO it's the opposite.  What do you mean by discoverability?  The user still has to “discover" the contrib on a webpage somewhere to find out that they want to use it.

The only advantage I can think of is if you want to automatically make sure that your app is using the latest version of all contribs - however this can be dangerous because of potential compatibility issues (esp as many contrib authors do not keep their contribs up to date with current Qooxdoo releases).  Personally, I would rather update them individually.

How many contribs do you use?  I use 6 publicly available ones, 4 of which I maintain myself and at least one other I may not even need any more.

Regards
John

On 10 Sep 2014, at 12:04, panyasan <[hidden email]> wrote:

> Hi John,
>
>
> John Spackman-3 wrote
>> But why do we need a new mechanism?  As opposed to just a web page and a
>> Git/SVN url?
>>
>> As I understand it, the need for a custom contrib mechanism was only
>> because there was (is?) a goal to not require the developer to have Git,
>> SVN, or any other kind of VCS installed - but Qooxdoo has no problem with
>> having other prerequisites (e.g. python, node and npm) so what’s the
>> problem with one more?  Especially as many devs will have Git or SVN
>> installed already.
>
> can use any location you want as long as there is a zip file that can be
> downloaded. You can also inform through this list that you have published a
> new contribution or updated an existing one. But not everybody is a
> subscriber, and not everybody wants to touch their config.json each time a
> small bug is fixed. There is a state of the art for central registries and
> version management and it is implemented in systems like bower or npm. They
> take care of these things and they are simple to use - that is why they are
> so successful. All you would need to do is to integrate them into the
> contrib registry, for example, and get rid of the cloning and pull request
> stuff. I would shut up and be happy.
>
> Cheers,
> C.
>
>
>
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586173.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

John Spackman-3
In reply to this post by Petr Kobalíček
Hi Petr

Personally this has not bothered me until recently when I’ve had to do some traditional web front ends - q/qxweb is not compatible with any nice UI widgets, so for “thin” front end I use requirejs, jquery, knockoutjs, etc … and a home made qx.Class.  I agree that Qooxdoo is not really suitable for that kind of development, but mostly because the qxweb provides very little compared to what is already out there and more established - this is a shame because it’s 95% of the way to being useful, a little more effort and it could have a good chance.

On the backend and for “thick” web clients the generator is essential (although slow), although I’m not sure I agree that a lot of code is unused.

Regards
John

On 10 Sep 2014, at 12:08, Petr Kobalíček <[hidden email]> wrote:

I know how the generator works, but I think that it's not just an advantage, but also a huge disadvantage. If you check out qooxdoo source code, there is a lot of code nobody needs, but is included, and it's hard to remove it.

I really believe that "qooxdoo" way is no longer needed. Qooxdoo should be split into some packages and every contrib would just include dependencies, it would be also much easier that one contrib depends on other.

But, I know it's not easy, and I know that qooxdoo is rather static than dynamic. For example theming contribs is another issue for me.

In the end I don't know if I will ever use qooxdoo again for a new project, and I'm maybe the only one here who doesn't like generator :-)

On Wed, Sep 10, 2014 at 12:20 PM, panyasan <[hidden email]> wrote:
Hi Petr,

but as far as I can see, you cannot use contribs without the generator and
you cannot include them as client-side dependencies. They are libraries that
create *compile time* dependencies that are sorted out very efficiently by
the generator (think of part generation). Isn't bower meant for libraries
that are mostly independent of each other that have *runtime* dependencies?
They might depend on each other, but this is outside of the qooxdoo
workflow.

Cheers,
Christian



--
View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586169.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

fritz
On Wed, 10 Sep 2014, John Spackman wrote:

> On the backend and for ?thick? web clients the generator is essential
> (although slow), although I?m not sure I agree that a lot of code is
> unused.

Why does speed matter here? I usually develop with the source version and
only rarely (when adding a new class or resource) run the generator.
Especially since source-hybrid became available.

I usually spend a lot more time on implementing/testing/debugging ...

Cheers,
Fritz

--
Oetiker+Partner AG              tel: +41 62 775 9903 (direct)
Fritz Zaucker                        +41 62 775 9900 (switch board)
Aarweg 15                            +41 79 675 0630 (mobile)
CH-4600 Olten                   fax: +41 62 775 9905
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

John Spackman-3
I develop multiple websites inside a single framework, where each website has several client apps and one server app; when deploying onto development or live servers, it is essential to delete the generator cache on the target machine before recompiling because otherwise the generator will often screw up the compiled code.  Recompiling a single app including populating the cache takes over 3 minutes, and deploying to a server requires regenerating all apps.  We generate the apps on demand to lessen the load but it’s still not great.

Also, because developing inside a framework and having server and client apps that work together, changing code sometimes requires re-running the generator for 2 or more apps - this is a pain because they’re in different directories, and having a permanent “watchdog” auto-generate does not work well because generator.py has such a heavy impact on the system.

I have written an esprima based version of generator.py that can build an entire app including analyse resources in around 7 seconds without a cache (around 150ms with a populated cache) so I know that massive speed up is possible - but I have not had the time to make it release worthy otherwise it have been a contrib a long time ago (and more recently the core dev team have said they’re doing something similar anyway).

Regards
John


On 10 Sep 2014, at 12:38, Fritz Zaucker <[hidden email]> wrote:

> On Wed, 10 Sep 2014, John Spackman wrote:
>
>> On the backend and for ?thick? web clients the generator is essential
>> (although slow), although I?m not sure I agree that a lot of code is
>> unused.
>
> Why does speed matter here? I usually develop with the source version and
> only rarely (when adding a new class or resource) run the generator.
> Especially since source-hybrid became available.
>
> I usually spend a lot more time on implementing/testing/debugging ...
>
> Cheers,
> Fritz
>
> --
> Oetiker+Partner AG              tel: +41 62 775 9903 (direct)
> Fritz Zaucker                        +41 62 775 9900 (switch board)
> Aarweg 15                            +41 79 675 0630 (mobile)
> CH-4600 Olten                   fax: +41 62 775 9905
> Schweiz                         web: www.oetiker.ch
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

panyasan
In reply to this post by John Spackman-3
John:

John Spackman-3 wrote
I don’t agree that npm is better at version management than Git - IMHO it's the opposite.  What do you mean by discoverability?  The user still has to “discover" the contrib on a webpage somewhere to find out that they want to use it.
Yes, exactly. If you have a registry of contributions which you can filter by the intended target (for example "qooxdoo-4.0.X"), you can "discover" all the contributions that work with that target. That's how the current contrib registry works, but the process of updating this registry is so convoluted that hardly anyone uses it. That is my point. Git and npm are not directly comparable, as you know - Git is a source control tool (version management at the file level), and npm is a package manager (version management at the package level). As I said, all I want to do is to publish new contribs and update old ones in a simple, one-step process, and provide versioned packages that are fed into the registry.

John Spackman-3 wrote
The only advantage I can think of is if you want to automatically make sure that your app is using the latest version of all contribs - however this can be dangerous because of potential compatibility issues (esp as many contrib authors do not keep their contribs up to date with current Qooxdoo releases).  Personally, I would rather update them individually.
I would not want automatic upgrade, but there are good technologies to prevent this (e.g. semantic versioning and versioned dependencies in package.json). That is what I mean with state-of-the-art -> the problem has been solved already - we don't need to reinvent the wheel.

And you are right - the number of contribs we are talking about is very small and might not warrant such lengthy discussion. But contrary to those who think qooxdoo's time is over my own experience is that it is a rock-solid foundation for thick web clients. On top of this, a healthy contribution ecosystem could be established, but this will only happen if maintaining contribs doesn't involve a process that I, at least, find rather convoluted....
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

John Spackman-3
Well anything that make it easier than the current version gets my vote - I’m one of the ones that don’t update it because it’s too cumbersome.

Personally I would have a few questions about whether state of the art npm equates to version management and how it would be better for me than just Git, but that’s just my POV and shouldn’t hinder your efforts.

John

On 10 Sep 2014, at 13:02, panyasan <[hidden email]> wrote:

> John:
>
>
> John Spackman-3 wrote
>> I don’t agree that npm is better at version management than Git - IMHO
>> it's the opposite.  What do you mean by discoverability?  The user still
>> has to “discover" the contrib on a webpage somewhere to find out that they
>> want to use it.
>
> Yes, exactly. If you have a registry of contributions which you can filter
> by the intended target (for example "qooxdoo-4.0.X"), you can "discover" all
> the contributions that work with that target. That's how the current contrib
> registry works, but the process of updating this registry is so convoluted
> that hardly anyone uses it. That is my point. Git and npm are not directly
> comparable, as you know - Git is a source control tool (version management
> at the file level), and npm is a package manager (version management at the
> package level). As I said, all I want to do is to publish new contribs and
> update old ones in a simple, one-step process, and provide versioned
> packages that are fed into the registry.
>
>
> John Spackman-3 wrote
>> The only advantage I can think of is if you want to automatically make
>> sure that your app is using the latest version of all contribs - however
>> this can be dangerous because of potential compatibility issues (esp as
>> many contrib authors do not keep their contribs up to date with current
>> Qooxdoo releases).  Personally, I would rather update them individually.
>
> I would not want automatic upgrade, but there are good technologies to
> prevent this (e.g. semantic versioning and versioned dependencies in
> package.json). That is what I mean with state-of-the-art -> the problem has
> been solved already - we don't need to reinvent the wheel.
>
> And you are right - the number of contribs we are talking about is very
> small and might not warrant such lengthy discussion. But contrary to those
> who think qooxdoo's time is over my own experience is that it is a
> rock-solid foundation for thick web clients. On top of this, a healthy
> contribution ecosystem could be established, but this will only happen if
> maintaining contribs doesn't involve a process that I, at least, find rather
> convoluted....
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-contrib-again-tp7586131p7586179.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo-contrib, again

Dietrich Streifert
In reply to this post by panyasan
Hello everybody,

I've tried to follow the discussion and I have to say that I'm just lost
on all those possible options, implementations and versioning stuff.

I've just did a few JSDoc corrections do UploadWidget on sourceforge [1]
via svn which where reported in an issue at bugzilla from Christian
Boulanger.

I'm currently using 3 contributions in my project, the aristo theme by
John Spackman, SmartTableModel by Derrell Lipman and of course
UploadWidget by Tobi Oettiker, Petr Kobalicek and me.

My "strategy" is to use manually checked out contributions to local
directories with manual references in the config.json file via the
libraries key. Til now my source was sourceforge.

Now I've seen that there is an (from my point of view) outdated
uploadwidget contrib on github [2] where Derrell already has made those
changes which I've made today :-(

I suspect that the github version and the sf version already evolved to
subtle differences. That's odd.

Regards
Dietrich

[1]
https://svn.code.sf.net/p/qooxdoo-contrib/code/trunk/qooxdoo-contrib/UploadWidget
[2] https://github.com/qooxdoo-contrib/uploadwidget

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
12