Re: [RT] Accepting and managing Skin Packages

[David Crossley <cr...@apache.org>]

Ross Gardler wrote:
> I would love to see your skin made available (I too like it a great 
> deal). However, we need to discuss exactly how to accept this donation 
> over on the dev list (this mail is copied to the dev list and replies 
> will be sent there).

Could we please keep such discussions on the dev list.
The replies to the user list do not automatically come here.

Why have you called this thread a Random Thought? It sounds
like a proposal. Be aware that people often ignore RT threads
until they have time to investigate, whereas proposals need
the attention of committers.

> In the past Forrest has not wanted to accept new skins because we do not 
> have the resources to maintain them. Consequently, we added a 
> skin-packaging system that allowed people to develop skins and make them 
> available via an automatic download mechanism.

There were two reasons for not accepting new skins:
Need interested committers/developers to maintain them.
Concentrate our energy on developing one very useful skin.

> The hope was that we would be able to encourage people, such as 
> yourself, to make their skins available via a zip download from their 
> sites. The benefit would be more eyes on the skin and thus improvements 
> would be sent back to you.
> 
> Unfortunately, we have not exploited this feature. Now is the time for 
> us to do so, and your skin can be the first example of that feature 
> (would you believe it was added in 0.5 and we still don't use it - shame 
> on us)

Steady on. No-one has bothered to contribute a skin
via the download mechanism. So there is no shame on us.

> I think Forrest should accept your skin package in one form or another, 
> the question is how, I see our options as:
> 
> 1. Forrest accepts the skin and keeps it in SVN
> 
> I am -0 on this. We need to would then be forced to maintain the skin 
> and ensure that it is "correct" in the sense of everything is done the 
> right way. I would prefer we only maintain the one skin in our core and 
> utilise the skin packaging system in order to add more skins.

Actually there is another option that comes before
all of these. We enhance Pelt skin to be able to address
these needs, hopefully with patches from the community.
We have tried to encourage this option, but few people
are interested.

I think it is the best option (apart from the views plugin).
We work as a community to develop one really good skin that
can address most needs and enables people to configure it.

> 2. We make all non-core skins available via a skins sub project within 
> Forrest
> 
> In this instance we would create a new project for contributed skins. 
> Anyone donating a skin will automatically get commit access to this 
> sub-project (but not to Forrest itself).
> 
> I am +1 for this if it is possible within the Apache Infrastructure. It 
> ensures that there will be at least one person with commit access with a 
> vested interest in maintaining the skin and in applying any contributed 
> patches.
> 
> Does the way our SVN is set up allow this?

This option does not absolve us from needing to oversee
all the commits and collaborate to keep the skin maintained.

It is my opinion that the Forrest project is not yet ready
to cope with the extra work of overseeing people who are
not interested in the Forrest project itself.

As far as i know, the ASF is still geared towards having
full committers. This concept of partial committer i have
not heard of before, other than some discussions here at
Forrest when we were establishing our project guidelines
to be sure to enable that possibility in the future.

> 3. The skin author makes it available via a ZIP download using the 
> skin-package system
> 
> I am +0 for this. I would prefer to see a solution that makes the skin 
> available through a version control mechanism to simplify patches. If 
> only a skin-package zip is provided it will make it difficult for people 
> to contribute to the skin.
> 
> 4. The skin author donates the skin to an external Open Source project 
> and uses that projects CVS/SVN etc.
> 
> This is kind of a half way house between option 2 and option 3. In the 
> past we tried to set-up a Sourceforge project for this, but it was 
> rejected as the project would not generate program code. I will offer 
> the Burrokeet project on SF since this uses Forrest at its core so the 
> housing of Forrest skins is appropriate within that project. I do not 
> have any problems adding skin contributors to that project to ensure 
> they have commit access. Of course, there may be other projects that are 
> appropriate.
> 
> 
> ---
> 
> Whatever we do, we should encourage the use of skin packages and we 
> should extend the system to list "official" skins in the same way the 
> plugin system does, see 
> http://forrest.apache.org/0.7/docs/plugins/index.html
> 
> Comments, ideas?

I am very concerned that we told Thorsten that we had no time
to review the "views" plugin proposal, which i gather will
address many "skin" needs, yet we are finding time to revisit
the skins situation.

--David

Re: [RT] Accepting and managing Skin Packages

[David Crossley <cr...@apache.org>]

Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> 
> >Why have you called this thread a Random Thought? It sounds
> >like a proposal. Be aware that people often ignore RT threads
> >until they have time to investigate, whereas proposals need
> >the attention of committers.
> 
> Because there are a number of options available and I am sure I missed 
> some. Furthermore, with the move to views in 0.8 this "proposal" may be 
> seen as a waste of time.

I reckon that that is exactly what a Proposal is. Other
options will come out during the discussion, some will
be shown to be ineffective. At the end of the Proposal
discussion we will probably already have the final solution.

> >>2. We make all non-core skins available via a skins sub project within 
> >>Forrest
> >>
> >>In this instance we would create a new project for contributed skins. 
> >>Anyone donating a skin will automatically get commit access to this 
> >>sub-project (but not to Forrest itself).
> >>
> >>I am +1 for this if it is possible within the Apache Infrastructure. It 
> >>ensures that there will be at least one person with commit access with a 
> >>vested interest in maintaining the skin and in applying any contributed 
> >>patches.
> >>
> >>Does the way our SVN is set up allow this?
> >
> >This option does not absolve us from needing to oversee
> >all the commits and collaborate to keep the skin maintained.
> >
> >It is my opinion that the Forrest project is not yet ready
> >to cope with the extra work of overseeing people who are
> >not interested in the Forrest project itself.
> 
> My intention was to have a lower barrier to entry for committers working 
> on skins. These are the kinds of developers who will take an active 
> interest in views.
> 
> It is possible to work on skins without knowing the internals of 
> Forrest, this will also be true of views once we get time to assist 
> Thorsten in finishing them off. As these developers become more familiar 
> with Forrest as a whole they may eventually become full committers.
>
> >As far as i know, the ASF is still geared towards having
> >full committers. This concept of partial committer i have
> >not heard of before, other than some discussions here at
> >Forrest when we were establishing our project guidelines
> >to be sure to enable that possibility in the future.
> 
> OK, I thought that would be the case, so this is not an option.

This is a great idea that we have talked about in the past.
When the dust has settled after releasing 0.7 we can
work towards eanbling that.

--David

Re: [RT] Accepting and managing Skin Packages

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> On Thu, 2005-06-02 at 10:08 +0100, Ross Gardler wrote:
> <snip/>
> 
>>I should have made the subject "attracting skins/views developers 
>>through skin-packages"
>>
>>Thorsten, does this make any sense or am I going down a dead end here?
> 
> 
> IMO part 1 no, part 2 yes. 
> 
> View development is different from skin development this is why I think
> we will hardly attract new view devs through skin-packages. We only will
> have more work but hardly any benefit out of it. That is my *personal*
> opinion.

OK. I'll "cease and dissist" your *personal* opinion is all that counts 
on views right now since we don't know them well enough yet.

Ross

Re: [RT] Accepting and managing Skin Packages

[Thorsten Scherler <th...@apache.org>]

On Thu, 2005-06-02 at 10:08 +0100, Ross Gardler wrote:
<snip/>
> I should have made the subject "attracting skins/views developers 
> through skin-packages"
> 
> Thorsten, does this make any sense or am I going down a dead end here?

IMO part 1 no, part 2 yes. 

View development is different from skin development this is why I think
we will hardly attract new view devs through skin-packages. We only will
have more work but hardly any benefit out of it. That is my *personal*
opinion.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: [RT] Accepting and managing Skin Packages

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> Ross Gardler wrote:
> 
>>I would love to see your skin made available (I too like it a great 
>>deal). However, we need to discuss exactly how to accept this donation 
>>over on the dev list (this mail is copied to the dev list and replies 
>>will be sent there).
> 
> 
> Could we please keep such discussions on the dev list.
> The replies to the user list do not automatically come here.

Hmmm, I was setting the reply-to header thinking that this would 
override the users mailing list reply-to. However, you are right, this 
is not the case. I'll change my method for moving to the dev list.

> Why have you called this thread a Random Thought? It sounds
> like a proposal. Be aware that people often ignore RT threads
> until they have time to investigate, whereas proposals need
> the attention of committers.

Because there are a number of options available and I am sure I missed 
some. Furthermore, with the move to views in 0.8 this "proposal" may be 
seen as a waste of time.

...

>>The hope was that we would be able to encourage people, such as 
>>yourself, to make their skins available via a zip download from their 
>>sites. The benefit would be more eyes on the skin and thus improvements 
>>would be sent back to you.
>>
>>Unfortunately, we have not exploited this feature. Now is the time for 
>>us to do so, and your skin can be the first example of that feature 
>>(would you believe it was added in 0.5 and we still don't use it - shame 
>>on us)
> 
> 
> Steady on. No-one has bothered to contribute a skin
> via the download mechanism. So there is no shame on us.

I believe some will donate their skins if we ask them to, we haven't 
been asking, so shame on us (or me if you prefer, since I think this is 
important, I've been here since 0.5 and *I* haven't been asking ;-)

>>I think Forrest should accept your skin package in one form or another, 
>>the question is how, I see our options as:
>>
>>1. Forrest accepts the skin and keeps it in SVN
>>
>>I am -0 on this. We need to would then be forced to maintain the skin 
>>and ensure that it is "correct" in the sense of everything is done the 
>>right way. I would prefer we only maintain the one skin in our core and 
>>utilise the skin packaging system in order to add more skins.
> 
> 
> Actually there is another option that comes before
> all of these. We enhance Pelt skin to be able to address
> these needs, hopefully with patches from the community.
> We have tried to encourage this option, but few people
> are interested.
> 
> I think it is the best option (apart from the views plugin).
> We work as a community to develop one really good skin that
> can address most needs and enables people to configure it.

Yes, in the case of this particular skin we can probably work the 
changes back into Pelt. However, could does not mean should. I would not 
propose doing that since it will take developer effort and, as you point 
out later in your reply, our developer effort should be on the 
forthcoming views. This particular skin is already working and looks 
great, so why not use it as-is (well with the removal or the committing 
back of changes to common).

Perhaps this point indicates we should just ask the author to make it 
available as a skin package for download. It's the simplest solution 
with the least developer effort.

>>2. We make all non-core skins available via a skins sub project within 
>>Forrest
>>
>>In this instance we would create a new project for contributed skins. 
>>Anyone donating a skin will automatically get commit access to this 
>>sub-project (but not to Forrest itself).
>>
>>I am +1 for this if it is possible within the Apache Infrastructure. It 
>>ensures that there will be at least one person with commit access with a 
>>vested interest in maintaining the skin and in applying any contributed 
>>patches.
>>
>>Does the way our SVN is set up allow this?
> 
> 
> This option does not absolve us from needing to oversee
> all the commits and collaborate to keep the skin maintained.
> 
> It is my opinion that the Forrest project is not yet ready
> to cope with the extra work of overseeing people who are
> not interested in the Forrest project itself.

My intention was to have a lower barrier to entry for committers working 
on skins. These are the kinds of developers who will take an active 
interest in views.

It is possible to work on skins without knowing the internals of 
Forrest, this will also be true of views once we get time to assist 
Thorsten in finishing them off. As these developers become more familiar 
with Forrest as a whole they may eventually become full committers.

> As far as i know, the ASF is still geared towards having
> full committers. This concept of partial committer i have
> not heard of before, other than some discussions here at
> Forrest when we were establishing our project guidelines
> to be sure to enable that possibility in the future.

OK, I thought that would be the case, so this is not an option.

...

>>Comments, ideas?
> 
> 
> I am very concerned that we told Thorsten that we had no time
> to review the "views" plugin proposal, which i gather will
> address many "skin" needs, yet we are finding time to revisit
> the skins situation.

See above comment about 0.8 development. My hope is that we can get more 
people with a personal interest in the skinning/views aspect of Forrest 
to have a more direct involvement with Forrest. That is those who can 
achieve what they want in terms of functionality, but desire their own 
look and feel.

In other words I am hoping to attract people who can assist Thorsten. In 
the meantime there is nothing stopping us from extending the range of 
skins available through the skin packaging system. We have many users of 
0.6 and they will take some time to upgrade to 0.7 (yet to be released) 
and then 0.8 (which is when views are introduced).

I should have made the subject "attracting skins/views developers 
through skin-packages"

Thorsten, does this make any sense or am I going down a dead end here?

Ross

Re: [RT] Accepting and managing Skin Packages

[Ferdinand Soethe <sa...@soethe.net>]

Thorsten Scherler wrote:

> IMO the only thing that we can and should accept is the CSS of Claudia.
> Skins ("old fashion" - the ones we have right now) are horror for
> maintainment (and there are only few that really maintain them). More so
> if they change common skin stylesheets.

I'd like to talk about 'making available' rather than 'accept' here to
make it clear that Forrest Project is not responsible or has to
maintain these skins.


But having said that, I suggest that we leave that decision up to the
people wanting to look at and use that skin? If at some point they
find that this skin does not follow Forrest's improvements anymore,
they can still opt out of using it.


> Per definition the result of a skin is a html skeleton that contains css
> markup and features. Features of skins are contracts. A skin provider
> can decide which contracts to offer (Claudia stated that they riped
> parts out of the skin). Now using this beautiful skin of her would mean
> we have to add this parts again and create a new "old fashion" skin.
> That leads to an endless circle of work on "old fashion" skins.

I don't see why we have to do any of that. Just add a short
disclaimer the way Claudia did and let people make up their own mind
about it.

> IMO we should focus to implement views and not adding more (endless)
> work with "old fashion" skins. In views Claudia would provide a
> default.fv, the default.css and a couple of new contracts (if needed,
> which can either override the common ones by providing new
> implementations of them or providing new contracts), which all are
> easily maintainable. I am -1 for dedicating any energy on "old fashion"
> skins that are in my eyes a dead end. 

Great! If that is so, then Claudia and other people wanting to use
that skin will probably go for it as soon as views is stable and
available.

Pls. try to look at it from a users point of view. People who want/need
a nice design now cannot not use views (alpha) at such an early stage
for a production site.

And if they work on tweaking pelt to look that way it will probably
take a lot more time than using or improving Claudia's skin.

So can we please not stand in the way of these people?

--
Ferdinand Soethe

Re: [RT] Accepting and managing Skin Packages

[Thorsten Scherler <th...@apache.org>]

On Thu, 2005-06-02 at 15:49 +1000, David Crossley wrote:
> Ross Gardler wrote:
<snip>
> > 
> > 1. Forrest accepts the skin and keeps it in SVN
> > 
> > I am -0 on this. We need to would then be forced to maintain the skin 
> > and ensure that it is "correct" in the sense of everything is done the 
> > right way. I would prefer we only maintain the one skin in our core and 
> > utilise the skin packaging system in order to add more skins.
> 
> Actually there is another option that comes before
> all of these. We enhance Pelt skin to be able to address
> these needs, hopefully with patches from the community.
> We have tried to encourage this option, but few people
> are interested.
> 
> I think it is the best option (apart from the views plugin).
> We work as a community to develop one really good skin that
> can address most needs and enables people to configure it.
> 

IMO the only thing that we can and should accept is the CSS of Claudia.
Skins ("old fashion" - the ones we have right now) are horror for
maintainment (and there are only few that really maintain them). More so
if they change common skin stylesheets.

Per definition the result of a skin is a html skeleton that contains css
markup and features. Features of skins are contracts. A skin provider
can decide which contracts to offer (Claudia stated that they riped
parts out of the skin). Now using this beautiful skin of her would mean
we have to add this parts again and create a new "old fashion" skin.
That leads to an endless circle of work on "old fashion" skins.

IMO we should focus to implement views and not adding more (endless)
work with "old fashion" skins. In views Claudia would provide a
default.fv, the default.css and a couple of new contracts (if needed,
which can either override the common ones by providing new
implementations of them or providing new contracts), which all are
easily maintainable. I am -1 for dedicating any energy on "old fashion"
skins that are in my eyes a dead end. 

It makes more sense to finish views and address the skin package
facility for views.

<snip>
> > 
> > 4. The skin author donates the skin to an external Open Source project 
> > and uses that projects CVS/SVN etc.
> > 
> > This is kind of a half way house between option 2 and option 3. In the 
> > past we tried to set-up a Sourceforge project for this, but it was 
> > rejected as the project would not generate program code. I will offer 
> > the Burrokeet project on SF since this uses Forrest at its core so the 
> > housing of Forrest skins is appropriate within that project. I do not 
> > have any problems adding skin contributors to that project to ensure 
> > they have commit access. Of course, there may be other projects that are 
> > appropriate.
> > 
> > 
> > ---
> > 
> > Whatever we do, we should encourage the use of skin packages and we 
> > should extend the system to list "official" skins in the same way the 
> > plugin system does, see 
> > http://forrest.apache.org/0.7/docs/plugins/index.html
> > 
> > Comments, ideas?
> 
> I am very concerned that we told Thorsten that we had no time
> to review the "views" plugin proposal, which i gather will
> address many "skin" needs, yet we are finding time to revisit
> the skins situation.

Yeah, you hit the nail on the head. 

IMO we should *not* encourage the use of skin packages but rather the
development and usage of views. I started views firstly only to address
"skin" needs. That means we are splitting our resources apart where we
should bundle them by talking about and encouraging the outdated "old
fashion" skins. 

...and sure you only can encourage something that you have reviewed.

Just my 2 cents.
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)