Re: [ubuntu-studio-devel] Ubuntu Studio Packaging [Was: Re: continued as per request, from IRC]
On Fri, Aug 21, 2015, at 12:09 AM, Ross Gammon wrote: > Spotting potential backports is harder. Launchpad gives you a view for > each package of what versions are in which release, but we need a table > (like the Debian Multimedia one) for our packages all on one page. > > Maybe I just haven't found the right website, or worked out how to > search/filter properly? I always intended to create a script for my email sorter to spot multimedia packages in the -changes list for the current Ubuntu development release - which then could be automatically processed in multiple ways, but it would be a lot easier to have a list in a browser for sure. -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[ubuntu-studio-devel] Ubuntu Studio Packaging [Was: Re: continued as per request, from IRC]
[...] Just chiming in on the packaging side of things (a few thoughts). Existing Packages - I have done the occasional SRU, backport, sync & merge in Ubuntu. But I would like to do more of this for Ubuntu Studio. The trouble is that there is no place that I know of where you can see all of the Ubuntu Studio Packages, and what work is required on them. You can see the bugs here for our packages: https://bugs.launchpad.net/~ubuntustudio-bugs/+packagebugs But as most of the bugs are not fully triaged, potential patches from upstream that could be applied are not known about. You can see here all the packages in universe that are out of sync with Debian: https://merges.ubuntu.com/universe.html But when the list is long, it can be hard to find our packages. You can see here the state of the Debian Multimedia Team packages and look for versions that are out of sync: https://qa.debian.org/developer.php?login=pkg-multimedia-maintain...@lists.alioth.debian.org Spotting potential backports is harder. Launchpad gives you a view for each package of what versions are in which release, but we need a table (like the Debian Multimedia one) for our packages all on one page. Maybe I just haven't found the right website, or worked out how to search/filter properly? New Packages You can find wishlist bugs that have been tagged as "needs packaging" here: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging Packaging for Ubuntu or Debian -- It is possible to do the work in Ubuntu, and then when it is accepted/uploaded in Ubuntu, offer it up to Debian. This works for patches, but for complete packaging, they are likely just to do it themselves eventually anyway. For learning packaging, Ubuntu has some great documentation, but you can't beat Debian Mentors for guiding you through the process: https://mentors.debian.net/ There are a lot of wise packagers on the mailing list there ready and willing to help answer questions. But if people are interested in this, there is no reason why we couldn't learn together here, and after a few successes, offer our service to the Debian Multimedia Team. Regards, Ross signature.asc Description: OpenPGP digital signature -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[ubuntu-studio-devel] Wubi - nuke it from orbit
As I understand it, wubi has not been supported, developed or upgraded for YEARS. Moreover, wubi is known to conflict with Ubuntu 13.XX and newer. So WHY is wubi not only present in the Ubuntu ecosystem, but actually packaged with Ubuntu .iso's? For the love of kittens, puppies and all that is good, please! Delete, remove, de-install and purge wubi from Ubuntu flavors! Confused and frustrated users will thank you. C. F. Howlett -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[ubuntu-studio-devel] another audio idea
It would be nice to detect a USB audio device that shares IRQs and put up a dialog sugesting the user try another USB port. Or have -controls do something else to alert the user they have not chosen the best one. Gui for setting rtirq up. Just to fix the RTIRQ_NAME_LIST. It is rarely correct as it comes. -- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Publishing Category
On Thu, 20 Aug 2015, C. F. Howlett wrote: Are we losing the Publishing category in 16.04? In 14.04, this includes Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... All of those things are still there. Scribus may not be in the menu due to not having a desktop file anymore... we can fix that as a bug. We have added desktop files to -settings for other things before where the SW author is not willing to do so and debian will not for one reason or another. I do not think Lyx has been in the meta, but rather available through the extra installer. The installer needs to be updated and redone. Using the code from ubiquity would make sense. -- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Next project lead
On Thu, 20 Aug 2015, Jimmy Sjölund wrote: I also think it might be helpful if you/we could document what is expected from the project lead, so they know what is expected of them before they volunteer for the position. But also as I wrote before, I think some of the tasks of current project lead could be delegated to other roles. That have not really been the case lately due to the team being so small. But with any luck the team might grow again and it wouldn't be such great task for someone in the PL roles to do more or less everything. What a small team has meant is that a lot of things just don't get done. We have some workflows. I personally would like to see someone different in charge of each of those workflows. We have sort of worked this way anyway and that is perhaps why audio has had more attention than other areas. I would welcome any ideas as to where we should go from here. I am more of a tech than an artist, once someone tells me what is wanted I can put it together (sometimes). -- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] continued as per request, from IRC
On Thu, Aug 20, 2015, at 10:49 PM, Len Ovens wrote: > On Thu, 20 Aug 2015, Mike Holstein wrote: > > > 15:48 < zequence> holstein: I really urge you to put your thoughts down and > > write > > an email instead > > 15:48 < holstein> well, its fashionable to not like ubuntu.. and, thats > > something larger than ubuntustudio.. but, when folks go to #ardour, for > > example, and the major piece of advice is "whatever you > > do, > > dont use ubuntustudio", i would like to think about why > > That is not really true, "don't use Ubuntu" Yes I see that... and > probably > with good cause. It is possible to get good results with Unity, easy to > get bad results. Certainly Studio sometimes just gets lumped in with > Ubuntu. And when suggesting a distro made for Audio, generally kxstudio > or > avlinux are the two mentioned. However, I have heard UbuntuStudio > recommended sometimes as well. (especially lately as kxstudio has had > some > issues related to KDE) > > Studio has some good stuff: > - xfce > - a good set of applications > - audio and RT allready works > > On the other side: > - LTS releases with sometimes the buggiest release of some > required audio utilities. > - LTS releases mean that by the time the next one comes out > the old one is hopelessly behind. Kubuntu may have > the best way of dealing with this by trying to make > each release LTS-able. Anything based on debian, tends > to be release based. > - It is not easy to update an LTS, the policys for adding a new > version for anything besides bugs is not an easy road to > take. > > It takes a lot of work to keep an LTS current and we just haven't been > able to do that. Both kx and av add the latest versions to their repos > within days (minutes sometimes)... they can do so because they own the > repos and manage them. It's usually not that hard to do a backport. It depends on the application. If there are a lot of dependencies that also need to be backported, that can get complicated. Also, for someone who is doing some kind of multimedia production project, and not just playing with the applications might not want to update stuff. Cause, that could lead to stuff breaking, such as not being able to load your project files, or some other conflict. But, that's the point with backports. They are not security updates, and the user is able to uncheck it. However, I don't think our users are fully aware of this, and this could become a problem should we actually begin to backport packages. > > We could set up an upgrade repo ppa, but I do not know if that is what > Ubuntu is all about. Ubuntu flavours are meant to use the Ubuntu repos. > I think we could do this in those cases where a backport is not possible. Otherwise, we should always try to do backports first. And for the following stuff, I think this is stuff we should make optional and possible to adjust using -controls. I'm going to dedicate a few weeks to that, and am really motivated to make this happen once and for all, so I will come back to this when I get the chance. > Directions we could go that remain Ubuntu-ish but still make a good > distro > for audio: > > remove module-udev-detect from pulseaudio and run jackd as the only back > end. So jackdbus would start at session start and pulse would use either > jack or dummy as it's only backends. > > Create a udev utility that replaces module-udev-detect for PA with > something that adds a plugged in audio IF to jack on the fly. The user in > -controls would be asked or allowed to determine if the new device became > the jack maser device or if it was added via zita-a2j/j2a. If the > (probably USB) new device was to be master, the internal would then get > added via zita-a2j/j2a. > > These two things alone would make Studio unique in the Linux audio world > and would solve more than 50% of support requests both in ubuntuStudio > and > in other places like #Ardour. > > Make performance mode default with the option when battery operation is > detected to goto a slower speed or ondemand. (in general a slower > _constant_ speed is better for low latency) > > Note on performance mode: I have found that performance mode runs cooler > at high CPU use than ondemand. Ondemand is good for mostly idle use. > > Allow sw update stuff to be turned off while doing audio intensive stuff > (stop cron works for me). > > Any place I have mentioned starting jack should include a2jmidid, using > a2j_control seems to be more reliable for me than using a2jmidid > directly. > > Note that this whole topic is audio only and does not address other > workflows in Studio. It happens to be what I know :) Also, I have not > mentioned the tweaks we already do for audio which should remain. > > -- > Len Ovens > www.ovenwerks.net > -- > ubuntu-studio-devel mailing list
Re: [ubuntu-studio-devel] Publishing Category
On Thu, 20 Aug 2015, Jimmy Sjölund wrote: On Thu, Aug 20, 2015 at 2:24 PM, Kaj Ailomaa wrote: On Thu, Aug 20, 2015, at 02:14 PM, C. F. Howlett wrote: > Are we losing the Publishing category in 16.04? In 14.04, this includes > Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... > We have just been redesigning the category tree, so to speak. Publishing stays, but it is a subcategory to either graphics or office in the menu. And, the menu is under construction, so nothing is permanently defined yet. Our metas will be untouched for the next release, but will probably change somewhat for the release of ... Sorry, I see what Howlett means now. I just installed 15.10 and the Publishing category is not there. Photography is a sub-category to Graphic Design. After all the other changes we made to the menu, there ended up being one publishing package only. All of the others had been added to graphics as agreed by those making suggestions. I did the work of changing the menus and I am willing to make changes. But there was agreement to move these packages out of publishing to graphics. I think scribus was the only thing left. Lyx has been considered outdated... I like it but do not do enough of that kind of work to really know (Len is using Alpine to write this message). -- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] continued as per request, from IRC
On Thu, 20 Aug 2015, Mike Holstein wrote: 15:48 < zequence> holstein: I really urge you to put your thoughts down and write an email instead 15:48 < holstein> well, its fashionable to not like ubuntu.. and, thats something larger than ubuntustudio.. but, when folks go to #ardour, for example, and the major piece of advice is "whatever you do, dont use ubuntustudio", i would like to think about why That is not really true, "don't use Ubuntu" Yes I see that... and probably with good cause. It is possible to get good results with Unity, easy to get bad results. Certainly Studio sometimes just gets lumped in with Ubuntu. And when suggesting a distro made for Audio, generally kxstudio or avlinux are the two mentioned. However, I have heard UbuntuStudio recommended sometimes as well. (especially lately as kxstudio has had some issues related to KDE) Studio has some good stuff: - xfce - a good set of applications - audio and RT allready works On the other side: - LTS releases with sometimes the buggiest release of some required audio utilities. - LTS releases mean that by the time the next one comes out the old one is hopelessly behind. Kubuntu may have the best way of dealing with this by trying to make each release LTS-able. Anything based on debian, tends to be release based. - It is not easy to update an LTS, the policys for adding a new version for anything besides bugs is not an easy road to take. It takes a lot of work to keep an LTS current and we just haven't been able to do that. Both kx and av add the latest versions to their repos within days (minutes sometimes)... they can do so because they own the repos and manage them. We could set up an upgrade repo ppa, but I do not know if that is what Ubuntu is all about. Ubuntu flavours are meant to use the Ubuntu repos. Directions we could go that remain Ubuntu-ish but still make a good distro for audio: remove module-udev-detect from pulseaudio and run jackd as the only back end. So jackdbus would start at session start and pulse would use either jack or dummy as it's only backends. Create a udev utility that replaces module-udev-detect for PA with something that adds a plugged in audio IF to jack on the fly. The user in -controls would be asked or allowed to determine if the new device became the jack maser device or if it was added via zita-a2j/j2a. If the (probably USB) new device was to be master, the internal would then get added via zita-a2j/j2a. These two things alone would make Studio unique in the Linux audio world and would solve more than 50% of support requests both in ubuntuStudio and in other places like #Ardour. Make performance mode default with the option when battery operation is detected to goto a slower speed or ondemand. (in general a slower _constant_ speed is better for low latency) Note on performance mode: I have found that performance mode runs cooler at high CPU use than ondemand. Ondemand is good for mostly idle use. Allow sw update stuff to be turned off while doing audio intensive stuff (stop cron works for me). Any place I have mentioned starting jack should include a2jmidid, using a2j_control seems to be more reliable for me than using a2jmidid directly. Note that this whole topic is audio only and does not address other workflows in Studio. It happens to be what I know :) Also, I have not mentioned the tweaks we already do for audio which should remain. -- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Publishing Category
On Thu, Aug 20, 2015 at 2:24 PM, Kaj Ailomaa wrote: > On Thu, Aug 20, 2015, at 02:14 PM, C. F. Howlett wrote: > > Are we losing the Publishing category in 16.04? In 14.04, this includes > > Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... > > > > We have just been redesigning the category tree, so to speak. Publishing > stays, but it is a subcategory to either graphics or office in the menu. > And, the menu is under construction, so nothing is permanently defined > yet. > > Our metas will be untouched for the next release, but will probably > change somewhat for the release of ... > Sorry, I see what Howlett means now. I just installed 15.10 and the Publishing category is not there. Photography is a sub-category to Graphic Design. -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] continued as per request, from IRC
On Thu, Aug 20, 2015, at 09:51 PM, Mike Holstein wrote: > 15:48 < zequence> holstein: I really urge you to put your thoughts down > and > write an email instead > 15:48 < holstein> well, its fashionable to not like ubuntu.. and, thats > something larger than ubuntustudio.. but, when folks go to #ardour, for > example, and the major piece of advice is "whatever you > do, dont use ubuntustudio", i would like to think about why > 15:48 < zequence> to the mail list, that is > 15:49 < holstein> zequence: ? do you not understand that it would take > weeks to have this kind of back and forth? > 15:49 < zequence> There are a lot of things that you are missing about > how > things really are, and why they are as they are > 15:49 < zequence> It would be good for you to get those things > straightened > out > 15:49 < holstein> zequence: sure > > > ok.. so, what do i need straightened out? > I actually asked you to put your thoughts down, and that wasn't it. But, to straighten out a few things for you anyway. = Getting New Applications Into Ubuntu = Anyone can do it. And by anyone, I mean anyone. But, it is preferable to first get the package into Debian repositories, since it will be automatically synced into Ubuntu from there. Here's info on how to get a new package into Debian: https://wiki.debian.org/DebianMentorsFaq#How_do_I_add_a_new_package_to_the_archive.3F If you still want to upload it directly to Ubuntu, here's the procedure: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages So, to answer your question why some packages aren't making it into Ubuntu - no one seems interested enough to package them, or there is a problem with the package following Debian or Ubuntu policies. I really don't know which. = Who can make changes to Ubuntu packages = Anyone can make changes to Ubuntu packages. And by anyone, I mean anyone. Unless it is a bugfix, you do the change in Debian instead of Ubuntu, since it will be automatically synced into Ubuntu. If you don't have upload rights, then you'll need a sponsor. In Debian there are several packaging teams, and the team as a whole is responsible for a set of packages. The Debian Multimedia team is responsible for packaging a lot of the stuff that we distribute. So, to make changes, you either become a Debian Multimedia team member and get access to the sources directly, or you get someone there to sponsor your changes. As long as you are improving stuff and not breaking them, as well as following Debian Policy, your changes will be accepted. = Who can upload Ubuntu Studio packages specifically? = Anyone with full upload rights. This means anyone with upload rights can upload a new version of our packages at any time. Usually, that person will want to make sure it is a change that the Ubuntu Studio team wants, but there is no guarantee for that. Anyone could ask for a change to be uploaded and if the uploader agrees, the change is in. I have upload rights only to our own packages, but this means I can upload changes at any time to the development release. After feature freeze, an archive admin will need to accept the upload before it gets through. -- any more questions? -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[ubuntu-studio-devel] continued as per request, from IRC
15:48 < zequence> holstein: I really urge you to put your thoughts down and write an email instead 15:48 < holstein> well, its fashionable to not like ubuntu.. and, thats something larger than ubuntustudio.. but, when folks go to #ardour, for example, and the major piece of advice is "whatever you do, dont use ubuntustudio", i would like to think about why 15:48 < zequence> to the mail list, that is 15:49 < holstein> zequence: ? do you not understand that it would take weeks to have this kind of back and forth? 15:49 < zequence> There are a lot of things that you are missing about how things really are, and why they are as they are 15:49 < zequence> It would be good for you to get those things straightened out 15:49 < holstein> zequence: sure ok.. so, what do i need straightened out? -- MH -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Next project lead
On Thu, Aug 20, 2015, at 12:30 PM, Jimmy Sjölund wrote: > Some thougths inline below. > > WHO VOTES? > > > > Who should be allowed to vote? > > > I think as Xubuntu does, only team members should be allowed to vote. > Though, it's a bit unclear what constitutes the Ubuntu Studio team. :) > How about https://launchpad.net/~ubuntustudio-contributors? I can make sure everyone who is a part of any other developer team is also a member there. > > > > > HOW DO WE VOTE? > > > > If we do an anonymous vote, we need to use some sort of a service. Which > > is easiest/best? > > > > I think the voting should be open, my suggestion is on IRC. No anonymous > votes. However, that is just my opinion. > I have nothing against it being open, but in that case I would prefer this list, since it can be difficult to have everyone available at a specific time. > On Thu, Aug 20, 2015 at 11:18 AM, Kaj Ailomaa > wrote: > > > > > REQUIREMENTS TO BE CANDIDATE > > > > What should be required of a candidate? > > > > I think everyone would agree on that the candidate needs to at least: > > * be active and available > > * know something about Ubuntu Studio development > > > > I also felt that the candidate should know: > > * Debian packaging (and Debian Policy) > > > > Beyond that, I think it would be nice if the candidate also was required > > to prepare a set of goals that he/she has for the next two years, so > > that we know what we are voting for. > > > > > Some thoughts about the next coming two years would be good to have, and > how the lead is going to "run the business". Otherwise it is kind of > voting > in the dark unless you know the person beforehand. > Then, let's decide that a candidate must create a wiki page using a template that we figure out. It's a common procedure when applying for stuff in the Ubuntu community. > > > > > HOW OFTEN DO WE VOTE FOR A NEW PROJECT LEAD? > > > > I would like to suggest every two years. > > > > Agreed. > > I also think it might be helpful if you/we could document what is > expected > from the project lead, so they know what is expected of them before they > volunteer for the position. But also as I wrote before, I think some of > the > tasks of current project lead could be delegated to other roles. That > have > not really been the case lately due to the team being so small. But with > any luck the team might grow again and it wouldn't be such great task for > someone in the PL roles to do more or less everything. > I will do my best to document that during the coming weeks. -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Publishing Category
On Thu, 20 Aug 2015, C. F. Howlett wrote: Are we losing the Publishing category in 16.04? In 14.04, this includes Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... We still have the meta and the applications. However, it became apparent that the term publishing is not clear. In fact a number of people thought it applied to things like applications to print a CD/DVD rather than generating written works. Also, we are looking at trying to use "proper Catagoization" so the menu just works when adding new SW. The input from someone who uses these tools on a regular basis would be wonderful. -- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Publishing Category
On Thu, Aug 20, 2015, at 03:12 PM, Len Ovens wrote: > On Thu, 20 Aug 2015, Kaj Ailomaa wrote: > > > On Thu, Aug 20, 2015, at 02:14 PM, C. F. Howlett wrote: > >> Are we losing the Publishing category in 16.04? In 14.04, this includes > >> Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... > >> > > > > We have just been redesigning the category tree, so to speak. Publishing > > stays, but it is a subcategory to either graphics or office in the menu. > > And, the menu is under construction, so nothing is permanently defined > > yet. > > > > Our metas will be untouched for the next release, but will probably > > change somewhat for the release of trusty. > The next LTS 16.04 "X". Right :D -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Publishing Category
On Thu, 20 Aug 2015, Kaj Ailomaa wrote: On Thu, Aug 20, 2015, at 02:14 PM, C. F. Howlett wrote: Are we losing the Publishing category in 16.04? In 14.04, this includes Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... We have just been redesigning the category tree, so to speak. Publishing stays, but it is a subcategory to either graphics or office in the menu. And, the menu is under construction, so nothing is permanently defined yet. Our metas will be untouched for the next release, but will probably change somewhat for the release of trusty. The next LTS 16.04 "X". -- Len Ovens www.ovenwerks.net -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Next project lead
> > > If someone skilled at Debian packaging will commit to the project for > the two years, then the lead doesn't have to be an expert at that. But, > it is still a lot easier, if the lead knows how this works. > > +1 -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Publishing Category
On Thu, Aug 20, 2015, at 02:14 PM, C. F. Howlett wrote: > Are we losing the Publishing category in 16.04? In 14.04, this includes > Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... > We have just been redesigning the category tree, so to speak. Publishing stays, but it is a subcategory to either graphics or office in the menu. And, the menu is under construction, so nothing is permanently defined yet. Our metas will be untouched for the next release, but will probably change somewhat for the release of trusty. -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Publishing Category
On Thu, Aug 20, 2015 at 2:14 PM, C. F. Howlett wrote: > Are we losing the Publishing category in 16.04? In 14.04, this includes > Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... > > No, I won't think so. The discussion have been around me suggesting to a writers application and where to put it, whether it be Publishing or elsewhere. The others will remain in the Publishing workflow as far as I know. /Jimmy -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[ubuntu-studio-devel] Publishing Category
Are we losing the Publishing category in 16.04? In 14.04, this includes Font Forge, Font Manager, Lyx, and Scribus. Seems a shame to lose it ... -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Next project lead
On Thu, Aug 20, 2015, at 11:18 AM, Kaj Ailomaa wrote: > REQUIREMENTS TO BE CANDIDATE > > What should be required of a candidate? > > I think everyone would agree on that the candidate needs to at least: > * be active and available > * know something about Ubuntu Studio development I would like to add that knowing something equivalent should suffice, since the candidate will have three months to learn about the Ubuntu Studio development process, and if the candidate has sufficient skills in similar areas, there should be no problem to pick up the administrative part of Ubuntu Studio development. So, if the candidate has enough experience in software development of any kind within the Linux world, it should not be too much of a burden to pick up the skills needed to lead the Ubuntu Studio project. In other words, it can be someone from the outside. > I also felt that the candidate should know: > * Debian packaging (and Debian Policy) > If someone skilled at Debian packaging will commit to the project for the two years, then the lead doesn't have to be an expert at that. But, it is still a lot easier, if the lead knows how this works. -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Next project lead
Some thougths inline below. On Thu, Aug 20, 2015 at 10:52 AM, Kaj Ailomaa wrote: > So, let's discuss how we do this. > > Ideally we have a vote. > > WHEN? > > I feel that it would be a good idea to have a vote on the next project > lead in January. That way the new project lead has three months to > prepare and is able to follow all of the work I do before a release. > After 16.04 is released, the new project lead is officially announced. > Any objections? > > Good idea. > WHO VOTES? > > Who should be allowed to vote? > I think as Xubuntu does, only team members should be allowed to vote. Though, it's a bit unclear what constitutes the Ubuntu Studio team. :) > > HOW DO WE VOTE? > > If we do an anonymous vote, we need to use some sort of a service. Which > is easiest/best? > I think the voting should be open, my suggestion is on IRC. No anonymous votes. However, that is just my opinion. On Thu, Aug 20, 2015 at 11:18 AM, Kaj Ailomaa wrote: > > REQUIREMENTS TO BE CANDIDATE > > What should be required of a candidate? > > I think everyone would agree on that the candidate needs to at least: > * be active and available > * know something about Ubuntu Studio development > > I also felt that the candidate should know: > * Debian packaging (and Debian Policy) > > Beyond that, I think it would be nice if the candidate also was required > to prepare a set of goals that he/she has for the next two years, so > that we know what we are voting for. > > Some thoughts about the next coming two years would be good to have, and how the lead is going to "run the business". Otherwise it is kind of voting in the dark unless you know the person beforehand. > > HOW OFTEN DO WE VOTE FOR A NEW PROJECT LEAD? > > I would like to suggest every two years. > > Agreed. I also think it might be helpful if you/we could document what is expected from the project lead, so they know what is expected of them before they volunteer for the position. But also as I wrote before, I think some of the tasks of current project lead could be delegated to other roles. That have not really been the case lately due to the team being so small. But with any luck the team might grow again and it wouldn't be such great task for someone in the PL roles to do more or less everything. /Jimmy -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Next project lead
The wiki page - https://wiki.ubuntu.com/UbuntuStudio/ProjectLeadVote -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Next project lead
Sorry, I forgot to mention about the candidates. REQUIREMENTS TO BE CANDIDATE What should be required of a candidate? I think everyone would agree on that the candidate needs to at least: * be active and available * know something about Ubuntu Studio development I also felt that the candidate should know: * Debian packaging (and Debian Policy) Beyond that, I think it would be nice if the candidate also was required to prepare a set of goals that he/she has for the next two years, so that we know what we are voting for. HOW OFTEN DO WE VOTE FOR A NEW PROJECT LEAD? I would like to suggest every two years. WIKI PAGE I'm preparing a page for documenting all this at - -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[ubuntu-studio-devel] Call for Beta Testing
Today is Debian Import Freeze - https://wiki.ubuntu.com/DebianImportFreeze. That means most of the applications we distribute won't be changing until Final Release, which is due at the end of October. That also means, this is a perfect time to start testing our ISOs for bugs. = HOW TO DO TESTING = We currently don't have very structured testing. We don't have a bunch of test cases ready. Instead, I ask everyone to just grab our latest ISO and start testing the stuff that they are interested in. The latest ISO is always here: http://cdimage.ubuntu.com/ubuntustudio/dvd/current/ Use zsync (cli tool) to download, so that when you download a new ISO, you only download the changes, not the full ISO. = IF YOU FIND BUGS = == APPLICATIONS == If you find a bug in any application, report your bug with this command in a terminal (replace with the name of the package): ubuntu-bug If you are unsure of the package name, please write to this mail list with questions. == DESKTOP ENVIRONMENT == If you find a bug in the desktop interface, like if something is not there that should be, you can report your bug here: https://bugs.launchpad.net/ubuntustudio/+filebug -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[ubuntu-studio-devel] Next project lead
So, let's discuss how we do this. Ideally we have a vote. WHEN? I feel that it would be a good idea to have a vote on the next project lead in January. That way the new project lead has three months to prepare and is able to follow all of the work I do before a release. After 16.04 is released, the new project lead is officially announced. Any objections? WHO VOTES? Who should be allowed to vote? HOW DO WE VOTE? If we do an anonymous vote, we need to use some sort of a service. Which is easiest/best? -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Feature Freeze Coming up
On Thu, Aug 20, 2015 at 9:41 AM, Kaj Ailomaa wrote: > On Thu, Aug 20, 2015, at 12:08 AM, Len Ovens wrote: > > On Wed, 19 Aug 2015, Jimmy Sjölund wrote: > > > > > > > As I mentioned before I'd like to look into incorporating > Plume > > > Creator in > > > > Ubuntu Studio, http://www.plume-creator.eu/. It is an > application > > > > dedicated > > > > to writing; blog posts, novels, essays or reports. > > > > > > Exactly, we had some talk about whether it would fit into Publishing > but it might > > > not be the best choice. > > > > > > Publishing in Freedesktop category have this spec: > > > > > > Publishing > > > Desktop Publishing applications and Color Management tools > > > Graphics or Office > > > > > > and Office: > > > > > > Office > > > An office type application > > > > ... > > > > > > When I compare with Scrivener which is a similar application it only > has "Office" > > > listed and it ends up in our Office menu when installed. > > > > > > I think Literature would be somewhat appropriate, but then it was > pointed to main > > > categories Education or Science, which to me seem a bit far fetched. > > > > > > I'd go for Office as no better alternative seem to exist. That would > put it > > > outside the Ubuntu Studio menu, I'm not sure if that's a problem? > > > > It doesn't have to be a problem. If it already fits in office we can just > > include it. We can still have it in the publishing meta regardless. This > > is what the publishing menu/meta was actually originally imagined to > > hold. > > I don't agree that this is what was imagined. And, I don't agree it goes > into the publishing meta. > Besides, we are going to redo those metas for next release, so that they > are in correlation with our way of categorizing. > > > The only thing that has changed is that publishing as a word has been > > found to be less than specific. However the idea of including Literature > > creating tools is not out of line and with a push to use existing > > Categories, Office is fine. I am sure many people will look there second > > if not first. > > > > -- > > Literature being a subcategory to education and science makes it not > work. But, what is actually the intention with that category? It looks a > little confused. > > Perhaps this is a case where you could actually add a new freedesktop > category, or change the literature category to be sub to office instead? > > In Ubuntu Studio we can have additional categories/workflows outside > those used in Debian sections, or freedesktop categories, but for the > sake of not getting people confused about English terms (which the > categories somehow represent), we need to be strict about how we use > them. > > Let's say we added a new meta called ubuntustudio-writing. That would > represent a workflow, rather than a tool set. > The freedesktop categories, and debian sections both focus on tool type, > rather than workflows. Currently, our metas do a bit of both. > ubuntustudio-writing (or whatever name we choose), would then include > all packages needed for that workflow, not that I think there are that > many. I think it's still an interesting area of digital arts creation. > > Ubuntustudio-writing is an interesting idea. That could include writer tools (like Plume Creator, Scrivener and such), applications to create e-books (not sure what those are as the applications I use all can produce e-books directly) and other that I don't know about to support the workflow. Then again writers often use stripped down text editors or Office applications. It is starting to grow that bloggers use special applications for their writing, so I believe it is a growing interest in tools that help the workflow and process. I think that workflow is the way to go rather than strict on application type. /Jimmy -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Feature Freeze Coming up
On Thu, Aug 20, 2015, at 12:08 AM, Len Ovens wrote: > On Wed, 19 Aug 2015, Jimmy Sjölund wrote: > > > > > As I mentioned before I'd like to look into incorporating Plume > > Creator in > > > Ubuntu Studio, http://www.plume-creator.eu/. It is an application > > > dedicated > > > to writing; blog posts, novels, essays or reports. > > > > Exactly, we had some talk about whether it would fit into Publishing but it > > might > > not be the best choice. > > > > Publishing in Freedesktop category have this spec: > > > > Publishing > > Desktop Publishing applications and Color Management tools > > Graphics or Office > > > > and Office: > > > > Office > > An office type application > > ... > > > > When I compare with Scrivener which is a similar application it only has > > "Office" > > listed and it ends up in our Office menu when installed. > > > > I think Literature would be somewhat appropriate, but then it was pointed > > to main > > categories Education or Science, which to me seem a bit far fetched. > > > > I'd go for Office as no better alternative seem to exist. That would put it > > outside the Ubuntu Studio menu, I'm not sure if that's a problem? > > It doesn't have to be a problem. If it already fits in office we can just > include it. We can still have it in the publishing meta regardless. This > is what the publishing menu/meta was actually originally imagined to > hold. I don't agree that this is what was imagined. And, I don't agree it goes into the publishing meta. Besides, we are going to redo those metas for next release, so that they are in correlation with our way of categorizing. > The only thing that has changed is that publishing as a word has been > found to be less than specific. However the idea of including Literature > creating tools is not out of line and with a push to use existing > Categories, Office is fine. I am sure many people will look there second > if not first. > > -- Literature being a subcategory to education and science makes it not work. But, what is actually the intention with that category? It looks a little confused. Perhaps this is a case where you could actually add a new freedesktop category, or change the literature category to be sub to office instead? In Ubuntu Studio we can have additional categories/workflows outside those used in Debian sections, or freedesktop categories, but for the sake of not getting people confused about English terms (which the categories somehow represent), we need to be strict about how we use them. Let's say we added a new meta called ubuntustudio-writing. That would represent a workflow, rather than a tool set. The freedesktop categories, and debian sections both focus on tool type, rather than workflows. Currently, our metas do a bit of both. ubuntustudio-writing (or whatever name we choose), would then include all packages needed for that workflow, not that I think there are that many. I think it's still an interesting area of digital arts creation. -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
