incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <>
Subject Re: web site resources?
Date Tue, 03 Jan 2006 22:39:12 GMT
Hey Geir,

Ah, now I think I see the problem that you have probably stated 15  
times that I did not get before.

I totally agree that the website is an 'official release'. It should  
be well tested before publishing and like the official bits of a  
software release (the jar, install files etc) the site should be  
reviewed to be 'good' before going live.

Rather than checking in the generated resources though I'd prefer we  
have someone be the 'gatekeeper' of the official site and have them  
do the initial 'sanity check' then publish somewhere for others to  
test. Once the bits are deemed 'good' they can be pushed to the  
actual site. So here is a rough outline of a QA procedure for the  
website content.

1) Builder - builds site with mvn site and does an initial sanity check
2) Builder - once satisfied that the build is not a waste of anyone  
else's time pushes the site to an intermediate server
3) Builder - sends email to dev & user list stating that website X.X  
RC1 is available for review at http://intermediate/foo/index.html
4) Everyone interested clicks on the links reads the doc etc and  
files jira issues against the site
5) Repeat steps 1 - 4 until dev's are satisfied with the site
6) Builder - push the site out to official project site

I'd hope that this process roughly corresponds in timing and process  
to a release of a project but in my experience it rarely does. I'm  
not arguing that its good that site QA rarely happens, only that its  

Thoughts? I'm happy to be the site builder at least for the first  
time (although I will not be happy if I'm the only site builder :-)

Bill Dudney
MyFaces -
Wadi -

On Jan 3, 2006, at 3:22 PM, Geir Magnusson Jr wrote:

> Bill Dudney wrote:
>> Hi Geir,
>> Should we be putting JavaDoc into SVN? To me that is what this   
>> discussion boils down too. I don't like the idea of putting the   
>> results of a 'compile' into the repository.
> If you are "releasing" something at Apache, you want to do it in a  
> way that's accountable and traceable, because it's an action of the  
> ASF.
> Lets step back for a second.  This may be the basic problem :
> Do you recognize the website as a "official release" or "official  
> publication" of the project for which the project PMC is ultimately  
> responsible?
> If so, since the PMC chair is arguably legally responsible for the  
> contents of the site, if you were PMC chair, would you want some  
> way to demonstrate a system of effective oversight? Not a perfect  
> one.  Not an iron-clad one, but simply one that at least reduces  
> the changes of uncaught mistakes and errors?
>> In the same way that a jar file should not be checked in neither   
>> should a set of generated HTML files IMO.
> BTW, I understand the argument.  The problem is that I can't find  
> any other way to solve the problem.
> I assume that you use computers in a serious way to solve some kind  
> of business problem.  When you have something to deploy to  
> production, what is the path from developers desktop to production  
> execution?  I'm not expecting "we check it in" because many people  
> don't do that.  (nutty, actually - some of the best admins I know  
> ensure that everythign the have on a running machine is checked in  
> somewhere so they know to the byte what the config is...)
> But what can we do?  I'm open to anything, but want to ensure we  
> have some way for group oversight over what we're actually  
> publishing, or at least take reasonable, well thought out risks.   
> (JavaDoc is actually IMO a reasonable risk to not check in, I  
> believe...  hard to exactly explain why ;)
> geir
>> TTFN,
>> Bill Dudney
>> MyFaces -
>> Wadi -
>> On Jan 3, 2006, at 2:43 PM, Geir Magnusson Jr wrote:
>>> Jeff Genender wrote:
>>>> Geir Magnusson Jr wrote:
>>>>>> My point is we should follow the maven best practices as do  
>>>>>> most  other
>>>>>> maven driven sites.    Its not really important enough for me  
>>>>>> to  decide
>>>>>> one way or the other.  But I will point out that doing it this  
>>>>>> way
>>>>>> confuses where changes are made to the site as opposed to its   
>>>>>> generation
>>>>>> at the source level.  This will cause a disjoint.
>>>>> Why?
>>>> Why?  Because I now have HTML that can be edited *as well as* the
>>>> source.  If someone edits the HTML, and not the source, then the  
>>>> next
>>>> time the site is generated, the HTML is over written.  This is a
>>>> complete PITA.
>>> Why would you edit the HTML?   That's like editing the jar.
>>> edit the source material.  render the site.  check in the  
>>> generated  artifacts. deploy to website from svn.  simple.
>>> You haven't had a problem with Geronimo's approach, have you?
>>>> IMHO, doing the maven thing is a better way...thats my
>>>> less.  You won't change this.
>>> Thanks for keeping an open mind.
>>> Just as an exercise in helping me understand why your mind is so   
>>> made up, at least tell me why.  You haven't given one technical   
>>> reason other than "others do it".
>>> I've explained the benefits of checking in the artifacts :
>>> 1) it ensures that you know exactly what changes are going "to   
>>> production"
>>> 2) Others can oversee the same thing - what changes are going  
>>> "to  production"
>>> 3)It provides a log of exactly what went to production, when,  
>>> and  by whom, with history.
>>> Why is it better to *not* check in the artifacts?
>>>> I personally have subscribed to the site generation methodology  
>>>> and I
>>>> like it.  As for commits and seeing them, its very simple and a lot
>>>> easier to read a commit based on APT (almost plain text) than  
>>>> it  reading
>>>> the raw HTML, so I cannot agree with you on those points.
>>> Except you aren't publishing the APT.  Just like you don't  
>>> exceute  source, you execute binary - hence, you compile the  
>>> source and test  the binary.
>>> You are arguing that no testing or QA is needed.  I'm saying  
>>> that  it is.
>>> You still commit the APT anyway, so you can see that.  However,   
>>> changing source material for a site can change more than one  
>>> output  artifact. How do you check them if you only read the source?
>>>> Lets do this according to the Apache way and put out a vote to  
>>>> commit
>>>> the site or just the source.  It should end there.  If everyone  
>>>> wants
>>>> the site committed, then so be it.
>>> Calling for a vote mid conversation is not "the Apache way", nor  
>>> is  appealing to mob rule.
>>>> Is this ok?  Can we agree to disagree on the web site subject   
>>>> based on
>>>> our personal preferences and let the majority rule?
>>> I'd prefer to hear why it's better to publish blindly to  
>>> production  rather than commit the same materials and let others  
>>> have a chance  to review.  It doesn't change the tool you are  
>>> using - it just adds  some minor steps.
>>> All I'm suggesting is that after generating the material, you do  
>>> a  svn commit, ssh to the machine, svn co.  Yes, it's two  
>>> additional  [scriptable] steps, but I think that we get a lot out  
>>> of it.  I  don't think I've seen seen an argument to what the  
>>> downside is.
>>> geir
>>>> Jeff
>>>>> geir

View raw message