Re: [dev] CWS for non-Domain Developer
Hi Heiner OK that explains why its done like this. I was just trying to point out that collaboration can be aided by access to information. So maybe I need to try and get commit rights. Cheers David Jens-Heiner Rechtien wrote: H David, EIS is mostly useful for developers with commit rights. Since we can't easily discern reading or writing EIS services (making a service secure is far more difficult than just controlling the access to a service), we need a kind of authorization for every access. Since developers with commit rights all have CVS passwords, this seemed to be the right choice without requiring everyone to come up with yet another password but without compromising on security either. The easiest way to keep track of a CWS is to use a Bonsai, as others have rightly noted. Heiner David Fraser wrote: Hi 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. So what I'd really like to do is get a patch that corresponds to all the changes made in that CWS. The cws tools (and the ooo-build enhancement cws-extract) should be able to do that. However, because I'm not a Domain Developer and don't have a OOo CVS account, I can't access the EIS SOAP service that lets you do that. So two proposals: 1) It would be nice to access the EIS SOAP service without a CVS write account 2) In the mean time, it would be nice if either EIS or some other web site provided such patches. They need not be generated dynamically, a nightly run of cws-extract would be great and they could offer static links to the patches. What do people think? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CWS for non-Domain Developer
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]
Re: [dev] CWS for non-Domain Developer
Christian Lohmaier wrote: 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. Doing an actual cvs update to the CWS may affect files I have currently changed. But I can do a cvs diff rather to get the diff between the branches so this isn't really an issue 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. As you agreed below, Issue summaries in the EIS page would help in seeing why changes are made. [...] 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? Me. So I'm writing scripts to do this for myself more easily as it doesn't seem to be a widespread need. 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? I mean collaboration in the sense of wanting to know what other people are doing. Visibility is great. But anyway I think I have the neccessary information to do what I want know, so thats fine. Cheers David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CWS for non-Domain Developer
H David, EIS is mostly useful for developers with commit rights. Since we can't easily discern reading or writing EIS services (making a service secure is far more difficult than just controlling the access to a service), we need a kind of authorization for every access. Since developers with commit rights all have CVS passwords, this seemed to be the right choice without requiring everyone to come up with yet another password but without compromising on security either. The easiest way to keep track of a CWS is to use a Bonsai, as others have rightly noted. Heiner David Fraser wrote: Hi 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. So what I'd really like to do is get a patch that corresponds to all the changes made in that CWS. The cws tools (and the ooo-build enhancement cws-extract) should be able to do that. However, because I'm not a Domain Developer and don't have a OOo CVS account, I can't access the EIS SOAP service that lets you do that. So two proposals: 1) It would be nice to access the EIS SOAP service without a CVS write account 2) In the mean time, it would be nice if either EIS or some other web site provided such patches. They need not be generated dynamically, a nightly run of cws-extract would be great and they could offer static links to the patches. What do people think? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] CWS for non-Domain Developer
Hi 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. So what I'd really like to do is get a patch that corresponds to all the changes made in that CWS. The cws tools (and the ooo-build enhancement cws-extract) should be able to do that. However, because I'm not a Domain Developer and don't have a OOo CVS account, I can't access the EIS SOAP service that lets you do that. So two proposals: 1) It would be nice to access the EIS SOAP service without a CVS write account 2) In the mean time, it would be nice if either EIS or some other web site provided such patches. They need not be generated dynamically, a nightly run of cws-extract would be great and they could offer static links to the patches. What do people think? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CWS for non-Domain Developer
Hi David, 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. 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. The cws tools (and the ooo-build enhancement cws-extract) should be able to do that. You can do that even without the tools. cvs can do (r)diffs between different branches/revisions as well. It might be not as efficient since it operates on all the files and not only on those that actually were changed, but since the information is not available until the cws is integrated, the cwstools would have to do the same thing anyway. [...] 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? 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. ciao Christian -- NP: Paradise Lost - Colossal Rains - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
