Alexander Leidinger

Just another weblog


How to fix FreeBSD for cor­po­ra­tions (and user with smaller instal­la­tions), the tools-viewpoint

There is a huge dis­cus­sion going on on hackers@ about how FreeBSD is not suit­able for large instal­la­tions (any­more?). As of this writ­ing, the dis­cus­sion seems to get some discussion-clusters. We have some sub-topics which could lead to some good improvements.

One subtopic is the release engi­neer­ing. Some changes like a more guided approach of what should be merged to which branch, the fre­quency of releases and maybe some kind of long-term-branch(es). There is some dis­cus­sion to get maybe some joined-funding in some way from inter­ested par­ties to pay some­one to take care about long-term-branch(es).

Another subtopic is the way bugs are han­dled in our old bug­track­ing soft­ware and how patches go unno­ticed there.

And both of them are con­nected (parts more, parts less) by what can be done in a vol­un­teer project.

To me it looks like the pro­pos­als “just” need some refine­ments and some “vol­un­teers” to put value (this means man power and/or money) to what they said.

What I want to dis­cuss here is, how tools could help with mak­ing PRs/patches more vis­i­ble to devel­op­ers (there is already the pos­si­bil­ity to get emails from the small bugbuster-team about patches in PR data­base, but you have to ask them to get them) and how to make it more easy to get patches into FreeBSD.

Mak­ing bugs more vis­i­ble to developers

The obvi­ous first: We need a dif­fer­ent bug­track­ing sys­tem. We already know about it. There is (or was…) even some­one work­ing IIRC on an eval­u­a­tion of what could be done and how easy/hard it would be. I am not aware of any out­come, despite the fact that it is months (or even a year) since this was announced. I do not blame any­one here, I would like to get time to fin­ish some FreeBSD vol­un­teer work myself.

In my opin­ion this needs to be han­dled in a com­mer­cial way. Some­one needs to be offi­cially paid (with a dead­line) to pro­duce a result. Unfor­tu­nately there is the prob­lem that the require­ments are in a way, that peo­ple do not have to change their workflows/procedures.

IIRC peo­ple ask that they should be able to send a mail to the bug­tracker with­out the need for authen­ti­ca­tion. Per­son­ally I think the bug­track­ing issue is in a state where we need to change our workflows/procedures. It is con­ve­nient to get mails from the bug­tracker and only have to reply to the mail to add some­thing. On the other hand, if I report bugs some­where, and if I really care about the prob­lem res­o­lu­tion, I am will­ing login to what­ever inter­face to get this damn prob­lem solved.

Send­ing a prob­lem report from the sys­tem where I have the issue in an easy way is a very use­ful fea­ture. Cur­rently we have send-pr for this and it uses emails. This means it requires a work­ing email setup. As an user I do not care if the tool uses email or HTTP or HTTPS, I just want to have an easy way to sub­mit the prob­lem. I would not mind if I first have to do a “send-problem reg­is­ter me@tld” (once), “send-problem login me@tld” (once per system+user I want to send from) and then maybe a “send-problem tem­plate write_template_here.txt” (to get some tem­plate text to fill out), edit the tem­plate file and then run “send-problem send my_report.txt file1 file2 …”. That would be a dif­fer­ent work­flow, but still easy.

Email noti­fi­ca­tions are surely needed, but if I really care about a prob­lem, I can be both­ered to reg­is­ter first. So in my opin­ion, we need a dif­fer­ent bug­tracker des­per­ately enough that we need to drop our require­ments regard­ing our cur­rent workflow/procedures (even if it means we can not get a com­mand line way of sub­mit­ting bugs at all). The pri­mary goal of the soft­ware needs to be to make it easy to track and resolve bugs. The sub­mis­sion of bugs shall be not hard too. If I look at the state of the world as it is ATM, I would say a webin­ter­face with authen­ti­ca­tion is not a big bur­den to take if I really want to get my prob­lem fixed. Some com­mand line tool would be nice to have, but regard­ing the cur­rent state of our bug­tracker it needs to be optional instead of a hard requirement.

Apart from mak­ing it easy to track and resolve prob­lems, the soft­ware also needs to be able to make us aware of the biggest prob­lems. Now… you may ask what is a big prob­lem. Well… IMO it does not mat­ter to you what I think is big or small here. The per­son with a prob­lem needs to decide what is a big prob­lem to him. And peo­ple with the same prob­lem need to be able to tell that it is also a big prob­lem for them. So a fea­ture which allows to “vote” or “+1″ or “AOL” (or how­ever you want to call it) would allow to let users with prob­lems voice their opin­ion upon the rel­e­vance of the prob­lem to our user­base. This also means there needs to be a way to see the high­est voted prob­lems. An auto­matic mail would be best, but as above this is optional. If I as a devel­oper really care about this, I can be both­ered to login to a webin­ter­face (or maybe some­one vol­un­teers to make a copy & paste and send a mail… we need to be will­ing to rethink our procedures).

Get­ting patches more easy into a FreeBSD branch

It looks to me that this topic is requires a lit­tle bit more involve­ment from mul­ti­ple tools. In my opin­ion we need to switch to a dis­trib­uted ver­sion con­trol sys­tem. One which allows to eas­ily cre­ate my own branch of FreeBSD on my own hard­ware, and which allows to let other users use my branch eas­ily (if I want to allow other to branch from my branch). It also needs to be able to let me push my changes towards FreeBSD. Obvi­ously not directly into the offi­cial sources, but into some kind of stag­ing area. Other peo­ple should be able to have a look at this stag­ing area and be able to review what I did. They need to be able to make some com­ments for oth­ers to see, or give some kind of (multi-dimensional?-)rating for the patch (code qual­ity / works for me / does not work / …). Based upon the review/rating and maybe some auto­mated eval­u­a­tion (com­pile test / regres­sion test / bench­mark run) a com­mit­ter could push the patch into the offi­cial FreeBSD tree (ideal would be some auto­mated noti­fi­ca­tion sys­tem, a push but­ton solu­tion for inte­gra­tion and so on, but as above we should not be afraid if we do not get all the bells and whistles).

If we would have some­thing like this in place, cre­at­ing some kind of long-term-release branch could be used more eas­ily in a colab­o­ra­tive man­ner. Com­pa­nies which use the same long-term-release branch could sub­mit their back­ports of fixes/features this way. They also could see if sim­i­lar branches (there could be related but dif­fer­ent branches, like 9.4–secu­rity–fixes-only <= 9.4-official-errata-only <= 9.4-bugfixes <= 9.4-bugfixes-and-driverupdates <= …) could be merged to their in-house branch (and maybe con­se­quently push-back to the offi­cial branch they branched from if the patch comes from a dif­fer­ent branch).

It does not mat­ter here if we would cre­ate a fixed set of branches for each release, or if we only cre­ate some special-purpose branches based upon the phase of the moon (ide­ally we would cre­ate a lot of branches for every release, companies/users can cherry pick/submit what they want, and the sta­tus of a long-term-branch is solely based upon the inflow of patches and not by what the secu­rity team or release man­ager or a ran­dom devel­oper thinks it should be… but the real­ity will prob­a­bly be some­where in the middle).

I do not know if tools exists to make all this hap­pen, or which tools could be put together to make it hap­pen. I also did not men­tion on pur­pose tools I am aware of which already pro­vide (small) parts of this. These are just some ideas to think about. Inter­ested par­ties are invited to join the dis­cus­sion on hackers@ (which is far away from dis­cussing spe­cific tools or fea­tures), but you are also free to add some com­ments here.


Tags: , , , , , , , , ,

Sony Bravia and HD videos (via DLNA)

I made some more tests which video res­o­lu­tions my TV accepts via DLNA. While I was look­ing before a SD res­o­lu­tions, this time I took care about some HD resolutions.

As the Sin­tel video in the 1024×436 res­o­lu­tion did not play, I tried to reen­code it to 1024×720 (for the enabled x264 options see below). This did not work either. After that I went to the offi­cial res­o­lu­tion of 1280×720, and this works. Ini­tially this video was encoded as High@L3.1, but with this the TV pro­duced some arti­facts on play­back. After chang­ing this to High@L4.0 (sim­ply by remux­ing instead of reen­cod­ing), the play­back was fine (warn­ing: increas­ing the H.264 level is OK, decreas­ing it if the video does not com­ply to the low­ered level, may cause prob­lems). I miss a set­ting in avide­mux for the level, it would be nice if there would be the pos­si­bil­ity to set it.

I also tested if the 1280×544 ver­sion of the Sin­tel video plays fine on the TV or not. It does not play fine, so there is prob­a­bly a hard require­ment on the com­plete res­o­lu­tion for HD video.

While doing this I noticed that tsMuxeR is trun­cat­ing the audio, instead of the 6 chan­nel audio it was before, the remuxed file has only two channels.

As I did not want to always go through all the set­tings to enter what I want, I made a lit­tle avidemux-script to setup (ECMA script + xml) every­thing for me. This was easy, I just took an exist­ing one (the Sony PSP one) as a base and changed the encod­ing options and the tar­get con­tainer (unluck­ily avide­mux 2.5.4 does not sup­port H.264 in MPEG-TS yet, so I have to use a MP4 con­tainer and remux it into the MPEG-TS stream afterwards).

The options I used for the x264-reencoding are –8x8dct –analyse all –mixed-refs –bime –weightb –subme 9 –b-rdo –ref 4 –b-adapt 2 –bframes 4 –direct auto –me umh (this includes b-pyramid, for which there are reports that it does not work).

Tags: , , , , , , , , ,

My pub­li­ca­tions and projects pages moved into the blog

I moved my pages about pub­li­ca­tions and projects into the blog. The con­tents of the pub­li­ca­tions are still at the old place (and there­fore in the same style as when I wrote them). I have not decided yet if I will import the con­tents of the pub­li­ca­tions into the blog or not. Import­ing the con­tents means every­thing would have a con­sis­tent style, not import­ing it would mean the con­tent is as “orig­i­nal” as possible.

Tags: ,

WP prob­lems solved

I solved my WP problems.

The perma­link prob­lem was because of a miss­ing .htac­cess file. I cre­ated one with write per­mis­sions for WP, and changed the permal­imk set­ting back.

The white-on-white issue was solved by set­ting CONCATENATE_SCRIPTS to false in wp–con­fig, so it seems to be a caching prob­lem some­where. Later I will take some time to switch back and flush some caches (at least where I have the rights to do it).

Tags: , , , , , ,

Blog moved to my own website

I took the time to move the blog to my own web­site. I can now post stuff which is not related to FreeBSD, and I do not use the resources of the project for this any­more. It also allows me to install a theme I like more, and I can install plu­g­ins like I want.
Now I just have to find the cause of some strange stuff I see. After import­ing my data from the FreeB­S­Dish blog, the perma­links do not work like I want, I have to use the ugly default way of han­dling perma­links. I also have to write this post with­out see­ing what I type, the edi­tor is dis­play­ing white text on a white background…

Tags: , , , , ,