What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Martijn Dashorst <ma...@gmail.com>]

On 5/6/07, Ryan Sonnek <ry...@gmail.com> wrote:
> As a wicket-stuff developer, I for one would hate to see restrictions
> placed on what can or can not be a wicket-stuff project.

This was not a thread on what constitutes a wicket stuff project, but
now that you brought it up :)

In my vision, there is no restriction (bar the things sf.net policies
and good taste prohibit) on what can be a Wicket Stuff project.

> The beauty
> of the wicket-stuff idea is that it is a playground for people try out
> potentially cool ideas.  It's a place for people to learn how to use
> wicket and build "possibly" cool widgets and tools.

Yes, but we should be able to keep it clean/real, in that the SVN
trunk does not end up as a dumping ground for dead projects and broken
ideas.

I would like the projects to be maintained (not as vigorously as
wicket core is, but at least migrate with each release of Wicket, and
get a download from either the maven repository or the sf.net download
area).

As such, I think the minimal requirements for a Wicket contrib project would be:
 - a page in the wicketstuff wiki explaining:
     * what the project does
     * who is maintaining it
     * the intent of the project (example, actual usage, experiment, ?)
 - if the intent is actual usage: a release with at least each major
wicket release
 - if the intent is example or experiment: description on how to get
it and start with it

I am in doubt on what to do with projects that don't get maintained:
 - letting them sit -> gives a bad experience for users trying the
projects out (see maven), but allows new users to pick up the code and
do something with it
 - removing them/moving to attic -> makes the projects invisible and
virtually annihilates the opportunity of someone else picking the
project up

If a project that has been in limbo for a while has a viable
alternative, I would opt to remove the dead project. If there is no
alternative, I would opt to keep it.

> I know that *my* project (wicketstuff-scriptaculous) has occasionally
> been left "in the dark" for several months before a whole slew of
> changes and features get built in.

The scriptaculous project is actively maintained in my book: regular
code additions, blog entries, etc. and would be an example for other
projects. Thanks for that!

> Sure, there may be a "better" wicket/hibernate project out there (aka:
> databinder), but I really don't see any issues with that.  Especially
> now that there's a wicket-stuff wiki, it can be clearly spelled out
> there what each project's strengths/weaknesses are.

But that was not even available for these projects. That prompted me
to ask if these are actively maintained and what we should do with
them. *Only* if they were not maintained I would want them be removed.
In this particular case, I would now only opt for removing the
distributables from the sf.net download site since these artifacts
don't have any value at the moment other than confusing new users.

Martijn

-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

On 5/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> thats nice of you eelco, but like i said i dont think this is our job. if a
> project is broken for some period of time we should move it off trunk. let
> the next person who wants to use it fix it. we dont need to fix the world.

I think that attitude is justifiable when API breaks are rare, and
there is just one development branch. Neither has been the case last
year.

Eelco

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

On 5/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> as far as i can see eelco is complaining because he is doing that and no one
> is following! :)

No, I have been complaining/ asking other team members in the past to
fix those projects as well because it's hardly any effort for the one
who is working on the break, whereas for anyone else it has much more
work, and also because it just increases the number of cases it gets
tested against.

Eelco

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Igor Vaynberg <ig...@gmail.com>]

as far as i can see eelco is complaining because he is doing that and no one
is following! :)

-igor


On 5/7/07, Johan Compagner <jc...@gmail.com> wrote:
>
> > we dont need to fix the world.
>
>
> but nobody should or would stop you if you did!
> the world needs saving! Igor start doing this maybe the rest will follow!
>
> johan
>

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Johan Compagner <jc...@gmail.com>]

> we dont need to fix the world.


but nobody should or would stop you if you did!
the world needs saving! Igor start doing this maybe the rest will follow!

johan

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Igor Vaynberg <ig...@gmail.com>]

thats nice of you eelco, but like i said i dont think this is our job. if a
project is broken for some period of time we should move it off trunk. let
the next person who wants to use it fix it. we dont need to fix the world.

-igor


On 5/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > if we break the
> > api it is not our responsibility to fix it, it is the job of whoever is
> > responsible for that wicket-stuff project.
>
> Technically, you are right. Practically you are not.
>
> * To start with, It's just a matter of courtesy.
> * It's much less work for the one doing the API break to fix other
> projects than for someone who probably doesn't right away understand
> the break/ ideas/ consequences. Where it takes a couple of minutes for
> the 'breaker' to fix a project, it takes an hour or more for someone
> else.
> * We have been moving fast with our breaks up to a point that it has
> probably been pretty hard to keep up for anyone but the core members.
> * In the end, I've been doing 90% of the wicket-stuff fixes (and I
> often waited for a few weeks and even asked on the dev list if others
> would take some time to fix it), whereas I've been repsonsible for
> maybe 10% of the breaks. And that's a bit of team work than can be
> improved imo.
>
> Eelco
>

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

> if we break the
> api it is not our responsibility to fix it, it is the job of whoever is
> responsible for that wicket-stuff project.

Technically, you are right. Practically you are not.

* To start with, It's just a matter of courtesy.
* It's much less work for the one doing the API break to fix other
projects than for someone who probably doesn't right away understand
the break/ ideas/ consequences. Where it takes a couple of minutes for
the 'breaker' to fix a project, it takes an hour or more for someone
else.
* We have been moving fast with our breaks up to a point that it has
probably been pretty hard to keep up for anyone but the core members.
* In the end, I've been doing 90% of the wicket-stuff fixes (and I
often waited for a few weeks and even asked on the dev list if others
would take some time to fix it), whereas I've been repsonsible for
maybe 10% of the breaks. And that's a bit of team work than can be
improved imo.

Eelco

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Igor Vaynberg <ig...@gmail.com>]

On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > However, that does impose some form of oversight, and given the
> > current state of Wicket Stuff, I doubt that it will ever happen, if it
> > doesn't come from us.
>
> Exactly.


i dont think you got it right eelco. oversight!=maintenance. if we break the
api it is not our responsibility to fix it, it is the job of whoever is
responsible for that wicket-stuff project.

our oversight shouldnt be much more then starting a vote to demote a project
from projects to concepts and doing an svn move.

we are already stretched on our resources, and people keep starting new
wicket-stuff projects. the problem is that after a few weeks the excitement
dies and those projects are orphaned - like the new attempt at the bean
panel thats in there now. this is of course natural, but we need to setup
some sort of a filter.

-igor

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

> However, that does impose some form of oversight, and given the
> current state of Wicket Stuff, I doubt that it will ever happen, if it
> doesn't come from us.

Exactly.

> It is just hard to find people with a sustained
> interest in maintaining a project and actively working on its
> progress.

We have a couple of people now who want to maintain the projects. I
think what our problem has been is that we have been breaking the API
a lot, but haven't immediately been updating those projects for the
breaks, leaving the projects most of the time in a broken state. I bet
that hasn't been too encouraging.

Besides that however, there really seems to be a problem with getting
people all fired up and exited about those projects, as there could
have been a ton more projects by now, and certainly more releases and
documentation etc. I don't know what it is. I'm afraid that's just how
most of such initiatives end up in OSS.

Eelco

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Johan Compagner <jc...@gmail.com>]

>
> In my opinion Wicket Stuff is used as a Wicket specific incubator for
> projects that will end up in core. At least for projects that have
> 'use' as intent.


this is not always the case. it is also a project place when the license
doesn't work out.
So to say that it is an incubator for everything is wrong.

johan

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Martijn Dashorst <ma...@gmail.com>]

Perhaps we should write up some goals for Wicket Stuff.

In my opinion Wicket Stuff is used as a Wicket specific incubator for
projects that will end up in core. At least for projects that have
'use' as intent.

Projects within Wicket have different intentions:
 - actual use (i.e. wicket, extensions, spring, velocity)
 - example (i.e. examples, auth-roles?, contrib-data/hibernate?)
 - proof of concept (i.e. fvalidate, wicket-flickr)
 - testing (thread test, performance test)

I would like to be able to distinguish between these projects better,
but I am not sure how to implement that.

Wicket Stuff must be able to host all these different types of
projects. But it should also be easy to find what the intent is of a
project without putting too much burden on the users.

Maybe a repo layout as follows would help?

trunk/projects
trunk/examples
trunk/testing
trunk/concepts
branches/wicket-1.2/projects
branches/wicket-1.2/examples
branches/wicket-1.2/testing
branches/wicket-1.2/concepts

Where the projects directory contains the 'use' usecase, etc.

Efforts under trunk/projects could be required to perform releases for
at least newer wicket versions within a couple of months, and be moved
to concepts if they fail to do so. This is not to discount the effort
put in by the original author, but to give people an easy path to the
actively maintained projects.

However, that does impose some form of oversight, and given the
current state of Wicket Stuff, I doubt that it will ever happen, if it
doesn't come from us. It is just hard to find people with a sustained
interest in maintaining a project and actively working on its
progress. Databinder has a great maintainer, as does Dojo, and
scriptaculous. I also think gmap is maintained but it could benefit
from a release IMO.

Martijn

-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

> i do not use the project. i do not have time, nor honestly the desire, to
> fix every wicketstuff project i do not use. do you find that unfair?

Well you do have pretty strong opinions on the quality of the project
and the way it is 'managed'. And you seem to think something is wrong
with the project, but you never took the effort of sending one single
email about it.

> as for
> it being fixed on a version, do you think anyone would bump down their
> hibernate version just for an auxilary project?

Well, do you think the whole world immediately upgrades Hibernate
versions for their systems once one comes out? It's fixed on a G.A.
version, meaning that if people don't run into problems, they should
be fine staying on that release.

This whole issue is moot, and I fail to see what you wanted to achieve
with this in the first place. You surely weren't trying to help
getting it fixed.

Eelco

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Igor Vaynberg <ig...@gmail.com>]

i do not use the project. i do not have time, nor honestly the desire, to
fix every wicketstuff project i do not use. do you find that unfair? as for
it being fixed on a version, do you think anyone would bump down their
hibernate version just for an auxilary project? i think not. maybe no one
reported it because no one is using it, i dont know.

-igor


On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > what defines a project as alive? at the least it works, not just
> compiles.
> > take data-hibernate 3. it compiles, but doesnt work because it hasnt
> been
> > synced with hibernate 3 changes.
>
> It is fixed on a version in the POM, and to my knowledge it works with
> that version!
>
> > if someone was to pick it up, fix it so it
> > works, etc, then it can be moved into trunk again.
>
> If you think there is a problem with it, why didn't you just report
> it? If the problem you describe exists, it's a 5 minute fix. That
> would have been a possitive contribution.
>
> Eelco
>

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

> what defines a project as alive? at the least it works, not just compiles.
> take data-hibernate 3. it compiles, but doesnt work because it hasnt been
> synced with hibernate 3 changes.

It is fixed on a version in the POM, and to my knowledge it works with
that version!

> if someone was to pick it up, fix it so it
> works, etc, then it can be moved into trunk again.

If you think there is a problem with it, why didn't you just report
it? If the problem you describe exists, it's a 5 minute fix. That
would have been a possitive contribution.

Eelco

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Ryan Sonnek <ry...@gmail.com>]

> i think what we should do is create a two-tier system where projects that
> are alive are directly in trunk, while other projects are in a subdirectory
> of trunk. projects can move between these two tiers as needed.

Perhaps a wicket-stuff-incubator??  ideas can be tried out in the
incubator module and promoted to a top level if it becomes a "real"
project.  Now, the definition of what constitutes a "real" project is
still up to debate.  =)

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Igor Vaynberg <ig...@gmail.com>]

well, thats exactly it - very little is required to do this, just an svn
move. we should establish procedures/guidelines for what it takes to move
from tier 2 to tier 1 and viceversa, and where new projects start out.

-igor

On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > i think what we should do is create a two-tier system where projects
> that
> > are alive are directly in trunk, while other projects are in a
> subdirectory
> > of trunk. projects can move between these two tiers as needed.
>
> It would be interesting to see someone actively maintaining that. So
> far it's even been too much trouble doing simple API fixes by people
> who did API breaking changes, so tbh, I don't expect this to take off.
> But if there is at least some communication before doing moves with
> the project's committers, it's all fine.
>
> Eelco
>

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

> i think what we should do is create a two-tier system where projects that
> are alive are directly in trunk, while other projects are in a subdirectory
> of trunk. projects can move between these two tiers as needed.

It would be interesting to see someone actively maintaining that. So
far it's even been too much trouble doing simple API fixes by people
who did API breaking changes, so tbh, I don't expect this to take off.
But if there is at least some communication before doing moves with
the project's committers, it's all fine.

Eelco

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Igor Vaynberg <ig...@gmail.com>]

i love the fact that wicketstuff is both a playground (very little entry
barrier for anyone) and that it serves as a repository for additional wicket
modules. the problem is when i look into trunk i see ten thousand projects.
some are dead, some are half dead, and others are alive. how am i supposed
to know what is what?

i think what we should do is create a two-tier system where projects that
are alive are directly in trunk, while other projects are in a subdirectory
of trunk. projects can move between these two tiers as needed.

what defines a project as alive? at the least it works, not just compiles.
take data-hibernate 3. it compiles, but doesnt work because it hasnt been
synced with hibernate 3 changes. if someone was to pick it up, fix it so it
works, etc, then it can be moved into trunk again.

or something like that.

-igor

On 5/6/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> On 5/6/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > As a wicket-stuff developer, I for one would hate to see restrictions
> > placed on what can or can not be a wicket-stuff project.
>
> This was not a thread on what constitutes a wicket stuff project, but
> now that you brought it up :)
>
> In my vision, there is no restriction (bar the things sf.net policies
> and good taste prohibit) on what can be a Wicket Stuff project.
>
> > The beauty
> > of the wicket-stuff idea is that it is a playground for people try out
> > potentially cool ideas.  It's a place for people to learn how to use
> > wicket and build "possibly" cool widgets and tools.
>
> Yes, but we should be able to keep it clean/real, in that the SVN
> trunk does not end up as a dumping ground for dead projects and broken
> ideas.
>
> I would like the projects to be maintained (not as vigorously as
> wicket core is, but at least migrate with each release of Wicket, and
> get a download from either the maven repository or the sf.net download
> area).
>
> As such, I think the minimal requirements for a Wicket contrib project
> would be:
> - a page in the wicketstuff wiki explaining:
>      * what the project does
>      * who is maintaining it
>      * the intent of the project (example, actual usage, experiment, ?)
> - if the intent is actual usage: a release with at least each major
> wicket release
> - if the intent is example or experiment: description on how to get
> it and start with it
>
> I am in doubt on what to do with projects that don't get maintained:
> - letting them sit -> gives a bad experience for users trying the
> projects out (see maven), but allows new users to pick up the code and
> do something with it
> - removing them/moving to attic -> makes the projects invisible and
> virtually annihilates the opportunity of someone else picking the
> project up
>
> If a project that has been in limbo for a while has a viable
> alternative, I would opt to remove the dead project. If there is no
> alternative, I would opt to keep it.
>
> > I know that *my* project (wicketstuff-scriptaculous) has occasionally
> > been left "in the dark" for several months before a whole slew of
> > changes and features get built in.
>
> The scriptaculous project is actively maintained in my book: regular
> code additions, blog entries, etc. and would be an example for other
> projects. Thanks for that!
>
> > Sure, there may be a "better" wicket/hibernate project out there (aka:
> > databinder), but I really don't see any issues with that.  Especially
> > now that there's a wicket-stuff wiki, it can be clearly spelled out
> > there what each project's strengths/weaknesses are.
>
> But that was not even available for these projects. That prompted me
> to ask if these are actively maintained and what we should do with
> them. *Only* if they were not maintained I would want them be removed.
> In this particular case, I would now only opt for removing the
> distributables from the sf.net download site since these artifacts
> don't have any value at the moment other than confusing new users.
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>

Re: What constitutes a wicketstuff project? (was: Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3)

[Eelco Hillenius <ee...@gmail.com>]

I think it's simple. If the projects compile for a given branch, there
is no need to pull them out. And even if they don't compile for a
while - which didn't happen that much as I'm generally playing the
cleanup guy after API breaks -; as long as the Wicket branch they are
written for doesn't approach release mode yet, all is fine. Whether
core members think the projects are good or not is completely
irrelevant in the scope of these projects.

The projects that were part of the discussion compiled fine, had
plenty of JavaDocs explaining the uses, and even were part of one of
the most extensive examples we had: cdapp in wicket-stuff. And they
used Hibernate 2.2 ga, which is not the latest, but not ancient
either. The main reason for me wanting to keep the projects was
because of cdapp in wicket-contrib-examples. I still think it's a nice
example, and as no-one rewrote it for e.g. databinder or took some
action to improve the projects, I thought they were fine being there.
The reason why there was no project documentation on the wicket-wiki
yet is easy as well: I just didn't get around doing it yet because I
have too much other stuff on my plate (and also forgot about it I
guess).

Eelco

On 5/6/07, Martijn Dashorst <ma...@gmail.com> wrote:
> On 5/6/07, Ryan Sonnek <ry...@gmail.com> wrote:
> > As a wicket-stuff developer, I for one would hate to see restrictions
> > placed on what can or can not be a wicket-stuff project.
>
> This was not a thread on what constitutes a wicket stuff project, but
> now that you brought it up :)
>
> In my vision, there is no restriction (bar the things sf.net policies
> and good taste prohibit) on what can be a Wicket Stuff project.
>
> > The beauty
> > of the wicket-stuff idea is that it is a playground for people try out
> > potentially cool ideas.  It's a place for people to learn how to use
> > wicket and build "possibly" cool widgets and tools.
>
> Yes, but we should be able to keep it clean/real, in that the SVN
> trunk does not end up as a dumping ground for dead projects and broken
> ideas.
>
> I would like the projects to be maintained (not as vigorously as
> wicket core is, but at least migrate with each release of Wicket, and
> get a download from either the maven repository or the sf.net download
> area).
>
> As such, I think the minimal requirements for a Wicket contrib project would be:
>  - a page in the wicketstuff wiki explaining:
>      * what the project does
>      * who is maintaining it
>      * the intent of the project (example, actual usage, experiment, ?)
>  - if the intent is actual usage: a release with at least each major
> wicket release
>  - if the intent is example or experiment: description on how to get
> it and start with it
>
> I am in doubt on what to do with projects that don't get maintained:
>  - letting them sit -> gives a bad experience for users trying the
> projects out (see maven), but allows new users to pick up the code and
> do something with it
>  - removing them/moving to attic -> makes the projects invisible and
> virtually annihilates the opportunity of someone else picking the
> project up
>
> If a project that has been in limbo for a while has a viable
> alternative, I would opt to remove the dead project. If there is no
> alternative, I would opt to keep it.
>
> > I know that *my* project (wicketstuff-scriptaculous) has occasionally
> > been left "in the dark" for several months before a whole slew of
> > changes and features get built in.
>
> The scriptaculous project is actively maintained in my book: regular
> code additions, blog entries, etc. and would be an example for other
> projects. Thanks for that!
>
> > Sure, there may be a "better" wicket/hibernate project out there (aka:
> > databinder), but I really don't see any issues with that.  Especially
> > now that there's a wicket-stuff wiki, it can be clearly spelled out
> > there what each project's strengths/weaknesses are.
>
> But that was not even available for these projects. That prompted me
> to ask if these are actively maintained and what we should do with
> them. *Only* if they were not maintained I would want them be removed.
> In this particular case, I would now only opt for removing the
> distributables from the sf.net download site since these artifacts
> don't have any value at the moment other than confusing new users.
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>