FLOSS Project Planets
There are multiple ways to write an app in Python. However, not all of them provide your users with the best experience.
One of the problems some people encounter is writing launch scripts. The best way to handle this is the Entry Points mechanism of Setuptools, and a __main__.py file. It’s quite easy to implement. If you’re interested, read on to learn more!
Read more… (17 paragraphs remaining — a 1 minutes’ read)
The Continuous Integration (CI) system combined with signed release tags in git has resulted in a greatly simplified process indeed it has become almost completely automated. The majority of the manual work is now confined to doing the tasks that require actual decision making and checking we are releasing what was intended.
By having the CI system build release binaries the project now has a much clearer and importantly traceable process, I can recommend such a system to any project that produces releases especially if they release binaries for any of their targets.
I have also managed to package and upload this version of NetSurf ready for the Debian Jessie release. I would like to thank Jonathan Wiltshire for his assistance in ensuring this was a good quality package.
The release incorporates the successfully merged work of Rupinder Singh who was our our GSoc 2014 student. Rupinder mainly made improvements to our core DOM implementation and was very responsive and enthusiastic throughout his time despite the mentor team sometimes not being available.
This work goes towards improving NetSurf in the future by ensuring the underlying features are present in our core libraries. The GSoc mentors and all project developers are all pleased with the results of this years GSoc participation and would like to thank everyone involved in making our participation possible.
Along with the good news comes a little bad:
- PowerPC Mac OS X
- Despite repeated calls for assistance with new hardware and Java builds none has been forthcoming meaning that from this release we ware no longer able to ship PowerPC builds for MAC OS X.
The main issue is the last version of MAC OS X that runs on PPC is Leopard and there is no viable Java 1.6 port necessary for our CI system to run. Additionally the fully loaded PPC Mac mini (kindly donated to us by Mythic Beasts) had become far too slow to keep up with our builds and was causing long delays.
- We have a lot of bugs, in fact just during this release cycle we have 30 more bugs reported than we closed.So while the new bug reporting system has been a success and our users are reporting issues when they find them the development team is not keeping up..
- The failure to keep up stems from the underlying issue of lack of manpower. We have relatively few active developers which is especially problematic when there are many users for a platform, such as RISCOS, but the maintainer is unable to commit enough time to fixing issues.
- If you would like to help making NetSurf a better browser we are always happy to work with new contributors.
As rar is a non free package, we don’t have it in default repository. You can easily install it from FLR (foresighters, foresight linux learning) repository.
All information is located here: http://wiki.foresightlinux.se/index.php?title=Unrar
We will continue make useful packages available for users.
I just spent the past week in China, and I thought I'd share a few reflections on the state of Drupal in China.
First, let me set the stage. There are 1.35 billion people living in China; that is almost 20 percent of the world's population. Based on current trends, China's economy will overtake the US within the next few years. At that point, the US economy will no longer be the largest economy in the world. China's rapid urbanization is what has led to the country's impressive economic growth over the past couple of decades and it doesn't look like it is going to stop anytime soon. To put that in perspective: China currently produces and uses 60 percent of the world's cement.
In terms of Drupal, the first thing I learned is that "Drupal" sounds like "the pig is running" ("Zhu Pao") in Chinese. Contrary to a pig's rather negative reputation in the West, many Chinese developers find that cute. A pig is a more honorable sign in Chinese astrology and culture. Phew!
In terms of adoption, it feels like the Drupal community in China is about 8 to 10 years behind compared to North America or Europe. That isn't a surprise, as Open Source software is a more recent phenomenon in China than it is in North America or Europe.
Specifically, there are about 5 Drupal companies in Shanghai (population of 21 million people), 3 Drupal companies in Beijing (population of 23 million people) and 5 Drupal companies in Hong Kong (population of 7 million people). The largest Drupal companies in China have about 5 Drupal developers on staff. Four of the 5 Shanghai companies are subsidiaries from European Drupal companies. The exception is Ci&T, which has 40 Drupal developers in China. Ci&T is a global systems integrator with several thousand employees worldwide, so unlike the other companies I met, they are not a pure Drupal play. Another point of reference is that the largest Drupal event in China attracted 200 to 300 attendees.
Given that China has 4 times the population of the US, or 2 times the population of Europe, what are we missing? In talking to different people, it appears the biggest barrier to adoption is language. The problem is that Chinese Drupal documentation is limited; translation efforts exist but are slow. The little documentation that is translated is often outdated and spread out over different websites. Less than 20 percent of the Chinese Drupal developers have an account on Drupal.org, simply because they are not fluent enough in the English language. Most Drupal developers hang out on QQ, an instant messaging tool comparable to Skype or IRC. I saw QQ channels dedicated to Drupal with a couple thousand of Drupal developers.
There is no prominent Chinese content management system; most people appear to be building their websites from scratch. This gap could provide a big opportunity for Drupal. China's urbanization equals growth -- and lots of it. Like the rest of the economy, Drupal and Open Source could be catching up fast, and it might not take long before some of the world's biggest Drupal projects are delivered from China.
Supporting Drupal's global growth is important so I'd love to improve Drupal's translation efforts and make Drupal more inclusive and more diverse. Drupal 8's improved multilingual capabilities should help a lot, but we also have to improve the tools and processes on Drupal.org to help the community maintain multi-lingual documentation. Discussing this with both the Drupal Association and different members of our community, it's clear that we have a lot of good ideas on what we could do but lack both the funding and resources to make it happen faster.
Every developer has a slightly different approach to building their Drupal sites. I’ve tried just about every approach, and they all have their merits, but my favorite is Drush Make. Before joining Acquia, I didn’t realize Acquia Cloud supported Drush Make, but I was delighted to discover that I was wrong. Assuming I’m not the only person who had missed this fact, I wanted to spend a little time highlighting where this exists and how I’m using it.
Almost everything we do on the web will work better with autonomous blockchain technologies such as Bitcoin & ethereum because they allow systems to be built with unbreakable rules. Unlike Facebook, Twitter, Airbnb, Uber, PayPal or eBay, no executive authority can step in and say the rules don't apply to you.
Of all the blockchain technologies, Bitcoin is currently the most high profile. It is a massive area of growth in the startup eco-system.
Drupal 8 is going to be a fantastic platform for building startups, but we need to make sure that it is also a fantastic platform for blockchain startups.
I've started by creating a Drupal 7 & 8 project called Coin Tools. It provides various components that would be useful for building a Bitcoin web product. Many of the altcoins are very similar to Bitcoin so the project could easily be extended to accommodate them.
Contains the following field types:
- facilitates configuration and access to bitcoind service
- triggers a hook when a Bitcoin transaction is detected
- provides a full UI for browsing transactions and sending and receiving bitcoin
I am currently working on a full implementation of BIP 70 which provides a much improved payment experience for the customer. Then I will add integration with Payment / Commerce. This means it will be possible to receive payments in Commerce without using a third party payment processor.Coins Tools Fiat
- obtains bitcoin exchange rates from BitcoinAverage (which I consider to be the gold standard), falling back to BitPay BBB
- facilitates rendering of fiat amounts
- user can select preferred fiat currency
- current bitcoin value block
If you would like help developing your Bitcoin startup on Drupal, please get in touch.
PyCon Videos & PicturesIf you weren't able to join us, the tutorials and talks were recorded and are available online at PyVideo. There are also a ton of great pictures from PyCon 2014. Be sure to check them out, and add your photos to the group!Thank you so much to the program committees – they reviewed over 800 proposals, and spent the better part of their year putting together a fantastic schedule.
- Diversity Outreach Chair: Jessica McKellar
- Talk Chairs: Luke Sneeringer & Alex Gaynor
- Tutorials Chairs: Stuart Williams & Ruben D. Orduz
- Posters Chairs: Juan Gomez & Gustavo Pinto
- Lightning Talk Chairs: Lynn Root & Nilovna Bascunan-Vasquez
Mathieu Leduc-Hamel, president of Montreal Python, and his team were a seemingly bottomless source of volunteers and enthusiasm. They helped bring childcare to PyCon for the first time, taught the Young Coders class in French, and organized many other PyCon firsts like the PyCon Dinners & Explore Montreal. They were instrumental in every step of the way. Thank you!
Lynn Root, and all the PyLadies work year round on outreach and mentorship, and no where is that more evident than when they come together in full force at PyCon to speak, and share their success stories. The additional $40,000 PyLadies raised in financial aid to bring more women to PyCon, and their PyCon events like the PyLadies Lunch & the PyLadies Auction play a huge role in making PyCon one of the most welcoming events in tech. A huge thanks to all the PyLadies, and those who support them!Until Next Year!PyCon 2015 will be held in Montreal again next year from April 8th - 16th, 2015. We hope to see you there!Tutorials: April 8th - 9thConference: April 10th - 12thSprints: April 13th - 16th
The 2014 launch day began with 17 sponsors, and quickly grew to 128. Are you or your organization interested in being a part of an even bigger launch for the best PyCon yet?
Sponsorship is what allows PyCon to do what it does. It enables us to fund programs like Financial Aid and subsidized child care, bringing more people to PyCon who otherwise may not have made it. It also allows us to run events like the Young Coders tutorials, bringing Python to children.
Sponsorship brings great benefits to its supporters. What better place to hire Python developers than at the largest collection of them around the world? Our expo hall and job fair are a great place to make connections with over 2,000 Python developers. For more thoughts on sponsorship benefits, see our https://us.pycon.org/2014/sponsors/whysponsor/ page.
Check out the PyCon Sponsorship Prospectus for more information about the sponsorship benefits and levels. To sign up as a launch day sponsor, or if you have any questions about sponsorship, please contact the conference Chair, Diana Clarke (email@example.com).
As with the last three conferences, PyCon 2015 will sell out. Be sure to mark your calendars for April 8-16, 2015, and look for our ticket sales announcements, usually in September. We'll also be sending out our Call for Proposals of talks and tutorials soon, usually in July.
If you don't have a passport, don't forget that Canada requires one. US residents should see http://travel.state.gov/passport/ for details.
Submit a Proposal Financial AidPyCon gives out over $100,000 in financial aid each year, with preference given to those speaking at PyCon, so please don't let money stop you from submitting a proposal!
Apply for Financial Aid ChildcarePyCon is also proud to be offering subsidized childcare for the second year in the row! High staff ratios have been arranged so that all children will get exceptional personalized care.
Register for Childcare RegistrationRegistration for PyCon opened just a few weeks ago, and tickets are selling fast! We've sold out for the past few years, so don't delay. Early bird ticket prices apply to the first 800 tickets sold.
Register for PyCon SponsorshipSponsors are what make this conference possible. From low ticket prices, to financial aid and video recording, the organizations who step forward to support PyCon, in turn support the entire Python community. A huge thanks to all of our sponsors!
Have a great weekend & don't forget to submit a proposal for PyCon!
자료구조와 알고리즘을 빠삭하게 꾀고 있는 베스트 프로그래머가 될 필요는 없다. 그래봐야 그냥 우수한 코더가 될 뿐이니까.
Dashboard (where you submit):
CFP announcement post:
Go for it!
This will be the fourth global meeting where users, developers and interested people will have the opportunity to discover or talk about Tryton.
Until now, the following talks are proposed:
- What's new in Tryton 3.4
- Synchronisation engine: The case study of Jamaica health records
- Writing your first module for Tryton
(More to be announced on our Lanyrd page)
The second Foundation Supporter Meeting will take place on Saturday 15h, 18.00.
Registration is available at TUL 2014.
If you like to give a talk, please announce it on Lanyrd. If you want to request a talk on a specific topic, you can send your request to the Tryton mailing list. If you have question about the organisation, please contact the foundation at firstname.lastname@example.org.
And don't forget to spread the word! #TUL2014
A lot of people read up on good Python practice, and there's plenty of information about that on the Internet. Many tips are included in the book I wrote this year, The Hacker's Guide to Python. Today I'd like to show a concrete case of code that I don't consider being the state of the art.
In my last article where I talked about my new project Gnocchi, I wrote about how I tested, hacked and then ditched whisper out. Here I'm going to explain part of my thought process and a few things that raised my eyebrows when hacking this code.
Before I start, please don't get the spirit of this article wrong. It's in no way a personal attack to the authors and contributors (who I don't know). Furthermore, whisper is a piece of code that is in production in thousands of installation, storing metrics for years. While I can argue that I consider the code not to be following best practice, it definitely works well enough and is worthy to a lot of people.Tests
The first thing that I noticed when trying to hack on whisper, is the lack of test. There's only one file containing tests, named test_whisper.py, and the coverage it provides is pretty low. One can check that using the coverage tool.$ coverage run test_whisper.py
Ran 11 tests in 0.014s
$ coverage report
Name Stmts Miss Cover
test_whisper 134 4 97%
whisper 584 227 61%
TOTAL 718 231 67%
While one would think that 61% is "not so bad", taking a quick peak at the actual test code shows that the tests are incomplete. Why I mean by incomplete is that they for example use the library to store values into a database, but they never check if the results can be fetched and if the fetched results are accurate. Here's a good reason one should never blindly trust the test cover percentage as a quality metric.
When I tried to modify whisper, as the tests do not check the entire cycle of the values fed into the database, I ended up doing wrong changes but had the tests still pass.No PEP 8, no Python 3
The hacking tool also shows that the code is not Python 3 ready as there is usage of Python 2 only syntax.
A good way to fix that would be to set up tox and adds a few targets for PEP 8 checks and Python 3 tests. Even if the test suite is not complete, starting by having flake8 run without errors and the few unit tests working with Python 3 should put the project in a better light.Not using idiomatic Python
A lot of the code could be simplified by using idiomatic Python. Let's take a simple example:def fetch(path,fromTime,untilTime=None,now=None):
fh = None
fh = open(path,'rb')
return file_fetch(fh, fromTime, untilTime, now)
That piece of code could be easily rewritten as:
with open(path, 'rb') as fh:
return file_fetch(fh, fromTime, untilTime, now)
This way, the function looks actually so simple that one can even wonder why it should exists – but why not.
Usage of loops could also be made more Pythonic:for i,archive in enumerate(archiveList):
if i == len(archiveList) - 1:
for i, archive in itertools.islice(archiveList, len(archiveList) - 1):
could be actually:
Wrong abstraction level
That reduce the code size and makes it easier to read through the code.
Also, one thing that I noticed in whisper, is that it abstracts its features at the wrong level.
Take the create() function, it's pretty obvious:def create(path,archiveList,xFilesFactor=None,aggregationMethod=None,sparse=False,useFallocate=False):
# Set default params
if xFilesFactor is None:
xFilesFactor = 0.5
if aggregationMethod is None:
aggregationMethod = 'average'
#Validate archive configurations...
#Looks good, now we create the file and write the header
raise InvalidConfiguration("File %s already exists!" % path)
fh = None
fh = open(path,'wb')
fcntl.flock( fh.fileno(), fcntl.LOCK_EX )
aggregationType = struct.pack( longFormat, aggregationMethodToType.get(aggregationMethod, 1) )
oldest = max([secondsPerPoint * points for secondsPerPoint,points in archiveList])
maxRetention = struct.pack( longFormat, oldest )
xFilesFactor = struct.pack( floatFormat, float(xFilesFactor) )
archiveCount = struct.pack(longFormat, len(archiveList))
packedMetadata = aggregationType + maxRetention + xFilesFactor + archiveCount
headerSize = metadataSize + (archiveInfoSize * len(archiveList))
archiveOffsetPointer = headerSize
for secondsPerPoint,points in archiveList:
archiveInfo = struct.pack(archiveInfoFormat, archiveOffsetPointer, secondsPerPoint, points)
archiveOffsetPointer += (points * pointSize)
#If configured to use fallocate and capable of fallocate use that, else
#attempt sparse if configure or zero pre-allocate if sparse isn't configured.
if CAN_FALLOCATE and useFallocate:
remaining = archiveOffsetPointer - headerSize
fallocate(fh, headerSize, remaining)
fh.seek(archiveOffsetPointer - 1)
remaining = archiveOffsetPointer - headerSize
chunksize = 16384
zeroes = '\x00' * chunksize
while remaining > chunksize:
remaining -= chunksize
The function is doing everything: checking if the file doesn't exist already, opening it, building the structured data, writing this, building more structure, then writing that, etc.
That means that the caller has to give a file path, even if it just wants a whipser data structure to store itself elsewhere. StringIO() could be used to fake a file handler, but it will fail if the call to fcntl.flock() is not disabled – and it is inefficient anyway.
There's a lot of other functions in the code, such as for example setAggregationMethod(), that mixes the handling of the files – even doing things like os.fsync() – while manipulating structured data. This is definitely not a good design, especially for a library, as it turns out reusing the function in different context is near impossible.Race conditions
There are race conditions, for example in create() (see added comment):if os.path.exists(path):
raise InvalidConfiguration("File %s already exists!" % path)
fh = None
# TOO LATE I ALREADY CREATED THE FILE IN ANOTHER PROCESS YOU ARE GOING TO
# FAIL WITHOUT GIVING ANY USEFUL INFORMATION TO THE CALLER :-(
fh = open(path,'wb')
That code should be:
fh = os.fdopen(os.open(path, os.O_WRONLY | os.O_CREAT | os.O_EXCL), 'wb')
except OSError as e:
if e.errno = errno.EEXIST:
raise InvalidConfiguration("File %s already exists!" % path)
to avoid any race condition.
We saw earlier the fetch() function that is barely useful, so let's take a look at the file_fetch() function that it's calling.def file_fetch(fh, fromTime, untilTime, now = None):
header = __readHeader(fh)
The first thing the function does is to read the header from the file handler. Let's take a look at that function:
info = __headerCache.get(fh.name)
originalOffset = fh.tell()
packedMetadata = fh.read(metadataSize)
(aggregationType,maxRetention,xff,archiveCount) = struct.unpack(metadataFormat,packedMetadata)
raise CorruptWhisperFile("Unable to read header", fh.name)
The first thing the function does is to look into a cache. Why is there a cache?
It actually caches the header based with an index based on the file path (fh.name). Except that if one for example decide not to use file and cheat using StringIO, then it does not have any name attribute. So this code path will raise an AttributeError.
One has to set a fake name manually on the StringIO instance, and it must be unique so nobody messes with the cacheimport StringIO
packedMetadata = <some source>
fh = StringIO.StringIO(packedMetadata)
fh.name = "myfakename"
header = __readHeader(fh)
The cache may actually be useful when accessing files, but it's definitely useless when not using files. But it's not necessarily true that the complexity (even if small) that the cache adds is worth it. I doubt most of whisper based tools are long run processes, so the cache that is really used when accessing the files is the one handled by the operating system kernel, and this one is going to be much more efficient anyway, and shared between processed. There's also no expiry of that cache, which could end up of tons of memory used and wasted.
None of the docstrings are written in a a parsable syntax like Sphinx. This means you cannot generate any documentation in a nice format that a developer using the library could read easily.
The documentation is also not up to date:def fetch(path,fromTime,untilTime=None,now=None):
This is something that could be avoided if a proper format was picked to write the docstring. A tool cool be used to be noticed when there's a diversion between the actual function signature and the documented one, like missing an argument.
Last but not least, there's a lot of code that is duplicated around in the scripts provided by whisper in its bin directory. Theses scripts should be very lightweight and be using the console_scripts facility of setuptools, but they actually contains a lot of (untested) code. Furthermore, some of that code is partially duplicated from the whisper.py library which is against DRY.Conclusion
There are a few more things that made me stop considering whisper, but these are part of the whisper features, not necessarily code quality. One can also point out that the code is very condensed and hard to read, and that's a more general problem about how it is organized and abstracted.
A lot of these defects are actually points that made me start writing The Hacker's Guide to Python a year ago. Running into this kind of code makes me think it was a really good idea to write a book on advice to write better Python code!The Hacker's Guide to Python
A book I wrote talking about designing Python applications, state of the art, advice to apply when building your application, various Python tips, etc. Interested? Check it out.
Unlike DrupalCon Austin, there is no separate UX track at DrupalCon Amsterdam. Ruben and I had to balance both design and development into one track. It was challenging, but it forced us to be really careful about every decision remade.
We really wanted there to be an overlap between sessions, frontend development and design are closer than ever in the workplace, so we wanted to reflect that in our session line up.
Here are a few sessions we think complement each other really well.The State of the Frontend
Not sure what to learn or where to start in frontend development? Let David and Brian guide you through the landscape, introducing new tools and techniques.
We've also planned this session as an introduction to the entire track, pointing signposts towards other sessions in that track that can fill in more in-depth knowledge about particular subjects. I would encourage everyone with an interest in frontend development to attend the session if only to better understand which sessions in the frontend track are right for them.
We also have a few session that compliment and feed in to each other. Here are a few sessions we think work really well together.Because it's about the interactions. (Better UX through prototyping) & Axure Prototyping for Drupal
How do we shift from an old design process to a new one while keeping our clients and team members happy? Roy Scholten, UX co-maintainer for Drupal Core, walks us through why prototyping is a better way to design and how to introduce this into your work life.
Then, in Axure Prototyping for Drupal, Dani Nordin takes us on a deep dive of Axure, a prototyping tool you can use without coding. I've been using it recently on a client project and I've been impressed with the way it introduces some concepts of frontend development without asking you to write code.The Future of HTML and CSS
As a designer, knowing the limits and capabilities of your medium is important, also it means you can call your developers out when they hit you with “That's not possible” which is fun. If you're interested in seeing where web browsers are heading and finding new tricks to add to your repertoire, Preston's talk on The Future of HTML and CSS should be a treat.Getting a CLUE at the Command Line
As a designer/front-end dev, I've never had a formal education on the command line, it's always been something I've picked up as I've needed it. It used to scare me. This is me using the command line a few years ago:
I'm so happy Emma Jane is talking on the command line in Getting a CLUE at the Command Line in the same vein as her introduction to Git at DrupalCon Prague last year. The command line is an immensely powerful and productive tool and I'm looking forward to picking up a few tips.Open Source Design
Something I've struggled with, both in my day job and as the maintainer of Drupal's admin theme is how do we bring successful design together with Open Source. I'm really happy that Jan-C. Borchardt, agreed to speak at DrupalCon and share his knowledge and experience with us. Jan is a big supporter of usability and design in free and open source software, with projects including A guide to Usability in Free Software, OwnCloud, Libre Projects, and the brilliant Terms of Service; Didn't Read.
It's really important for Drupal for us to gain insight from people outside the community and learn from other projects. Thanks again Jan for agreeing to speak! I can't wait!
Lewis Nyman (LewisNyman)
DrupalCon Amsterdam Frontend Track Chair
I’m not used to talking about my day job but here’s an exception.
Over the past few years I worked in two startups (3 years each). It was nice to spend time in different areas: one job was mostly about research and development in a Linux cluster environment; the other one was about maintaining a highly-customized, Linux-based operating system, managing a small support team, and performing technological surveillance in IT security.
In the meanwhile I’ve reached a milestone: 10 years with Debian. I had been wondering for a few months whether I could try my luck going freelance, becoming a Debian consultant. I finally decided to go ahead and started in August!
The idea is to lend a hand for various Debian-related things like systems administration, development/debugging, packaging/repository maintenance, or Debian Installer support, be it one-shot or on a regular basis. I didn’t think about trainings/workshops at first but sharing knowledge is something I’ve always liked, even if I didn’t become a teacher.
For those interested, details can be found on my website: https://mraw.org/.
Of course this doesn’t mean I’m going to put an end to my volunteer activities within Debian, especially as a Debian Installer release manager. Quite the contrary in fact! See the August and September debian-boot@ archives, which have been busy months. :)
A little more than a year ago, I started working as a syslog-ng OSE developer full-time. That was a tremendously important milestone in my career, as one of the goals I wanted to achieve in life - to work on free software for a living - became a reality. Rocket boots were fired up, and we accomplised quite a lot in the past year, and I'm very, very proud of the work we did - we, the whole community. I enjoyed every bit of it, but as it turns out, some of the other desires I wish to pursue, and new challenges I am looking for, will lead me in a different direction. At the end of August, I handed in my resignation, and the past friday was my last work day at BalaBit.
There are a few questions that will likely be asked, and I'll try my best to answer them beforehand. Questions such as: What will happen to syslog-ng?, Who will be the new maintainer?, How does this affect your Debian work?, and so on, and so forth.syslog-ngWhat will happen to syslog-ng?
After careful consideration, with the syslog-ng team at BalaBit, we decided that they will take over OSE-related responsibilities as well. They will do releases, they will engage the people on GitHub and the mailing list, they will take care of the @sngOSE twitter account.
During the past few months, we've been working on pushing the team closer to the community: we moved issues to GitHub, the team submitted pull requests, and in general, we moved closer to each other in every possible way.
While they may not have the open source maintainer experience I had, they are all capable folk, and will quickly learn on the job. The team taking over also has the advantage of having more manpower, and better collaboration between the premium edition and OSE.Who will be the syslog-ng maintainer?
There will be no single bottle neck. This has both good and bad implications, but I believe the good ones outweigh the disadvantages.What about the roadmap? When will 3.6.1 happen?
The roadmap is already laid out for 3.6, but it is the team's judgement when it will be released. The latest 3.6.0beta2 was released together with the team, too. I expect there will be delays (I planned 3.6.1 to be released on September 27th), but not much; a few weeks, perhaps.What will your involvement in syslog-ng development be?
With changing jobs, my involvement will drastically decrease. I will remain a syslog-ng user, and I will continue packaging it for Debian and Ubuntu, and will keep my unofficial repository running. I do not see myself contributing much, perhaps bug reports, opinions and an occasional idea.
Nevertheless, my expertise is still considerable, and I will help the team and the community in whatever way I can - but I will be severely time constrained.Debian
While BalaBit were very free software friendly, and allowed me to work on Debian tasks from time to time, my other activities took up an increasingly big chunk of my paid time, and I had to cut back a little. At the new job, things will be a bit different: while I won't have as much time to do Debian work on the job, I will have a lot more free time, in which I hope to do more for Debian.
I will - as promised above - continue maintaining syslog-ng, and all other packages I currently maintain. Apart from those, I wish to make myself more useful within the Clojure and Hy teams.MiscellaneousWhere to are you moving?
This is something I will answer in due time. For now, I will have two weeks off, which I wish to spend my way, picking up projects I neglected for far too long.
Last week’s autopkgtest 3.5 release (in Debian sid and Ubuntu Utopic) brings several new features which I’d like to announce.Tests that reboot
For testing low-level packages like init or the kernel it is sometimes desirable to reboot the testbed in the middle of a test. For example, I added a new boot_and_services systemd autopkgtest which configures grub to boot with systemd as pid 1, reboots, and then checks that the most important services like lightdm, D-BUS, NetworkManager, and cron come up as expected. (This test will be expanded a lot in the future to cover other areas like the journal, logind, etc.)
In a testbed which supports rebooting (currently only QEMU) your test will now find an “autopkgtest-reboot” command which the test calls with an arbitrary “marker” string. autopkgtest will then reboot the testbed, save/restore any files it needs to (like the tests file tree or previously created artifacts), and then re-run the test with ADT_REBOOT_MARK=mymarker.
The new “Reboot during a test” section in README.package-tests explains this in detail with an example.Implicit test metadata for similar packages
The Debian pkg-perl team recently discussed how to add package tests to the ~ 3.000 Perl packages. For most of these the test metadata looks pretty much the same, so they created a new pkg-perl-autopkgtest package which centralizes the logic. autopkgtest 3.5 now supports an implicit debian/tests/control control file to avoid having to modify several thousand packages with exactly the same file.
An initial run already looked quite promising, 65% of the packages pass their tests. There will be a few iterations to identify common failures and fix those in pkg-perl-autopkgtest and autopkgtestitself now.
There is still some discussion about how implicit test control files go together with the DEP-8 specification, as other runners like sadt do not support them yet. Most probably we’ll declare those packages XS-Testsuite: autopkgtest-pkg-perl instead of the usual autopkgtest.
In the same vein, Debian’s Ruby maintainer (Antonio Terceiro) added implicit test control support for Ruby packages. We haven’t done a mass test run with those yet, but their structure will probably look very similar.
Dru(pal)sh(ell) is an essential tool if you are working with Drupal intensively. If you don't know it yet, Drush is command line shell and scripting interface for Drupal. It helps you to quickly perform various administation and maintenance tasks using only a terminal. If you are not convinced, you should probably install it and give it a try. You won't regret it. It's awesome and will save you headaches, time and again more time. If you are using Drush, you must have been using the command "drush cc all" like a million time. I have. But Drush can do much more.Read More...