From: Pedro Lopez-C. <ped...@gm...> - 2006-06-27 21:28:58
|
Hi, There are several new features in trunk, started but unfinished: guitar chord editor, lilypond directives, multitrack MIDI recording, a new track parameters box, redesign of the IPB area... And now, seems that the proposal to assign the Instruments to segments instead of tracks has been accepted with some interest. This last one is likely to require a big rewrite, which in turn may require a long delay until the next featured release. On the other hand, there are also several new interesting features in trunk: a new Finnish translation, support for Lilypond 2.8 and several other Lilypond enhancements and bug fixes, a few new dialogs... There is also a bugfix branch, with very little fixes but some users using it. I would like to know if somebody has a feature plan in mind for the next release, and also timings. If we delay the next release one year away or more, as it is customary here, I would like to propose to release soon the bugfix brach 1.2.4, during the few next months or so. What do you think? Regards, Pedro |
From: D. M. 'S. M. <ros...@gm...> - 2006-06-27 21:48:27
|
On Tuesday 27 June 2006 5:28 pm, Pedro Lopez-Cabanillas wrote: > There are several new features in trunk, started but unfinished > lilypond directives This isn't polished, but it isn't exactly "unfinished" either. It needs minor tweaking, and new capabilities added, but I don't think it's so far off that it should necessarily have to wait until February to see general use. I'm thinking weeks, not months, and I firmly believe that is not wishful thinking. > I would like to know if somebody has a feature plan in mind for the next > release, and also timings. If we delay the next release one year away or > more, as it is customary here, I would like to propose to release soon the > bugfix brach 1.2.4, during the few next months or so. What do you think? I think Chris would say 1.2.4 should be strictly for bugs fixed since 1.2.3, with no new features, and any of these new features we release should be in 1.3.x. People don't build from SVN as a rule. I wonder if we could start some kind of stable/experimental release model like so many other projects do, and actually get people to package both versions in parallel, and thus get more exposure for the SVN snapshot release to get real pre-release testing before the next stable version comes out. I think that might be the best thing. Get strictly bug fixes into 1.2.4, and get it out. Then get a 1.3 experimental release out in parallel, to eventually become stable 1.4, or something like that. I don't know exactly at this moment. I'm still trying to get the mud out from under my fingernails. It seems like a good idea off the top of my head, but our user community might be too small to support this scheme. -- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: D. M. 'S. M. <ros...@gm...> - 2006-06-28 04:32:53
|
On Tuesday 27 June 2006 5:28 pm, Pedro Lopez-Cabanillas wrote: > There are several new features in trunk, started but unfinished: guitar I just got different barline types and glissandi done. After figuring out a way to remove 20,000 gallons of water from my crawlspace and digging trenches in the mud in pouring drenching rain to boot. This should be ready for our next release, I think. Anything that isn't working by then can just be //'ed out. -- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Vladimir S. <vla...@vl...> - 2006-06-28 17:22:35
|
On Wednesday 28 June 2006 04:32, D. Michael 'Silvan' McIntyre wrote: > On Tuesday 27 June 2006 5:28 pm, Pedro Lopez-Cabanillas wrote: > > There are several new features in trunk, started but unfinished: guitar > > I just got different barline types and glissandi done. Why don't we actually make everything prints with lilypond by default? :) It looks nicer, every distribution has it included (I think so), related bugs are fixed in SVN and having lilypond directives sounds great to me (Haven't tried them yet). I don't know how hard would it be to synchronize notation editor page layout with lilypond output, but... Chris had mentioned notation editor improvements four times in 2005-2006 period. Which is 2 times more then in 1653-2004. Rg will soon be almost typesetting ready! Vlada |
From: D. M. 'S. M. <ros...@gm...> - 2006-06-28 04:36:34
Attachments:
hackery.png
|
-- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Pedro Lopez-C. <ped...@gm...> - 2006-06-28 05:57:46
|
On Tuesday, 27 June 2006 23:48, D. Michael 'Silvan' McIntyre wrote: > On Tuesday 27 June 2006 5:28 pm, Pedro Lopez-Cabanillas wrote: > > lilypond directives > I don't think it's so far off that it should necessarily have to wait until > February OK. couldn't I explain myself? Let me reword the paragraph. I'm not pushing for a new featured release just now, because there are some new features started, that still need a bit of work to become ready for general use. Perhaps one month or two (talking for myself). But if I start the big rewrite of tracks/segments/instruments, this may require many months. Do you want to wait until next year for the next release? > > If we delay the next release one year away or > > more, as it is customary here, I would like to propose to release soon > > the bugfix brach 1.2.4, during the few next months or so. > > I think Chris would say 1.2.4 should be strictly for bugs fixed since > 1.2.3, with no new features And that was my proposal, too. If we delay the next release a long time, because the new featuires require a lot of time for cooking, at least let the users to have a bugfix release, with no new features but less bugs than the 1.2.3 release. > Get strictly bug fixes into 1.2.4, and get it out. SVN branch: stable_1_2_4 Summary of bugfixes already available in this bugfix branch: 7320 bug #1466837 Debian bug# 374716: Segfault when /dev/snd/seq is unavailable. Based on a patch by Mike O'Connor. 7254 bug #1480689 i18n issues reported by Erik Magnus Johansson 7256 Swedish translation update, by Erik Magnus Johansson 7253 bug #1479000 Stuck notes in matrix after pressing a stop button 7218 Patch to fix the "scons --help" bug, from Emmanuel Saracco. (Partially committed on Nov 20 2005, except this file) 7215 bug #1471910 Sequencer status lying: "no driver" 7210 Remove a temporary assert which makes MappedPluginSlot destructor to fail. 7205 Build-system fixes ported from trunk > Then get a 1.3 > experimental release out in parallel, to eventually become stable 1.4, or > something like that. SVN branch: trunk It has the bugfixes and all the new features. Regards, Pedro |
From: D. M. 'S. M. <ros...@gm...> - 2006-06-28 06:42:15
|
On Wednesday 28 June 2006 1:57 am, Pedro Lopez-Cabanillas wrote: > OK. couldn't I explain myself? Let me reword the paragraph. No, I'm just tired. > But if I start the big rewrite of tracks/segments/instruments, this may > require many months. Do you want to wait until next year for the next > release? No, not again. Never! Do it in a branch, I say. > And that was my proposal, too. If we delay the next release a long time, > because the new featuires require a lot of time for cooking, at least let > the users to have a bugfix release, with no new features but less bugs than > the 1.2.3 release. I didn't read it that way. You did say: "On the other hand, there are also several NEW INTERESTING FEATURES in trunk:" (emphasis is mine) So I thought you were after putting new features into the 1.2.4 release, instead of purely bug fixes. It was an honest mistake. Not my fault you don't el talko el English-o. Next thing you're going to try to tell me English isn't your first language. I know that's crap. Everybody in the world is born speaking English. I saw that on TV, so it must be true. </gringo> :D > > Then get a 1.3 > > experimental release out in parallel, to eventually become stable 1.4, or > > something like that. > > SVN branch: trunk > It has the bugfixes and all the new features. Yeahbut what I was getting at was an official tarball release of the "experimental" branch in the form of a periodic trunk snapshot. Only a tiny number of people ever check out SVN. Most people use packages. So if we could encourage experimental packages in the likes of Debian Sid or whatever other distro call the evil unstable pre-alpha release version that all the crazy bleeding edge people use, that would be totally copacetic. (Los mucho el cool-o. Not culo. Get your mind out of the gutter.) What I'm trying to get after is more people testing experimental things before we release with gobs of bugs that don't get found until after, and don't get officially (in a stable release) corrected for untold months. -- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Vince N. <vin...@gm...> - 2006-06-28 09:16:36
|
> Yeahbut what I was getting at was an official tarball release of > the "experimental" branch in the form of a periodic trunk snapshot. Only a > tiny number of people ever check out SVN. Also, the svn trunk will swing between "unstable but worth tinkering with" and "segfaults when you breathe on it", which is how it's meant to be but not helpful for someone who wants to help with testing. There would seem to be room for a "semi-stable" snapshot release, put out when the SVN trunk is stable enough to be usable by a keen tester - updated approximately (not metronomically) once or twice a month. |
From: D. M. 'S. M. <ros...@gm...> - 2006-06-28 16:05:08
|
On Wednesday 28 June 2006 5:16 am, Vince Negri wrote: > > Yeahbut what I was getting at was an official tarball release of > > the "experimental" branch in the form of a periodic trunk snapshot. Only > > a tiny number of people ever check out SVN. > > Also, the svn trunk will swing between "unstable but worth tinkering > with" and "segfaults when you breathe on it", which is how it's meant > to be but not helpful for someone who wants to help with testing. > > There would seem to be room for a "semi-stable" snapshot release, put > out when the SVN trunk is stable enough to be usable by a keen tester > - updated approximately (not metronomically) once or twice a month. I do definitely agree with the spirit of this. I don't have a firm inclination in this direction only because it seems like it might just be too much to hope for, finding time to make the releases. Also, who would use it? The real question is whether enough people would use it to make it worth the bother. I see WIP packages coming across in Sid all the time, so theoretically Debian could pick it up for Sid or Experimental, and other distros could follow suit, but how many potential Rosegarden users are actually running these bleeding edge distros anyway? I have no idea. -- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Chris C. <ca...@al...> - 2006-06-28 09:47:07
|
On Wednesday 28 Jun 2006 06:57, Pedro Lopez-Cabanillas wrote: > And that was my proposal, too. If we delay the next release a long time, > because the new featuires require a lot of time for cooking, at least let > the users to have a bugfix release, with no new features but less bugs than > the 1.2.3 release. My suggestion back when 1.2.3 came out was to do a 1.2.4 stable release shortly afterwards if necessary, and then to do 1.3 in "late spring" with certain selected new features, and do 1.4 or whatever late in the year with notation restructuring and so on. We're still basically looking at those releases, but reconsidering the question of which ones to do and when. For reference this is what I imagine the three releases as containing: 1.2.4: * Bug fixes against 1.2.3 1.3: * Multi-track MIDI recording (but not revised segment instrument scheme) * Ramped tempo and new tempo ruler (with editing (editing not done yet)) * Range cut and paste * Lilypond annotations * Fixes * Anything else? 1.4: * Staff and voice related notation work (me) * Fretboard and tablature (various) * New instrument/segment structure (Pedro) * Matrix canvas rewrite (Guillaume) Three options: [A] Release 1.2.4 ASAP. Continue working in trunk towards 1.4 in a year or so. Skip 1.3 entirely. I think this sounds like what Pedro's suggesting. [B] Tidy up the features that are in trunk already, fix a few more things and put out 1.3 in "a couple of months". Then continue hacking towards 1.4 next year. [C] All of the above, i.e. 1.2.4 ASAP, 1.3 "soon", 1.4 "later". This is basically the original plan plus slippage. I think I probably vote for B. I vote against A because I really want to see some of the features currently in trunk released, and I don't want to wait until the 1.4 timeframe for that. I vote against C because it takes work to get a release out and I'm not sure we have enough fixes in 1.2.4 to justify it if 1.3 can be fairly close, which it probably can. There's also the option of a separate unstable series -- in the above I'm basically thinking of 1.3 as a stable release if possible (i.e. as a potential branch point for a 1.3.1 with bugfixes, rather than as the first in a new 1.3.x unstable series with more new features). I don't really have a view on that at the moment -- if someone wants to suggest dates and contents for such releases, that might make it easier to think about. Chris |
From: Chris C. <ca...@al...> - 2006-06-28 09:58:16
|
On Wednesday 28 Jun 2006 10:48, Chris Cannam wrote: > There's also the option of a separate unstable series And also of branch releases, for example with features that might not be mainstream (such as the Glasgow pitch tracker -- which reminds me, I haven't replied to an email from Dougie that I meant to reply to -- I wonder if I have it on this machine?), or to get advance testing for features that could do with exposure before the release as a whole is ready (e.g. a guitar-features test release prior to 1.4). Chris |
From: Martin S. <mc...@as...> - 2006-06-28 10:07:07
|
On Wed, 28 Jun 2006, Pedro Lopez-Cabanillas wrote: > I'm not pushing for a new featured release just now, because there are some > new features started, that still need a bit of work to become ready for > general use. Perhaps one month or two (talking for myself). Regarding the parameter area update, I suspect that I'm not going to get much more done before I head off to Chile on Saturday, and it seems unlikely that I will have much time for the 3 weeks that I'm there. Thus, a month is probably about the soonest that I can get this completed. So far, what I have done is the following: 1. I have written a RosegardenParameterArea widget, which is what now occupies the left-most doc area. This inherits from a QWidgetStack, and each of the container widgets that implements a particular layout arrangement for the parameter boxes, is contained in this stack. RosegardenParameterBox widgets are added to this widget with a call to the addRosegardenParameterBox() method. This adds these widgets both to a vector, and to the container that implements the currently selected parameter box arrangment. When the setArrangement() method is called, to select a different parameter-box arrangement, the RosegardenParameterArea widget goes through its vector of parameter-box widgets, removes them from the currently active container widget, and reparents them and adds them to the newly specified container. It then tells the QWidgetStack to switch to displaying the new container, with its new contents. Currently there are only two arrangement styles supported; these being classic and tabbed. 2. I have also added a combo box to the General Configuration/Presentation page of the Configure Rosegarden dialog. This allows one to select between the two arrangement styles, and is linked to both a KConfig token, and to a short chain of signals that invoke the setArrangement() method of the RosegardenParameterArea widget. I have verified that this correctly switches the arrangement of the parameter box area, when the OK or Apply buttons of the configuration dialog are pressed, and that it gets saved to the rosegardenrc file by "Save settings", and that it is correctly restored and instantiated when the program next starts. This appears to work, but there are some rough edges, and at the moment, it doesn't address the problem of the parameter boxes being wider than they need to be, when displayed in tabbed mode. Thus, the most important thing that remains to be done, is to modify the individual parameter boxes to support the proposed landscape and portrait layout modes. The landscape mode would be what we currently have, whereas the portrait mode, which would be automatically selected by the tabbed arrangement style (since this has more vertical space available), would rearrange the internal widgets of each parameter box, to make the box as narrow as possible. I believe that I know roughly how to implement this, and I have mocked up an example layout, but I haven't had time to start implementing this yet. I also need to restore labeled outlines around the parameter boxes, in classic mode (but not in tabbed mode). Again, this should be pretty straightforward, once I find time. Also, whereas I currently record the arrangement style via KConfig, using an integer that matches the position of the configuration entry in the configuration combo-box, I would like to change this to a more intuitive string configuration token, like "tabbed" and "classic", and create a small table for associating these names with their enumerated equivalents, and their combo-box descriptions. Thereafer, the combo-box entries could be moved around, without breaking anything. Finally, I need to experiment with the idea of putting the RosegardenParameterArea widget within a ScrollView (with scroll bars turned off), to see if it looks okay as a side-bar that can optionally be partly obscured. Martin |
From: Chris C. <ca...@al...> - 2006-06-28 10:13:26
|
On Wednesday 28 Jun 2006 11:07, Martin Shepherd wrote: > Regarding the parameter area update, I suspect that I'm not going to > get much more done before I head off to Chile on Saturday, and it > seems unlikely that I will have much time for the 3 weeks that I'm > there. Thus, a month is probably about the soonest that I can get this > completed. Certainly sounds good so far. Any chance of a patch of what you've got to date, against the SVN trunk? Would you be happy or annoyed if someone else went and finished off the bits you described, while you were away? It's probably not going to happen, but you never know. Your email looks like a pretty thorough description of what needs to be done, apart from the details of how to make a portrait layout. Chris |
From: Martin S. <mc...@as...> - 2006-06-28 11:00:24
|
On Wed, 28 Jun 2006, Chris Cannam wrote: > On Wednesday 28 Jun 2006 11:07, Martin Shepherd wrote: >> Regarding the parameter area update, I suspect that I'm not going to >> get much more done before I head off to Chile on Saturday, and it >> seems unlikely that I will have much time for the 3 weeks that I'm >> there. Thus, a month is probably about the soonest that I can get this >> completed. > > Certainly sounds good so far. Any chance of a patch of what you've got to > date, against the SVN trunk? Sure. I'll try and get this out in the next couple of days. I haven't updated my copy of the trunk for a while. So I need to do that and merge in my stuff before sending a patch. The new files are called: gui/rosegardenparameterarea.cpp gui/rosegardenparameterarea.h and the existing files that I had to modify, were the following: gui/SConscript gui/rosegardenconfiguredialog.h gui/rosegardenconfiguredialog.cpp gui/rosegardenconfigurationpage.cpp gui/rosegardengui.cpp gui/rosegardengui.h gui/segmentparameterbox.cpp gui/instrumentparameterbox.cpp gui/widgets.cpp gui/widgets.h I imagine that at least one of these files has been modified since I started fiddling, and I want to do the checking for conflicts when I'm a bit more awake than I am right now (ie. at 4am). > Would you be happy or annoyed if someone else went and finished off the bits > you described, while you were away? I wouldn't mind at all. Right now, I consider this patch to be a good beginning introduction to working with KDE, Rosegarden and C++, although my original reason for working on it, was that it seemed more likely that my patch for adding more controller rotaries would be accepted, if I found a way (ie. the tabbed layout) to add vertical space to the IPB :-). If somebody else finishes this patch, and there is room for the added rotaries, then I will be just as happy as if I did it myself. Note that I haven't tried to shoehorn in extra error handling, or anything like that, and apart from including more comments, I've been doing my best to follow the lead of other code in Rosegarden. So I hope that what I have written can be worked on by anybody who is used to working with Rosegarden. > It's probably not going to happen, but > you never know. Your email looks like a pretty thorough description of what > needs to be done, apart from the details of how to make a portrait layout. Right now I need to get some sleep. But I'll see if I can flesh out the descriptions a bit, within the next day or two. Martin |
From: D. M. 'S. M. <ros...@gm...> - 2006-06-28 16:01:53
|
On Wednesday 28 June 2006 5:48 am, Chris Cannam wrote: > I think I probably vote for B. I'll second that. It just doesn't seem there's enough bug fixing to take time for a 1.2.4, and 1.3.x is "pretty close." I think we ought to set a firm deadline, and keep it. I'd like to pick August 14th, but six weeks seems too close. Especially with August being hell month for both my wife and myself. Heavy workload, hot as a furnace; short tempers and bad moods all around this house in that wretched month that's coming up all too soon. August is evil. So how about September 15th to get 1.3.x out the door and gone? > in a new 1.3.x unstable series with more new features). I don't really > have a view on that at the moment -- if someone wants to suggest dates and > contents for such releases, that might make it easier to think about. I don't have a strong desire to move in that direction. I just want to get more people involved sooner with testing. We could accomplish that with more frequent "stable" releases too. Especially with a follow-on bugfix like we didn't get around to last time. Meanwhile everyone I can think of asking lately has been using 1.0. -- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Chris C. <ca...@al...> - 2006-07-03 18:59:15
|
On Wednesday 28 Jun 2006 17:01, D. Michael 'Silvan' McIntyre wrote: > So how about September 15th to get 1.3.x out the door and gone? OK, you're on. Chris |
From: Marcos G. <mar...@gm...> - 2006-07-04 06:29:37
|
El Mi=E9rcoles, 28 de Junio de 2006 18:01, D. Michael 'Silvan' McIntyre=20 escribi=F3: > Meanwhile everyone I can think of asking lately has been using 1.0. Musix has Rosegarden 1.2.3 since a few months ago, now Debian has it too: i= t=20 works very good but I didn't had time/intention to make music in the last=20 times.... but, the last song I recorded, I made it with 1.2.3 and it was=20 really comfortable and easy to use, also I feel more comfortable recording= =20 audio into Rosegarden 1.2.3 than into 1.0, maybe because the zoom works=20 better... (hey, we need a vertical zoom now!! :-D) i dont know... but I jus= t=20 want to say that the proyect is fantastic and many people is using it. =2D-=20 Marcos Guglielmetti =20 * Director del desarrollo de Musix GNU+Linux, 100% Software Libre * Descarga el CD de Musix: (www.musix.org.ar) (www.pc-musica.com.ar/musix) * Videos, programas y otras cosas en: ftp://musix.ourproject.org/pub/musix/ * Reporte de errores a:=20 https://www.musix.org.ar/wiki/index.php?title=3DProblemas-Bugs *IRC: #musix channel on freenode |
From: Pedro Lopez-C. <ped...@gm...> - 2006-06-28 19:35:23
|
On Wednesday, 28 June 2006 11:48, Chris Cannam wrote: > Three options: > > [A] Release 1.2.4 ASAP. Continue working in trunk towards 1.4 in a year > or so. Skip 1.3 entirely. I think this sounds like what Pedro's > suggesting. > > [B] Tidy up the features that are in trunk already, fix a few more things > and put out 1.3 in "a couple of months". Then continue hacking towards 1.4 > next year. > > [C] All of the above, i.e. 1.2.4 ASAP, 1.3 "soon", 1.4 "later". This is > basically the original plan plus slippage. > > I think I probably vote for B. I vote against A because I really want to > see some of the features currently in trunk released, and I don't want to > wait until the 1.4 timeframe for that. I vote against C because it takes > work to get a release out and I'm not sure we have enough fixes in 1.2.4 to > justify it if 1.3 can be fairly close, which it probably can. I would prefer C, or at least to release 1.2.4 very soon. First, because the 1.2.3 release has some really serious bugs. Regarding the build system, there were a few ones (see [1]) hitting packagers, distros and developers. I also would like to see a new Rosegarden release in the forthcoming Mandriva 2007 release, which may be released soon. Also the Jack synchronization bug (#1479000) was pretty serious too. The last one, about /dev/snd/seq is also worth, because it affected every Ubuntu user and others. There are 43 bug reports closed since the 1.2.3 release, if I've counted correctly. I've not committed every bugfix to both branches, only the few ones I've posted already, and nobody else has done a single commit to the stable_1_2_4 branch since the Subversion migration. For instance, there are several LilyPond bugs fixed by Heikki Junes, which are only on trunk at this moment. I've also invested some time in maintenance tasks on this branch, as you can remember (there was needed a directory reorganization, fix properties and recover PNG files and other resources damaged after the migration). I thought it was worth to spend the effort. I would be disappointed if we throw it away. [1] Some bug reports about the build system http://www.mail-archive.com/ros...@li.../msg08307.html http://www.mail-archive.com/ros...@li.../msg08415.html http://www.mail-archive.com/ros...@li.../msg08441.html Regards, Pedro |
From: Chris C. <ca...@al...> - 2006-07-03 18:50:10
|
On Wednesday 28 Jun 2006 20:35, Pedro Lopez-Cabanillas wrote: > On Wednesday, 28 June 2006 11:48, Chris Cannam wrote: > > Three options: > > [...] > > [C] All of the above, i.e. 1.2.4 ASAP, 1.3 "soon", 1.4 "later". > > This is basically the original plan plus slippage. > > > > I think I probably vote for B. [...] > > I would prefer C, or at least to release 1.2.4 very soon. > > First, because the 1.2.3 release has some really serious bugs. The most serious reported bug in 1.2.3 (a crash when starting to record) is still unfixed. Moderately serious bugs that have been fixed include the segfault when /dev/snd/seq is unavailable, the stuck notes in matrix, mis-sorting in marker editor, and sequencer status lying. I don't think any of those counts as critical, although I could be persuaded about /dev/snd/seq (I wish we'd realised there were still distros that failed to set up that device). As for the build system, I could see the point in releasing build system fixes one week after the prior release, but I don't see much point in concentrating on build system fixes five months later, unless we really expect not to have another release for another five months (a situation I think we should aim to avoid ending up in if at all possible). I can't believe it takes any packager five months to work around the fairly minor build system problems in 1.2.3. > I've also invested some time in maintenance tasks on this branch [...] > I thought it was worth to spend the effort. I would be disappointed if > we throw it away. Well, I've spent some time managing the branch myself (prior to the Subversion migration). But I don't think "I put lots of work in to this" has much bearing on whether to release it, it doesn't really help to be subjective in that way. I think it stands or falls on one thing: are the actual fixes in 1.2.4 (not including fixes to the build system) substantial enough to balance out the amount of time it will take out of our schedules to make a release? My gut feeling is that they aren't. (I would feel quite differently if we had a fix for that recording crash.) So I'm not keen to take the time myself. On the other hand I've absolutely no objection if someone else wants to take their time to roll up a release, and I'll happily give a quick test to any prelimary tarballs or whatever. Chris |
From: Pedro Lopez-C. <ped...@gm...> - 2006-07-03 22:50:34
|
On Monday, 3 July 2006 20:49, Chris Cannam wrote: > The most serious reported bug in 1.2.3 (a crash when starting to record) > is still unfixed. I've not seen any *repeatable* procedure, or a decent stack trace, or anything that could be used to debug this issue. I've tried some recording sessions, single and multitrack, and I couldn't reproduce it. > As for the build system, I could see the point in releasing build system > fixes one week after the prior release, but I don't see much point in > concentrating on build system fixes five months later, I don't agree. Packagers need to be in sync with their distribution schedule, not with Rosegarden's release cycle. For instance: Mandriva 2006 was released last year, and it is still the current one. They include Rosegarden 1.0; the current development repository (Cooker) includes Rosegarden 1.2.3, with all the bugs. The next release, Mandriva 2007, is scheduled for September. A 1.2.4-bugfixes released soon could be included, but not the planned 1.3 if it is released also in September. > I think it stands or falls on one thing: are the actual fixes in 1.2.4 > (not including fixes to the build system) substantial enough to balance > out the amount of time it will take out of our schedules to make a > release? My gut feeling is that they aren't. (I would feel quite > differently if we had a fix for that recording crash.) I've not committed many bug fixes to stable_1_2_4, because nobody else was interested. I've asked about the LilyPond ones, and got no support. I've been very alone, hanging on this branch. As I've said, in trunk there are many more bugs fixed, that can be identified and ported to the 1_2_4 branch. I would like to do my part of the job, but not alone. > So I'm not keen > to take the time myself. On the other hand I've absolutely no > objection if someone else wants to take their time to roll up a > release, and I'll happily give a quick test to any prelimary tarballs > or whatever. I would like to do it, if I can get some support from the patches authors, and if it is released officially. Regards, Pedro |
From: Heikki J. J. <hj...@gm...> - 2006-07-04 00:31:54
|
2006/7/4, Pedro Lopez-Cabanillas <ped...@gm...>: > On Monday, 3 July 2006 20:49, Chris Cannam wrote: > > The most serious reported bug in 1.2.3 (a crash when starting to record) > > is still unfixed. > > I've not seen any *repeatable* procedure, or a decent stack trace, or anything > that could be used to debug this issue. I've tried some recording sessions, > single and multitrack, and I couldn't reproduce it. I suggest that there would be a release policy similar to lilypond: The new version does not do worse than the previous version: - the features which worked also in earlier version work also in newer version - the bugs which existed also in earlier version may still exist in the new release - there may be some new features and/or bug fixes. This policy favours more frequent releases. Frequent releases make it easier for users to follow the development. Best regards, Heikki |
From: Marcos G. <mar...@gm...> - 2006-07-04 06:49:23
|
El Martes, 4 de Julio de 2006 00:50, Pedro Lopez-Cabanillas escribi=F3: > On Monday, 3 July 2006 20:49, Chris Cannam wrote: > > The most serious reported bug in 1.2.3 (a crash when starting to > > record) is still unfixed. > > I've not seen any *repeatable* procedure, or a decent stack trace, = or > anything that could be used to debug this issue. I've tried some > recording sessions, single and multitrack, and I couldn't reproduce > it. =20 Hey! Now I found a clue: it happens here when I open a session that was saved us= ing=20 rosegarden 1.0 and I try to record audio with Rosegarden 1.2.3 into this=20 session. If i begin a new session from rosegarden 1.2.3, rosegarden do not= =20 crash! :-D =2D-=20 Marcos Guglielmetti =20 * Director del desarrollo de Musix GNU+Linux, 100% Software Libre * Descarga el CD de Musix: (www.musix.org.ar) (www.pc-musica.com.ar/musix) * Videos, programas y otras cosas en: ftp://musix.ourproject.org/pub/musix/ * Reporte de errores a:=20 https://www.musix.org.ar/wiki/index.php?title=3DProblemas-Bugs *IRC: #musix channel on freenode |
From: Chris C. <ca...@al...> - 2006-07-04 12:06:20
|
On Monday 03 Jul 2006 23:50, Pedro Lopez-Cabanillas wrote: > On Monday, 3 July 2006 20:49, Chris Cannam wrote: > > The most serious reported bug in 1.2.3 (a crash when starting to > > record) is still unfixed. > > I've not seen any *repeatable* procedure, or a decent stack trace, or > anything that could be used to debug this issue. Nor me -- but I _have_ actually seen the crash myself, just not at the right time to be prepared to debug it. Maybe with persistence. > > As for the build system, I could see the point in releasing build > > system fixes one week after the prior release, but I don't see much > > point in concentrating on build system fixes five months later, > > I don't agree. Packagers need to be in sync with their distribution > schedule, not with Rosegarden's release cycle. For instance: Mandriva > 2006 was released last year, and it is still the current one. They > include Rosegarden 1.0; the current development repository (Cooker) > includes Rosegarden 1.2.3, with all the bugs. Well then, that supports my point. Despite the build system problems, 1.2.3 is nonetheless already in Cooker, so fixing the build system bugs makes no difference to this distribution. The point of interest is whether the non-build-related bugs are important enough. > I've not committed many bug fixes to stable_1_2_4, because nobody else > was interested. I've asked about the LilyPond ones, and got no > support. That's really down to Heikki, I think, to disentangle the actual fixes from updates that may affect compatibility. I wouldn't wish to attempt that myself. Anyway, I took a look at some of the other patches that have appeared on trunk and you're right, there are quite a few more fixes we can use. I've brought across all the ones I noticed that I felt qualified to deal with: * a further marker-editor fix * Yves Guillemot's percussion matrix fixes (with Guillaume's tidyup). This one's a reasonable amount of code, but (see email of 5th Mar) it does appear to be entirely work that I would consider bug fixes rather than features. * Guillaume's composition view fixes to ensure that the segment that appears to be on top of a stack is the one that is used for mouse operations * Martin's rotary update fix for IPB * Two small composition view fixes from me (fix hang for zero duration segment, fix audio previews for repeating audio segments) and I've brought across the new .rgd files. Let's consolidate any further fixes, do a bit of testing, and release next week. I see it's the fourth of July today -- happy America, Americans! -- and that puts me in mind to suggest the 14th (Bastille day) as a nice release date for 1.2.4. How about it? Chris |
From: D. M. 'S. M. <ros...@gm...> - 2006-07-04 15:13:28
|
> I see it's the fourth of July today -- happy America, Americans! -- and Happy England is Evil Day! :D > that puts me in mind to suggest the 14th (Bastille day) as a nice > release date for 1.2.4. How about it? Works for me. -- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |
From: Pedro Lopez-C. <ped...@gm...> - 2006-07-04 20:03:28
|
On Tuesday, 4 July 2006 14:05, you wrote: > On Monday 03 Jul 2006 23:50, Pedro Lopez-Cabanillas wrote: > > On Monday, 3 July 2006 20:49, Chris Cannam wrote: > > > I've not committed many bug fixes to stable_1_2_4, because nobody else > > was interested. I've asked about the LilyPond ones, and got no > > support. > > That's really down to Heikki, I think, to disentangle the actual fixes > from updates that may affect compatibility. I wouldn't wish to attempt > that myself. The issue started earlier, with revision 7155 committed by Michael on Feb 22 (finish converting lilypondio entirely over to Pitch, fix bugs in Pitch that were mangling E# and other hated friends). Then I've committed the revision 7194 on April 9 (bug#1466805. Lilypond >= 2.6 needs text encoded as utf8). On top of these two revisions there are the many more revisions by Hekki Junes including a mix of features and fixes. Advices would be appreciated. > Anyway, I took a look at some of the other patches that have appeared on > trunk and you're right, there are quite a few more fixes we can use. > I've brought across all the ones I noticed that I felt qualified to > deal with: > > * a further marker-editor fix > > * Yves Guillemot's percussion matrix fixes (with Guillaume's tidyup). > This one's a reasonable amount of code, but (see email of 5th Mar) it > does appear to be entirely work that I would consider bug fixes > rather than features. > > * Guillaume's composition view fixes to ensure that the segment that > appears to be on top of a stack is the one that is used for mouse > operations > > * Martin's rotary update fix for IPB > > * Two small composition view fixes from me (fix hang for zero duration > segment, fix audio previews for repeating audio segments) > > and I've brought across the new .rgd files. Let's consolidate any > further fixes, do a bit of testing, and release next week. I've committed two more fixes from trunk: * bug#920879 (incorrect MIDI Text Marker export) * bug#1485643 (crash erasing a duplicated key signature) And also: * updated Catalan translation, by Quim Perez Noguer BTW, one of the previous fixes was related to i18n issues (bug#1480689), reported by the Swedish translator Erik Magnus Johansson. I would like to ring the bell of the translation team, so they can update their translations too. Should we include the Finnish translation? It is already at trunk. > I see it's the fourth of July today -- happy America, Americans! -- and Happy Independence Day, America! > that puts me in mind to suggest the 14th (Bastille day) as a nice > release date for 1.2.4. How about it? Viva la France! Viva la Republique! I like the date, and I don't like soccer. Regards, Pedro |