incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: web site resources?
Date Tue, 03 Jan 2006 23:13:49 GMT
This probably states things as closely to how I feel on this issue and
agree with the statement that Bill made about 15 times explained and not
getting until now.  There was clearly a communication gap here.

With that said, I like Bill's idea as it mitigates this issue.

Bill Dudney wrote:
> 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 common.
> 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
>>>>>>> decide
>>>>>>> one way or the other.  But I will point out that doing it this
>>>>>>> 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