incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: web site resources?
Date Tue, 03 Jan 2006 22:41:08 GMT


Jeff Genender wrote:
> 
> Geir Magnusson Jr wrote:
> 
> 
>>Why would you edit the HTML?   That's like editing the jar.
> 
> 
> Ok..so then who checks in jars?  Not many people do.  So why would we
> check in our output?

See my other message to Bill.

The underlying premise of where I'm coming from is :

"The website is a 'release' of the project"

The question that follows :

"How do we ensure we have a demonstrable process that's scalable, 
transparent, etc to ensure that we know what's getting published?  What 
can we do to minimize errors and increase general awareness of what's 
getting published?"

> 
> 
>>You haven't had a problem with Geronimo's approach, have you?
> 
> 
> Its a different paradigm...yes?  Are we not using a tool like maven to
> create the site.

What possible difference could it make which tool generates the bits in 
the html file?

I could probably script the "deploy" as well from ant.  Or we could 
script the checkin, ssh, checkout w/ maven....

Forget the tool - think about the policy.


> 
> 
>>>IMHO, doing the maven thing is a better way...thats my opinion...no
>>>more...no less.  You won't change this.
>>
>>Thanks for keeping an open mind.
> 
> 
> Oh come on Geir...this is a ludicrous statement.  My mind is open...

"You won't change this"

>I
> just prefer to do it a way I am most comfortable with, just as you do
> with your way.  We are beating a really dead horse here...its really not
> a big deal.  Lets vote on it and go the route all want to go...is that
> closed minded?

I think you are stuck on the tool.

What is the "way that you are comfortable with"?

Just typing "deploy"?  If I script that so it does a checkin, ssh, and 
checkout, would you be satisfied?

> 
> 
>>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 have and I explained myself clearly.  We don't source control the
> output of a generated website for the same reason we do not source
> control a jar.  Its the output of the source.  The "source control"
> should be implemented on the "source".  Also *sigh* confusion over which
>  is the editable version...the output or the source.

IMO, you haven't explained the downside of putting what we publish in 
the "configuration management system" (changed from "source control" so 
we don't get hung up on teh semantics...)

> 
> 
>>I've explained the benefits of checking in the artifacts :
>>
>>1) it ensures that you know exactly what changes are going "to production"
> 
> 
> So can the source.

C'mon Jeff - the source isn't going to production.

> 
> 
>>2) Others can oversee the same thing - what changes are going "to
>>production"
> 
> 
> Source helps too...they can do a "mvn site".  Its a 2 second process.
> We can also deploy to a "dev" site, yes?

No, please.  Not a staging server....

> 
> 
>>3)It provides a log of exactly what went to production, when, and by
>>whom, with history.
> 
> 
> Does the source not show this?

Because one source change can result in n output changes.

> 
> 
>>
>>Why is it better to *not* check in the artifacts?
> 
> 
> Duplicated effort.  Confusion over what is edited...the source or the
> output.

I never buy this argument.  I would assume that someone qualified to 
work on enterprise clustering can understand "DON'T EDIT THE GENERATED HTML"

> 
> 
>>>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.
> 
> 
> No...who said that? I surely didn't.

Well, where is the QA then?

> 
> 
>>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?
> 
> 
> DeDeploy to a "dev" site.  Say...incubator.apache.org/dev.  Or run "mvn
> site" yourself.

Why is that more efficient?

> 
> 
>>>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.
>>
> 
> 
> How is it then?  You and I agree to disagree...we both want to do it our
> way...allow others to chime in.  In the end it will come to a vote.
> IMHO, this is a such a beaten horse and small factor...as well as we
> have much bigger fish to fry...we are wasting wayyyyy too much energy on
> this.  I am confused...how is voting not the Apache Way or not bring a
> resolution to this?

I believe that voting should be a last resort, that working to find 
consensus is healthier when it's something like this.

I find it very rude when someone just throws a vote out there in a 
discussion.   It's "legal", but we do have to learn to bring discussions 
like this to reasonable closure.

That said, it's only my opinion.  Call for a vote if you need to.


> 
> 
>>>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.
> 
> 
> I think we have gone over this several times.  Create a dev site.  Let
> people make their comments on that.  Seems to me like a good happy medium.
> 

No thanks.  It means that people can't incorporate oversight into their 
daily workflow, which for me and I think hundreds of others is scanning 
over commit message from svn.  I personally wouldn't be going off to the 
dev website for every source commit to hunt down all the places that the 
output could have changed.

> 
>>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.
> 
> 
> I have and I did...we are checking in output and its like checking in
> our jars.  Confusion over what gets edited...the source or the
> output...thats the huge downside.

I think the confusion issue is a strawman.  I don't know what to tell 
you.  I won't advocate checking in jars, becuase we have other process 
that provides oversight.

Think of svn as "configuration control" rather than "source control" if 
that helps.  I dunno.


> 
> Have I repeated myself enough?  We are going in circles on this...lets
> come to a quick conclusion on this...please.

Do what you want. You have my 0.02.

geir


Mime
View raw message