Hi David,

On Mon, Jan 09, 2006 at 10:45:59AM +0200, David Fraser wrote:
> I was a bit silly to post this just before going on holiday :-)

:-)

> Christian Lohmaier wrote:
> >On Fri, Dec 30, 2005 at 08:15:40PM +0200, David Fraser wrote:
> >  
> >>I'm trying to find out what's involved in certain CWSs. Using EIS I can 
> >>see the issues attached to a CWS but not what actual files have been 
> >>changed and the changes made.
> >>    
> >You can see the files once the cws is integrated.
> >  
> But that seems to me to defeat the whole purpose of being able to 
> browser through current CWS on a website.
> Collaboration is enhanced by being able to quickly see what others are 
> up to.

Well, the description should be telling you what the CWS is about
(unfortunately this usually is only something like "bugfixes for
<module>") and there is the list of issues that should contain more
info.

> >>So what I'd really like to do is get a patch that corresponds to all the 
> >>changes made in that CWS.
> >>    
> >Just update your tree to that CWS. (I always create a shadow-tree of
> >pristine sources and update that copy to a certain cws. This way you
> >only have to do "find . -type f" to see what files did actually change.
> >  
> Aha, but this will mess up my builds and do all kinds of things.

Please explain why you think that this will "mess up" your builds and
what other "all kinds of things" you expect to happen.

> I still 
> think its helpful to be able to see things quickly on the web.
> This is for fairly casual browsing, and I maintain that being able to 
> quickly see what others are up to makes a big difference.
> If I see someone is working on something I'm interested in, I can help.
> And unfortunately, its not always easy from looking at the CWS summaries 
> / list of issues, whereas seeing the patches makes it really clear

Well I disagree. 
In a path you can see that something was changed. But not necessarily
why. (And yes, developers tend to forget QA/other people when filing
issues, they just write: remove xy, change A + B and similar without
explaining why this is done...)

If you cannot tell from the list of issues what is going on, then the
issues are of bad quality.

(Surely it depends on what your goal is. Seeing /how/ a problem was
solved usually needs the code itself. Seeing /what and why/ something
was changed - this should be apparent by the issues.

> >>[...]
> >>2) In the mean time, it would be nice if either EIS or some other web 
> >>site provided such patches.
> >>    
> >What for? Just to be lagging behind all the time?
> >  
> >>They need not be generated dynamically, a 
> >>nightly run of cws-extract would be great and they could offer static 
> >>links to the patches.
> >>    
> >Again: What for? 

I repeat the question. Even if there was such thing as a set of patches
- who would use those?

> >>What do people think?
> >>    
> >I don't think this makes sense. If you're interested in the patches, you
> >probably have the sources already. So just checkout that particular cws
> >you're interested in or let cws create a patch/diff for the relevant
> >modules and you're done.
> >  
> See my comments above on collaboration. If other people don't think this 
> is useful, not much I can do except try write some scripts myself :-)

I guess I cannot understand your point since I'm not a programmer
myself. I cannot imagine that looking at a patch lets you get a quicker
idea of what is being done elsewhere. If you mean collaboration in the
sense of "working on the very same stuff", then again: You need the code
anyway, so why not simply use CVS directly?

> But I find the EIS website could be more helpful in letting me know what 
> a CWS is about. Maybe the patches aren't the most helpful thing here.
> In order to try understand a CWS, there is:
> 0) the name which often ends up being initials and a number, like 'os67'
> 1) a Description that is sometimes opaque, like 'Added features for OOo 
> 2.02'

Yes. The description often lacks real information.

> 2) A list of tasks. Sometimes a number of these are internal Sun tasks, 
> which don't provide any info. Other than that, listing the tasks in 
> IssueZilla is a helpful link, if IssueZilla responds :-)  What would be 
> helpful is to add the summaries of the issues here.

+1

> [...]

ciao
Christian
-- 
NP: Creed - Inside Us All

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to