Technical Board Meeting

[dale-f-beaudoin]

There will be a meeting of the Technical Board - The next meeting is set for 2017-12-05, 20:00 London time: We meet in channel #ubuntu-meeting-2 on chat.freenode.net.

I will be sending group mail to the unity7maintainers team and the U+1 team specifically calling for those who are experienced in bug triaging through launchpad and who know launchpad maintenance. I will also need a volunteer tutor to help me finish some of my launchpad training. jbicah, seb and didrocks were really very helpful in getting me started but there are a few more things I need to learn. I had stated before, I am not a launchpad janitor or triager, I am a turing/basic programmer and other but I want to be able to help as much as I can to fix bugs. I am currently captian of U+1 team where we do field testing for Ubuntu Development Version cycles and so my other commitments are there. I also maintain the U+1 wiki.

If you are already on one of my teams and can commit to triaging unity7 (and other) bugs then please leave a message in this thread so that I have something to bring with me to the technical board meeting. It is very important that I have committed individuals that I can reference at the board meeting because it may be a very critical point that might be made if Ubuntu Unity Experience is to become an official flavor.

This will all be volunteer work. Any help at all will be appreciated. If you eat, breath and sleep code and numbers then this is where you want to be

Regards…

[om26er]

Hi!

I have worked with launchpad for a long time and have probably triaged thousands of bugs, so I can help there.

PS: I was one of the responsibles of bug management of Unity going back to 2010, both voluntarily and later paid by Canonical.

[dale-f-beaudoin]

Awesome. Best news I heard all day!

Thanks!

Regards…

[danieldangol-f]

i have no experience in launchpad. but i wanted to stay in team for leaning. can i do that?

[dale-f-beaudoin]

Yes… of course you can.

[khurshid-alam]

@dale-f-beaudoin

will also need a volunteer tutor to help me finish some of my launchpad training. jbicah, seb and didrocks were really very helpful in getting me started but there are a few more things I need to learn.

I agree.
Apart from bug triaging, a simple instruction on making merge-request in right-way, is the most wanted issue regarding launchpad. Since Unity and all related projects have their source and bzr-branches in launchpad, making a simple merge request against upstream branch is most suitable and direct method compared to the traditional get-the-source--->create-debdiff---->upload-patch-to-bug method.

But the problem is Developing with launchpad and bzr is atm, haphazard. Once there was a coherent orderly method, UDD (Ubuntu Distributed Development). But UDD is defunct now (there are trying to replace udd+bzr to udd+git) so instruction written on the wiki doesn’t always work as intended. There is also ubuntu-desktop for which workflow of merge request is totally different than normal branches.

That is why I decided to revive my old wiki on bzr (recently removed from ubuntu community wiki due to lack of maintenance). I also have a plan to provide very simple instruction for git as well. I will make it available either on community wiki or on read-the-docs.

[cplate]

Likewise I’m with danieldangol, I haven’t had the opportunity of working with Launchpad before but I will be tagging along to learn as much as possible.

om26er, do you still regularly work on bug management? I was wonder if any of the newbies here who are skilled and willing to learn would be able to shadow you working?
Or if there are any learning materials like a launchpad training dale mentioned in the original post, all would be super helpful!!

[dale-f-beaudoin]

@dale-f-beaudoin

If you are already on one of my teams and can commit to triaging unity7 (and other) bugs then please leave a message in this thread so that I have something to bring with me to the technical board meeting. It is very important that I have committed individuals that I can reference at the board meeting because it may be a very critical point that might be made if Ubuntu Unity Experience is to become an official flavor.

Hi cplate,

So this will not be a tutorial thread.

Thanks …

Regards…

[khurshid-alam]

From the mailing-list the topics which will probably be discussed for unity in the board meeting are the issues pending and available on Unity/NotDefaultIssues - Ubuntu Wiki.

Let’s go through this one by one.

• libinput

GNOME (and others desktops) have been moving to libinput but Unity didn’t and installing the old driver leads to non working mouse settings under GNOME.

This is indeed most challenging issue. Porting to libinput probably won’t be that hard ( I can do that without the ui part), but if we port it to libinput we will lose some fine touch/trackpad gestures which are still not possible with libinput. So we need to make it work both ways a) with synaptics, b) with libinput. I need some help here.

• The default GNOME applications might look less well integrated

Ubuntu was carrying non trivial patches to some of its applications (nautilus, totem, …) to look better under Unity, in particular restoring the use of a classic menubar and avoiding client side decorations when being used under an unity session. To reduce the maintenance work those are being removed.

The tracking bug is this: 1719322 , And I already proposed several solutions.

• No online accounts

One simple solution is to use gnome-online-accounts panel in ucc, but it will add dependency on gnome-control-center and several other gnome components.

• Shared GSettings keys

Some settings are shared between the sessions and needs to be separated Tracked on Trello: https://trello.com/c/2uAVLGcb

I am decoupling unity-settings from ubuntu-settings. See bug: 1735998

Source: trunk : Code : unity-settings
unity-settings binary will be available in the testing ppa.

• deja-dup settings panel

deja-dup is building a panel for unity-control-center which creates a depends on that component which is being moved to universe → new binary for the panel is resolving the issue.

As said solution is simple. We need a separate deja-dup-unity binary.

• unity launcher integration

some applications are using libunity to integrate with the unity launcher (nautilus to display a progress bar on copies for example, deja-dup, update-manager) which forces us to keep that source in main

• libappindicator

to integrate with the unity indicator we build some code with libappindicator (update-notifier, vino, nmapplet, …) which forces us to keep libindicator/libdbusmenu in main

Not sure about this. Isn’t ubuntu also using app-indicators in gnome-shell ?

• gnome-user-share

To improve the GNOME experience and not hold back on updates, it is proposed to update gnome-user-share. The newest version of gnome-user-share does not offer GUI support. Maybe mate-user-share can be adapted to work instead.

We are testing if we could use mate-user-share instead (as Martin advised). We just need to distro-patch it to use nautilus-extension.

Other option is to fork gnome-user-share to unity-user-share.

[chanath]

@khurshid-alam

And I already proposed several solutions.

That solution is excellent, Nautilus looks more Unity.

[dale-f-beaudoin]

@khurshid-alam

We are testing if we could use mate-user-share instead (as Martin advised). We just need to distro-patch it to use nautilus-extension.

I hope to build an updated .ISO after TB with some of these changes.

[dale-f-beaudoin]

Hi All,

Technical Board did not immediately approve our request for official flavor. There was a group of questions that came just while the meeting was starting where we did not have time to prepare answers for. The questions had nothing to do with the recent preparations we have been involved with but I can understand their concerns. Also a lot of people didn’t show up. I guess that this could only be due to my lack of connecting with the team.

It is true that a lot of people want unity to go to sleep and die but I think the board is expressing their thoughts as best they can:
“slangasek my gut reaction is similar to yours that unity7 should just be allowed to die peacefully instead of being made a flavor; but I’m not sure with TB hat on it’s in order for me to argue that”
https://irclogs.ubuntu.com/2017/11/21/%23ubuntu-meeting-2.html#t20:06

…to the effect that their has to be some sort of responsible maintenance for upstream packages and bug fixing and it is their argument that the required skill-set and manpower is just not there.

We will keep trying.

Regards…

[popey]

Worth linking to this weeks TB meeting log too I think.

https://irclogs.ubuntu.com/2017/12/05/%23ubuntu-meeting-2.html#t20:00

[dale-f-beaudoin]

@popey

Yes. Much appreciated. In retrospect , there was a lot accomplished.

Regards…

[GizmoChicken]

After reading the entire transcript from the Technical Board Meeting (and also reading the questions asked in the message sent just before the meeting started), the following statement made by @stgraber at 20:36 seems particularly revealing:

getting a new flavor in Ubuntu is a process which usually takes months/years, there will be quite a few discussions both on IRC and e-mail about it. Since you were around it felt appropriate to keep this on the agenda rather than postpone it to another meeting so we could get some of that discussion done now.

I sense that the Ubuntu Unity team likely won’t have sufficient time to obtain official flavor status for an 18.04 release.

If the Ubuntu Unity team agrees that obtaining official flavor status for an 18.04 release is unlikely, then, rather than chase after what is unlikely, perhaps time would be better spent if the team were to change its focus to releasing an “Ubuntu Unity Remix” (preferably under an appropriate license to use the “Unity” name, if needed) for 18.04. The team could try again for official flavor status in a later release, once the team has proven itself.

[ian-weisser]

It helps to have a tea (or two or three) and then to re-read.

Upon my re-read, the Technical Board seems quite open to Unity as a flavor, after a few more key metrics are in place that show the scope of the project (package list), resources available (committed uploaders with reputation), and that the leadership has some kind of coverage plan so B meets A.

Seems like solid advice.

It also shows just how far your team has come already!

[dale-f-beaudoin]

@GizmoChicken

After reading the entire transcript from the Technical Board Meeting (and also reading the questions asked in the message sent just before the meeting started), the following statement made by @stgraber at 20:36 seems particularly revealing:

getting a new flavor in Ubuntu is a process which usually takes months/years, there will be quite a few discussions both on IRC and e-mail about it. Since you were around it felt appropriate to keep this on the agenda rather than postpone it to another meeting so we could get some of that discussion done now.

I sense that the Ubuntu Unity team likely won’t have sufficient time to obtain official flavor status for an 18.04 release.

That is a speculation that I cannot answer and borders on the hypothetical. jbicha did send a list to us a week prior to the meeting and we had assumed incorrectly that the items he mentioned would be the issues discussed at the meeting just recent past and Khurshid was prepared to asnwer to those issues. Unity/NotDefaultIssues - Ubuntu Wiki Some people did not make it to the meeting, probably because of time zone or other personal reasons

@GizmoChicken

If the Ubuntu Unity team agrees that obtaining official flavor status for an 18.04 release is unlikely, then, rather than chase after what is unlikely, perhaps time would be better spent if the team were to change its focus to releasing an “Ubuntu Unity Remix”

This will be up to Khurshid to determine this direction as he is current team leader. He has painstakingly built a lot of infrastructure that was presentable enough a platform to go forward and propose that the team could handle official flavor status. In the interim I will be working on recruiting the few missing pieces that the TB is requiring and hope to answer their shortlist as expediently as possible. If the TB , in their good conscience cannot vote us forward sometime in January then perhaps a remix may be the only way to go for the team. So that will be a remix image built on Canonical servers.

@GizmoChicken

“Ubuntu Unity Remix” (preferably under an appropriate license to use the “Unity” name, if needed) for 18.04. The team could try again for official flavor status in a later release, once the team has proven itself.

This may also be the case. So the team may have to apply for an additional license through legal. I will continue to build Remixes as my license permits me to do so but in a more limited fashion as I only have a certain amount of space to use and a bandwidth requirement to fit into my own budget as I too , like the TB, am only a volunteer offering a service and my license does not permit me to grant proxy licenses to individuals.

Regards…

[dale-f-beaudoin]

Thanks Ian,

@ian-weisser

It helps to have a tea (or two or three) and then to re-read.

Upon my re-read, the Technical Board seems quite open to Unity as a flavor, after a few more key metrics are in place that show the scope of the project (package list), resources available (committed uploaders with reputation), and that the leadership has some kind of coverage plan so B meets A.

It’s quite possible that growing the knowledge base and communication channels for both A and B may take more time than is conveniently available for 18.04, and that @GizmoChicken’s suggestion is sensible.

Seems like solid advice.

Yes … goal of the team is greater than anyone person. I think the core of the team is on the same page but it certainly is an emotionally charged issue. As it stands now, team lead, K_alam, has built a solid infrastructure whilst I am trying to recruit a few more key components in the form of developer manpower hours. It was a little disconcerting that the TB did not want to hear about my past 7 year commitment to ubuntuforums, the Development Version Testing, taking care of team maintenance and keeping the wiki updated, pretty well single handedly so their attitude towards it all seemed very much, initially, like a slight, however , in my experience, I know that only cordiality , apologetics and red rose tea will win the day Upon my review I have seen that it went quite well and was a very professional conducted slice of work.

Gizmo-chicken , of course, has made some good points but most observers are not really able to appreciate the down_time that the participants are subjected to, especially when they are volunteering their quality time. I am confident that @tsimonq2 and @khurshid-alam will pull these prerequisite package lists together to start getting image builds on the servers.

Regards…

[GizmoChicken]

@dale-f-beaudoin

I am confident that @tsimonq2 and @khurshid-alam will pull these prerequisite package lists together to start getting image builds on the servers.

I have no doubt that you and your team can pull this together. But even so, my instincts still tell me that the Technical Board will want to see a longer track record before granting official “flavor” status.

To reiterate what @ian-weisser wrote:

@ian-weisser

Upon my re-read, the Technical Board seems quite open to Unity as a flavor, after a few more key metrics are in place . . .

If I recall correctly: MATE Remix preceded Ubuntu MATE; GNOME Remix preceded Ubuntu GNOME; and Budgie Remix preceded Ubuntu Budgie. So if Ubuntu Unity must first exist for a short time as Unity Remix (until a few more key metrics are in place), consider yourself in good company.

Many (including me!) are eager to continue using Unity (whether an official flavor or a remix) and wish you and your team success.

[dale-f-beaudoin]

@GizmoChicken

(until a few more key metrics are in place), consider yourself in good company.

Yes… I do.

@GizmoChicken

Many (including me!) are eager to continue using Unity (whether an official flavor or a remix) and wish you and your team success.

We had done our level best to expedite the process and fell short on some launchpad mechanics, and thank you for your vote of confidence.