[opensuse-buildservice] osc release with new features
Hi, Short changelog: - new "search" command - new "meta" command - initial support for commit messages - new "log" command (commit log) Full changelog: - added initial search support (some ideas are taken from the webclient): * when searching a package/project it is also possible to search for the search term in the <title /> and <description /> elements of a package/project. * show only exact matches - new meta command, replacing editmeta, editprj, createprj, editpac, createpac, edituser. Can either show existing meta, or edit it (--edit), or upload content (--file). Fix metadata change detection, which no longer relies on the timestamp of the temporary file. - log: - renamed previous "log" command to "buildlog" (short: bl) - implementing a log command to review the commit log - commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc. - other changes: - api now sends HTTP/1.1 400 Bad Request for invalid xml. Thus, show the reply body because it contains helpful info. - if PUT on metadata fails with a 500, and http_debug is True, print out the body of the server reply - improved exception handling in some places - updatepacmetafromspec: read spec files in utf-8, or whatever the preferred encoding is in the locale Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- new "search" command
Stupid question: would a patch seem useful to add an option, which prints out URLs to the project directories on the download server?? Like this: poeml@batavia510 ~ % osc search --repos-baseurl quilt No matches found for 'quilt' in projects #################################################################### matches for 'quilt' in packages: # Package # Project # URL stgit devel:tools:scm http://download.opensuse.org/repositories/devel:/tools:/scm/ stgit openSUSE:Factory http://download.opensuse.org/repositories/openSUSE:/Factory/ quilt openSUSE:Factory http://download.opensuse.org/repositories/openSUSE:/Factory/ quilt home:fseidel http://download.opensuse.org/repositories/home:/fseidel/ stgit home:tiwai http://download.opensuse.org/repositories/home:/tiwai/ quilt Ports:DebianBased http://download.opensuse.org/repositories/Ports:/DebianBased/ quilt devel:tools:scm http://download.opensuse.org/repositories/devel:/tools:/scm/ quilt Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ gquilt Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ guilt Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ stgit Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ quilt-el Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
* Dr. Peter Poeml <poeml@suse.de> [2007-07-26 17:42]:
On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- new "search" command
Stupid question: would a patch seem useful to add an option, which prints out URLs to the project directories on the download server?? Like this:
I'd like some functionality that also prints the full RPM URL. Like when I specify openSUSE_10.2 and x86_64 then I'd get all URLs that can be used to install the package. ;) Thanks, Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Jul 26, 2007 at 05:50:21PM +0200, Bernhard Walle wrote:
* Dr. Peter Poeml <poeml@suse.de> [2007-07-26 17:42]:
On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- new "search" command
Stupid question: would a patch seem useful to add an option, which prints out URLs to the project directories on the download server?? Like this:
I'd like some functionality that also prints the full RPM URL. Like when I specify openSUSE_10.2 and x86_64 then I'd get all URLs that can be used to install the package. ;)
I had you in mind with that ;) but for a full binary list, I think it would be better to add a specific binarysearch command which could be used to search for binaries (only in certain repositories, maybe). FYI, the api provides functions for listing binaries, and to download them. It is just a matter of defining a useful user interface this! Moreover, I think it would be good to have some kind of "repo mirroring" script which syncs a repository to the local filesystem. It would be very useful for developers who want to test stuff locally before publishing to the users. Thinking of reposync (part of yum-utils) -- which needs to be changed to work with remote buildservice repositories (instead of yum sources configured in the system, which is what reposync requires). Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Thursday 26 July 2007 19:12:21 wrote Dr. Peter Poeml:
On Thu, Jul 26, 2007 at 05:50:21PM +0200, Bernhard Walle wrote:
* Dr. Peter Poeml <poeml@suse.de> [2007-07-26 17:42]:
On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- new "search" command
Stupid question: would a patch seem useful to add an option, which prints out URLs to the project directories on the download server?? Like this:
I'd like some functionality that also prints the full RPM URL. Like when I specify openSUSE_10.2 and x86_64 then I'd get all URLs that can be used to install the package. ;)
I had you in mind with that ;) but for a full binary list, I think it would be better to add a specific binarysearch command which could be used to search for binaries (only in certain repositories, maybe).
or based on certain repos like only on openSUSE:10.1 or only on KDE:KDE4/openSUSE_Factory . This is something what Andreas is implementing in the end user web interface ...
FYI, the api provides functions for listing binaries, and to download them. It is just a matter of defining a useful user interface this!
Moreover, I think it would be good to have some kind of "repo mirroring" script which syncs a repository to the local filesystem. It would be very useful for developers who want to test stuff locally before publishing to the users.
yes ! you read my mind :)
Thinking of reposync (part of yum-utils) -- which needs to be changed to work with remote buildservice repositories (instead of yum sources configured in the system, which is what reposync requires).
Peter
-- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Jul 26, 2007 at 07:23:44PM +0200, Adrian Schröter wrote:
would be better to add a specific binarysearch command which could be used to search for binaries (only in certain repositories, maybe).
or based on certain repos like only on openSUSE:10.1 or only on KDE:KDE4/openSUSE_Factory . This is something what Andreas is implementing in the end user web interface ...
Great! A projected osc command could, by the way, also guess the installed distro of the system it runs in, and find just the appropriate binaries...
FYI, the api provides functions for listing binaries, and to download them. It is just a matter of defining a useful user interface this!
Moreover, I think it would be good to have some kind of "repo mirroring" script which syncs a repository to the local filesystem. It would be very useful for developers who want to test stuff locally before publishing to the users.
yes ! you read my mind :)
No, you mine ;)
Thinking of reposync (part of yum-utils) -- which needs to be changed to work with remote buildservice repositories (instead of yum sources configured in the system, which is what reposync requires).
Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Hi, I recently implemented a different commit method in osc, when I added the -m/-F option: On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc.
Did anyone test this? (Either by setting "do_commits = 1" in .oscrc, or by using commit -m) I would like to make this the default behaviour, but I'm hesitant as long as I fear that I'm the only one testing this. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Aug 9, 2007, at 1:38 PM, Dr. Peter Poeml wrote:
Hi,
I recently implemented a different commit method in osc, when I added the -m/-F option:
On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc.
Did anyone test this?
works great here
(Either by setting "do_commits = 1" in .oscrc, or by using commit -m)
commit -m
I would like to make this the default behaviour, but I'm hesitant as long as I fear that I'm the only one testing this.
nope - just hadn't needed to update the package for a while. one question... how will updates made via the web interface be handled? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello,
- commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc.
Did anyone test this?
works great here
No problems here as well using commit -m. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 8/13/07, Andrew Beekhof <abeekhof@suse.de> wrote:
On Aug 9, 2007, at 1:38 PM, Dr. Peter Poeml wrote:
Hi,
I recently implemented a different commit method in osc, when I added the -m/-F option:
On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc.
Did anyone test this?
(Either by setting "do_commits = 1" in .oscrc, or by using commit -m)
I've set "do_commits = 1" in .oscrc, everything works great, i haven't noticed any difference from without that line, should there be any? Cheers -J --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2007-08-13 20:30:30 +0530, CyberOrg wrote:
On 8/13/07, Andrew Beekhof <abeekhof@suse.de> wrote:
On Aug 9, 2007, at 1:38 PM, Dr. Peter Poeml wrote:
Hi,
I recently implemented a different commit method in osc, when I added the -m/-F option:
On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:
- commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc.
Did anyone test this?
(Either by setting "do_commits = 1" in .oscrc, or by using commit -m)
I've set "do_commits = 1" in .oscrc, everything works great, i haven't noticed any difference from without that line, should there be any?
Hmm it more or less happens behind the scenes. If you add "do_commits = 1" to your ~/.oscrc all commits will be logged on the server (with -m or -F you can add a commit message). See https://api.opensuse.org/apidocs#22. To display the log messages etc. you can use "osc log" (see osc help log too). Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Aug 13, 2007 at 03:30:48PM +0200, Dirk Stoecker wrote:
No problems here as well using commit -m.
On Mon, Aug 13, 2007 at 08:30:30PM +0530, CyberOrg wrote:
I've set "do_commits = 1" in .oscrc, everything works great, i haven't noticed any difference from without that line, should there be any?
Thanks for the other confirmations as well... no, no difference should be noticeable, except that the committer's name shows up in the commit log, and the message if any was given. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Mon, Aug 13, 2007 at 03:26:42PM +0200, Andrew Beekhof wrote:
I recently implemented a different commit method in osc, when I added the -m/-F option: Did anyone test this?
works great here
Cool, thanks! I'll make it the default later today.
one question... how will updates made via the web interface be handled?
Not sure what you mean with "updates made via the web interface", could you explain please? Do you mean, with regard to committing / commit message? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, Aug 14, 2007 at 10:37:41AM +0200, Dr. Peter Poeml wrote:
On Mon, Aug 13, 2007 at 03:26:42PM +0200, Andrew Beekhof wrote:
I recently implemented a different commit method in osc, when I added the -m/-F option: Did anyone test this?
works great here
Cool, thanks!
I'll make it the default later today.
I would like to hear your opinion about something. Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional. The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does. Or if the current behaviour should remain. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On 8/14/07, Dr. Peter Poeml <poeml@suse.de> wrote:
Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.
The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.
Or if the current behaviour should remain.
If it is enforced, any way to continue using the script like this? for i in a b c do cd $i osc ci cd .. done I sometime make all the changes in many packages and run the script. Ciao -J --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Aug 14, 2007 at 04:17:17PM +0530, CyberOrg wrote:
If it is enforced, any way to continue using the script like this?
for i in a b c do cd $i osc ci cd .. done
I sometime make all the changes in many packages and run the script.
Yes, that would be possible using "osc -m ''". As with svn. BTW, "osc ci -m '' <dir>" would also work. Even "osc ci -m '' <dir1> <dir2> ..." should. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, 14 Aug 2007, Dr. Peter Poeml wrote:
Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.
The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.
Or if the current behaviour should remain.
I would vote for enforcement, but there are some other things related to this: a) The webinterface commits currently have no commit message: adding new files, deleting files, editing files b) Commit messages are only useful, when the RPM changelog can be built with the help of these messages somehow automatically. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Aug 14, 2007 at 12:48:53PM +0200, Dirk Stoecker wrote:
On Tue, 14 Aug 2007, Dr. Peter Poeml wrote:
Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.
The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.
Or if the current behaviour should remain.
I would vote for enforcement, but there are some other things related to this:
a) The webinterface commits currently have no commit message: adding new files, deleting files, editing files
Indeed.
b) Commit messages are only useful, when the RPM changelog can be built with the help of these messages somehow automatically.
I think they should kept separate (or at least this behaviour should be made optional). I regard the commit log as something which may not be what I want to end up into the rpm changelog. I may need many iterations until I get a package to build on all targets, and I would clutter the rpm changelog with those changes. Just like the rpm changelog is usually not the same as the changelog of any upstream source code repository. For example, IMO it makes sense to the Apache webserver package that there are really three changelogs: - the upstream svn changelog (also packaged as CHANGES in the packages) - the buildservice commit log (making transparent the work of the packager) - the rpm changelog (documenting user-visible end results) Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, 14 Aug 2007, Dr. Peter Poeml wrote:
b) Commit messages are only useful, when the RPM changelog can be built with the help of these messages somehow automatically.
I think they should kept separate (or at least this behaviour should be made optional).
I regard the commit log as something which may not be what I want to end up into the rpm changelog. I may need many iterations until I get a package to build on all targets, and I would clutter the rpm changelog with those changes.
Just like the rpm changelog is usually not the same as the changelog of any upstream source code repository.
For example, IMO it makes sense to the Apache webserver package that there are really three changelogs: - the upstream svn changelog (also packaged as CHANGES in the packages) - the buildservice commit log (making transparent the work of the packager) - the rpm changelog (documenting user-visible end results)
Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.
You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs. Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog? Would be very helpful I think. And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec. Regarding the webpage: The Add-file and edit-file pages could get a box for commit messages as well as checkmarks for the Tags I introduced here :-) Leaving only deletes without message. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi Peter,
Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.
You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs.
Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog?
Would be very helpful I think.
And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec.
Regarding the webpage:
The Add-file and edit-file pages could get a box for commit messages as well as checkmarks for the Tags I introduced here :-) Leaving only deletes without message.
Did you think about this suggestion? Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Aug 16, 2007 at 03:45:32PM +0200, Dirk Stoecker wrote:
Hi Peter,
Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.
You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs.
Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog?
Would be very helpful I think.
And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec.
Regarding the webpage:
The Add-file and edit-file pages could get a box for commit messages as well as checkmarks for the Tags I introduced here :-) Leaving only deletes without message.
Did you think about this suggestion?
Think, yes, come to a conclusion, no, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Thu, 16 Aug 2007, Dr. Peter Poeml wrote:
Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.
You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs.
Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog?
Would be very helpful I think.
And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec.
Regarding the webpage:
The Add-file and edit-file pages could get a box for commit messages as well as checkmarks for the Tags I introduced here :-) Leaving only deletes without message.
Did you think about this suggestion?
Think, yes, come to a conclusion, no,
Then you should at least send me a "Hmm", or you risk letter like above. On mailinglist sometimes mails are overlooked and I always ask back. Not come to a conclusion? What are your Pros and Contras? Maybe I can help to find a conclusion. I'm always full of good ideas, but very often have not the time to let them come true (switching my job to non-IT could increase my hobby-IT productivity I think :-). Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Fri, Aug 17, 2007 at 08:58:20AM +0200, Dirk Stoecker wrote:
Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.
You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs.
Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog?
No, I don't think that this is a good idea. An overkill mechanism IMO, and it'd only make sense if you work exactly in the way and order you assume here...
Would be very helpful I think.
And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec.
Doesn't make sense to me. The basic idea does, but that should rather be an optional query argument sent to the api IMO, not a "magic" part of the changelog. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Mon, 20 Aug 2007, Dr. Peter Poeml wrote:
On Fri, Aug 17, 2007 at 08:58:20AM +0200, Dirk Stoecker wrote:
Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.
You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs.
Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog?
No, I don't think that this is a good idea. An overkill mechanism IMO, and it'd only make sense if you work exactly in the way and order you assume here...
Anyway a way to unify the change logs is certainly required.
Would be very helpful I think.
And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec.
Doesn't make sense to me. The basic idea does, but that should rather be an optional query argument sent to the api IMO, not a "magic" part of the changelog.
I agree. When do you implement it? :) Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Dr. Peter Poeml schrieb:
[...]
Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.
The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.
Yes, it should be enforced, else it is too easy to enter no commit message which is always bad. Another question how such a message would be related to some changelog inside of the package. Maybe it is possible to have another option (Say -M) that tells osc to reuse some information from there.
Or if the current behaviour should remain.
Cheers Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Aug 14, 2007 at 12:55:30PM +0200, Herbert Graeber wrote:
Dr. Peter Poeml schrieb:
[...]
Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.
The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.
Yes, it should be enforced, else it is too easy to enter no commit message which is always bad.
Another question how such a message would be related to some changelog inside of the package. Maybe it is possible to have another option (Say -M) that tells osc to reuse some information from there.
osc would not be the place to implement this, as far as I can see. It would rather be the build service backend which could be configured to (principally) reuse the information from the commit log when adding to the rpm changelog. Or, it is also conceivable that osc takes the string which is specified via -m, and inserts it at the top of the .changes file and commits that. Or vice versa -- it could use the top entry of .changes as commit message. Personally, I think the latter makes most sense. What do others think? I may be a little Novell centric here. I'm not sure how widespread usage of a .changes file is, though. We might want to establish that, first... it is pretty much standard inside Novell, because the internal build system enforces this. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Aug 14, 2007, at 12:40 PM, Dr. Peter Poeml wrote:
On Tue, Aug 14, 2007 at 10:37:41AM +0200, Dr. Peter Poeml wrote:
On Mon, Aug 13, 2007 at 03:26:42PM +0200, Andrew Beekhof wrote:
I recently implemented a different commit method in osc, when I added the -m/-F option: Did anyone test this?
works great here
Cool, thanks!
I'll make it the default later today.
I would like to hear your opinion about something.
Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.
The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.
I believe this is the correct approach. Project membership is rarely static and as such we really should be telling those that came after us about the changes we're making. And for personal projects, its a good habit to get into anyway :-) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Aug 14, 2007, at 10:37 AM, Dr. Peter Poeml wrote:
On Mon, Aug 13, 2007 at 03:26:42PM +0200, Andrew Beekhof wrote:
I recently implemented a different commit method in osc, when I added the -m/-F option: Did anyone test this?
works great here
Cool, thanks!
I'll make it the default later today.
one question... how will updates made via the web interface be handled?
Not sure what you mean with "updates made via the web interface", could you explain please? Do you mean, with regard to committing / commit message?
right. one can obviously edit files (and commit them) via the web interface too. presumably populating the author for such commits would be easy, but it might be nice if there was a text-box for a commit message too. just wondered if you'd given any thought to the matter. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Aug 14, 2007 at 12:55:27PM +0200, Andrew Beekhof wrote:
one question... how will updates made via the web interface be handled?
Not sure what you mean with "updates made via the web interface", could you explain please? Do you mean, with regard to committing / commit message?
right.
one can obviously edit files (and commit them) via the web interface too. presumably populating the author for such commits would be easy, but it might be nice if there was a text-box for a commit message too.
just wondered if you'd given any thought to the matter.
That absolutely makes sense. Also, it would be very nice to be able to view the commit log in the web interface, and display the latest entries in the commit log when viewing a package. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
participants (8)
-
Adrian Schröter -
Andrew Beekhof -
Bernhard Walle -
CyberOrg -
Dirk Stoecker -
Dr. Peter Poeml -
Herbert Graeber -
Marcus Hüwe