Elsewhere

Hook 42: Hook 42 + NYC Camp + The UN = All Multilingual, All The Time

Planet Drupal - mar, 14/07/2015 - 10:08
Tuesday, July 14, 2015

We are excited to be headed to NYC Camp this week! We are ready to rock the UN with our sessions and trainings... all capped off with a Drupal 8 Multilingual (D8MI) Sprint.

Multilingual Drupal Sessions

Both Aimee & Kristen will be presenting sessions - one for Drupal 7 & one for Drupal 8:

Multilingual Drupal Trainings

In addition to our sessions, we will be hosting TWO hands-on trainings:

  • Drupal 7: On Friday, July 17th from 9AM to 1PM, we will be running a shorter version of our D7 hands-on multilingual training. This is similar to the one we ran at BADCamp in 2014. Also, if you want even more Drupal 7 multilingual training, check out Lingotek's all day training on Thursday, July 16th as well.
     
  • Drupal 8: We will also do our Hands-On Multilingual Training for Drupal 8 on Friday, July 17th from 2PM to 5PM. If you join us after the Drupal 7 training, you will really see a world of difference between creating multilingual sites and D7 and D8.
Multilingual Drupal Sprinting

At the end of the week, on Sunday July 19th, we are hosting a Drupal 8 Multilingual Initiative (D8MI) Sprint. Sign up here if you want to come sprint with us!

We can’t wait to see you all there!

 

Hook 42 Topics:
Catégories: Elsewhere

BlackMesh: Sprint Planning Part 1: Planning and executing a focused sprint that helps move an Open Source Project forward

Planet Drupal - mar, 14/07/2015 - 08:52
Intro

This blog is based on a transcript of a talk given by Cathy Theys (YesCT) and Peter Wolanin (pwolanin) at DrupalCon Los Angeles Planning and executing a sprint that actually helps move an Open Source Project forward. There is a video and the slides are also available. This blog has been edited and is not an exact transcript, but it has a conversational tone since that is the origin.

This blog is part 1 of a 3 part series about different types of sprints, with different purposes. Part 1 is about a small focused sprint. Part 2 will be about small local general sprints. Part 3 will be about giant DrupalCon-like sprints with a mentoring focus.

Types of sprints: focused

A sprint is a focused effort for a short period of time.

Generally, Drupal sprints last from two to three days up to a week.
Photo credit: Pedro Lozano

At the end of DrupalCon, usually on Friday, there is a tradition of having a huge sprint. As time has gone on, this large sprint focused more and more on mentoring new contributors, getting people involved in contributing to Drupal, and celebrating people who are making contributions for the first time. Big sprints, like those at DrupalCon, provide a good opportunity for a lot of people to come together. Besides the large sprint, there are also smaller groups doing focused sprinting, but often, they do not have enough time to achieve larger goals.

What we want to talk about is a focused sprint. This is where you have a small group of people (that will fit in one room) who meet for two, three, four, or five days, working together to try to get some things done.

Background: Drupal 8 release plans

A lot of focused sprints have been organized around the Drupal 8 release cycle to try to knock the number of open critical (release blocking) issues down to zero, because we need to get to zero so we can get a release candidate.

What you might see if you look at these images in detail is that when we get to a release candidate, we actually expect to find more criticals to work on.

It is important to not only look at critical issues, but also at the things that people rated “high” as bugs. Oftentimes, if you start digging into a highly-rated bug that is not critical, you will discover it is critical.

Conversely, you might look into a critical and discover that it is not so bad; it is not going to severely impact the release. We could get back to it later, and it could be downgraded and stop blocking the release.

Addressing both of these categories of bugs is important at focused sprints.

Basics

When you organize the event, make sure these are checkboxes that you have in your planning phase.

Venue/Facilities Venue

The most important thing to have is a good venue and everything that goes with it in terms of facilities. During a focused sprint, you want to keep people watered and fed.

Dedicated Space


Photo credit: Phase2 cropped cc

This means having a dedicated space to make this kind of event successful.

Do not try to do it in a coffee shop or any place where there will be distractions, such as people walking through.

If necessary, you might have to pay for the space, which can be a good use of resources for making the event a success.

Electricity


Photo credit: Karl Baron cropped cc

Power strips!

Tables


Photo credit: Kristen Pol cc

Provide tables and chairs so people can be comfortable. They need to be able to face each other, have conversations, and move the chairs around as their needs change during the day. If possible, consider whether the tables and chairs have good ergonomics for computer work, and if there can be some standing desk space.

Drinks


Photo credit: Phase2 cropped cc

Beverages, coffee. A common complaint is coffee service being cut short.

Make sure you have beverage options. Either provide beverages to the sprinters or have someplace available for them to get beverages.

If you are serving beer or wine later in the day, make sure you also get some good quality non-alcoholic beverages so people do not feel excluded if they do not want to drink alcohol.

Natural Light


Photo credit: Tamás Szügyi cropped cc

Natural light. I want natural light! I want to recover from my jet lag because I might have traveled from a distant place. I want to be able to get a sense of how the day is going, and what the weather is like outside. I want to stay awake. Natural light helps. So, instead of a basement cave, pick a space for the sprint that has natural light.

Writing boards


Photo credit: Phase2 cropped cc

You should have writing boards, whiteboards, or something that people can collaboratively scribble on. Collaborative whiteboarding moments can actually be the most productive moments in the entire sprint, so make sure that you have made some facility for that. Do not leave that up to chance.

Climate control


Photo credit: Frédéric Marand cc

As with natural light, natural air can be very useful for keeping people awake. Make sure that the space is going to be comfortable, and people are not going to be sweating or freezing.

Parking


Photo credit: Daniel Oines cc

If you are organizing an event, parking can be important for people coming and going during the day. Do not make them walk a mile if they had to drive there. Make the parking options clear and include information about parking costs.

Internet


Photo credit: Alexander Baxevanis cc

The thing that is obvious - but we will just say it - we need Internet.

Wi-Fi is convenient.

You should also have a wired back up.

Spend time checking out the venue beforehand to make sure that the bandwidth will hold up to even a dozen people doing hard core work.

Contact freenode if you are going to have a fairly large event because freenode will sometimes block people if there are too many connections to IRC from one IP address.

Drupal projects can have automatic tests that run every time a code change is proposed on an issue. The Drupal Core test suite can take 15-45 mintutes to run, and sometimes there can be a queue of issues waiting to have the tests run on a patch.

Make contact with Drupal Association infrastructure team ahead of time so you know who to reach out to in case testbots get backed up, so that sprint participants are not sitting around all day waiting to see if their patch passed the tests.

Food


Photo credit: Mads Danquah cropped cc

Food is important. Bringing food into the venue is convenient for people who want to keep working.

Deconstructed food, or "assemble your own sandwich, salad, or something," is a great option because it lets everyone meet their own needs. Also, you do not have to have separate lines or separate things prepared ahead of time for the vegans, the vegetarians, and the paleos - whoever they are.

It is helpful if the sprint is in a location where people can go out and quickly get dinner and come back, so they do not feel like once they have left the sprint that it is too much trouble to return.

Convenience and quality matters

A lot of the people who are at sprints are there on their own time. We want to respect them as people, and what they are offering, and what they have had to go through to get there. So, it really matters that things like sprint location and food are convenient and high quality.

Community building


Photo credit: xjm cropped

It helps to do some super fun things at events and between events to keep people communicating and working really well together.

Having colorful post-its for issues on poster boards or chalkboards, helps organize things and also is fun.

We have all different fun of ways of identifying people at sprints. We have used T-shirts or leis more mentors, and bunny ears for people working on criticals.

People travel from far away and we have a tradition of bringing chocolates from your home country and sharing them with the other people at the sprint. It reinforces the differences and similarities that we all have. When we come together it is nice and fun.

We do not work all day. Integrating something from the local area into the sprint provides a good break. Being able to go out for dinner and come back, is a nice break, yet keeps everyone together. The conversations that we have when we are not tied to our computer screens can be really brilliant.

Looking back

So far, we covered the basics. A lot of what we are recommending have been things that have worked for us in recent sprints, like Drupal Dev Days, the New Jersey sprint, Drupal Cons, etc.

Next, we are going to talk about things that people might not know. But we hope once you read them you will say, “Oh I didn't know that you did that when you were planning a sprint, but that really makes sense. I'm going to do that too.”

Things you may not know (about sprint scheduling and logistics) Catalysts

How the heck do sprints come about? Is it just a calendar thing and a meet-up and then people show up? No!

A person + burning interest

Somebody has to have the idea to have a sprint and the catalysts are usually that someone has this overwhelming burning desire to get a particular thing done that is bothering them. They are thinking of it all the time, and they are thinking, "We really need to address this."

Maintainer aware of gaps

Maintainers or release managers will be aware of gaps in the current work that is being done. They may say, “We are doing really well on some issues, but nobody is looking at this other set of issues.”

The topic of the sprint could be something that you want to use the "getting together in the same physical space" to accomplish. It might be a problem that is really vaguely defined, or super scary, and is not moving forward organically on its own.

Funding

Another trigger for holding a sprint can be that funding is available, either through local companies, sponsors, or through D8 Accelerate. Sprint organizers will often use that funding for plane tickets to bring people in, provide them a convenient place to stay, and pay for food at the sprint.

Planning and Preparation is Key

The more planning we do, the better the event is going to come off.

Identify a broad topic and specific goals

Identify a topic area before the sprint. Saying, “Hey let's work on Drupal 8,” is not clear enough. It is important to focus on a specific area and identify distinct goals within that area.

Triage issues ahead of time

Look at the issues and triage them. Make sure that the issue summaries are up-to-date. Relate issues together to provide context. Identify which issues are blocking other issues. Doing this work ahead of time within that special focus is going to make the sprint much more effective when people arrive to do work.

Committer communication helps

It helps during the planning to have contact with a committer to your project. You can get advance buy in from a committer like, “Hey, we were thinking of having a sprint on ‘special focus.’ Do you think that is a good idea?”

The committer can provide guidance to make sure you are going in the right direction.

When you talk to the committer during the planning process ask them if they are available to attend, and which days. Or, if they might be available to attend remotely. When you are working really fast (because you have all these people gathered together) and you have issues that are blocking other issues, having responsive committers is amazing and allows you to keep up the momentum at the sprint.

With Drupal 8, we are really lucky because we have committers that are responsive. Our RTBC queue (list of issues that are "reviewed and tested by the community") is under control most of the time, but all the committers are paying attention to it.

Committers can make a powerful difference at a focused sprint, so touch base with them and let them know what is happening in advance. Having a committer's participation can be a big advantage, but is not a requirement, and the importance depends on the nature of the sprint.

Example timeline Six weeks out

Far in advance we can do things like: advance planning, defining focus, and identifying and inviting attendees.

Three weeks out

Closer to the sprint, doing hangouts with the technical lead and maybe a maintainer or somebody else who is project managing the sprint to make sure things are going well.

One week out

Do another check in. Have some initial debates about the issues like, “Is this really blocking this? What is this really about? I do not understand this thing.” Get that done ahead of time before you have all these people arrive.

Get one or two domain experts involved. If they can work a few days in advance, especially when there is a blocking issue that will unblock all these other things, that can really help out a sprint.

Hours of planning

Planning takes time. The sprint organizers are going to be doing much of the volunteering and logistical planning. If it's four people getting together and talking over the course of several meetings ... adds up a lot of hours!

Doing some of the initial work on the blocking issues could be another four people working 10 hours in advance of the sprint.

Funding

While planning, work on your funding. Check on grant applications. If your sprint is happening at a Drupal camp you might be using some of the camp money.

Providing scholarships to key attendees can be a valuable use of resources. Help make arrangements, like hotels and airplane tickets, for people who are going to fly in.

At the sprint

Here are five things you can do at the sprint to make it effective.

Communicate: Track key issues

Keep track of the issues that are within the scope of the project and their status in a way where everybody can see it. Boards on the wall work really well for that. Keep track of which is blocking which. Keep track of who is working on them. You can have more than one person working on the same issue. Keep track of what still remains on the issue that needs to be done.

Communicate: Make sure updates get posted on the issue

Any work that gets done at the sprint also needs to be posted back up on the issue. This is good for documenting how the issue evolves over the days, and useful for communicating with people who are remote. Even though your sprint is local, there are people all over the world paying attention to the issues you are working on. We do not want to keep the developments on an issue secret from them.

We want to have good communication with everyone because when we go to sleep, another part of the world wakes up, and they can work on things. Later, when we wake up, we can make more progress. This will not happen if we do not post updates in public on the issues. A good time to do this is right before you break for a meal. Right before lunch, upload your broken things and make a comment like, “I wasn't sure about this and maybe this… Coming back to this later.” Do this whenever you are just stopping work for a while. Your future self will thank you because you will have forgotten what you were thinking then. Overall, this is good for communicating with the world, and also yourself.

Communicate: Check-ins during the day

Even during a small sprint, there is going to be a lot of different things happening. We want to be communicating really well throughout the day and checking in with the different people, working on different issues, asking them what is blocking them, what do they need and then trying to get them their help.

Sometimes people who are working get a little too "heads down" trying to solve things themselves. A little bit of help from outside can help speed up what they are doing.

We also want to check on the testbots and make sure that the tests are running okay.

Communicate: Take pictures

Documenting the sprint is great because usually sprints are energizing, fun, and productive. People who are there want to look back on that and say, “Yes, that was awesome when we did that. I remember when we did that. That was so great!”

Not everyone will want their picture taken. Be respectful of their wishes. Announce when you are taking pictures and let people know you intend to share them online.

Pictures are also good for communicating with other people outside the sprint because somebody could be listening to the chatter about the sprint. When they see pictures, they will know what a sprint is like. That makes them less afraid to attend one in the future. You are not taking pictures to get people to come to your current event. You are taking pictures so that you might get people coming to your next sprint.

Communicate: Daily update

At the end of each day, it is helpful to have one person write a summary of the day. “This is all the stuff we got done,” “These things still need to be done,” and “We are really unsure about this.” Post the summary online for everyone to reference. This makes compiling a final report of activities at the end of the sprint much easier. It also keeps attendees up to speed, because if I am working on one thing, I may not know what other people are doing.

When we write things down like that, it allows us to celebrate the successes that we have had. We tend to focus on is what is broken and what we need to do next, so it is really good for us to see all of our accomplishments.

Follow-up, after the sprint Publish a summary

After the event, we want to communicate what happened. This is sometimes required depending upon your funding. It might be required by a grant, or if a company gave you money, they may have done so in exchange for you writing a blog about the event.

A couple examples of recap posts are the Portsmouth NH theme system critical sprint recap and the Princeton Critical Sprint Recap.

Write-ups like these enrich the community's knowledge and help transfer your experience to future sprints. Summary write-ups are really good investment. Be sure to take notes!

Check on issues that got close but not committed

After the sprint, there is still more work to be done. This work can be really effective and a significant part of what happens to move issues forward.

Check on issues that got really close but are not yet committed. See what is blocking them and just nudge them along and finish that off. Because you invested so much work at the sprint, you want it to pay off.

D8 Accelerate

The D8 Accelerate program is a great example of how the Drupal Association is trying to push Drupal 8 forward. The last few months of development before a release candidate are the hardest because the problems are no longer fun. The problems are difficult. D8 Accelerate provides the sort of impetus and ability to hold these sprints. These events are to push forward those issues that are not getting solved organically. It is going to get Drupal 8 done much faster than it would otherwise.

https://www.crowdrise.com/d8accelerate to donate. And, if you think about organizing one of these sprints, you should definitely apply for a grant. For the New Jersey sprint we applied almost as soon as the program was opened. We got one of the first grants (which was very exciting). It also gave us avenues directly to people like Angie Byron, who is a committer. Angie got involved and helped us on a daily basis to move the issues we worked on toward being committed to the project.

Make it even more effective Initialize, with specific people

Focus on getting specific people to your sprint. Even before you pick a date, you need reach out to sprinters. Adjust the dates of the event to accommodate the sprinters, if needed. Make a list of people you must have at the event and make the entire event conditional on those people rather than defining an event and hoping that they will show up. If you get some of those people to confirm, their attendance will encourage additional participants to come.

Once you have gotten some of these people confirm, publish their names. Make sure that they are okay with you saying they committed to come on these days. Sprint organizers can then tell potential attendees they will get to work with someone who is an exciting person to be in the room with, someone who can get a lot done. These people are the key, rather than the date of your event.

Committer/Maintainer Communication

With a Contrib project you can reach out directly to the Contrib maintainer. For Core, get in touch with one of the Core committers, or ideally a couple of them since they may have gaps in their coverage. If at all possible, get them to attend.

Going to events like Dev Days is great because you usually get two or three committers in the room. It is amazing how fast things get done when you are sitting next to a committer. You will say, "That is ready to go. It is blocking this other issue," and after a careful review they will commit it to Core. Then, you can move on to the issue that was blocked. You do not have to wait for them to notice that a blocking issue is in the RTBC queue.

The challenge is to recruit people that have a working relationship with the committers, or the Contrib project lead. Ideally, recruit the Contrib project lead to your sprint, someone they worked with before, or someone who has a good relationship with one or more of the Core committers.

When you have an open communication channel with a committer, before a sprint it will improve the chances of the sprint being successful. And, during a sprint, it will reduce the time being blocked while waiting for issues to to be committed when they are ready.

Particular People

Ask particular people.

Say no sometimes.

Also, you need to be prepared to say no to some people.

If you are holding a focused sprint and you have someone who says, “You know what? I’ve heard about this Drupal thing and I want to come and get my machine set up and really help.” You should be prepared to say, “This is not the event for you. I appreciate that you are interested. Here’s another event where you can do that, where you can get set up and get started. This is going to be a focused event and we need everyone to come in already up to speed working on Core.”

Have some generalists

Attendees do not all have to be subject area experts. It is great to have some people there who are generalists, who are going to work on issues as needed. They are going to work on the issue summaries with the goal of understanding how the whole process works.

People should be familiar with contributing

Everyone at the sprint should be up to speed on day one. You do not want to get distracted trying to help people debug their local LAMP stack.

Example

At the New Jersey sprint, two or three people were generalists out of about 10. That was a good mix because those people could pick up a lot of the smaller issues, move patches forward, and fix things that were in need of fixing without having to have a deep background. The people with the deep background would get a basic fix in place and move between issues, moving them forward. Other people jumped in and dealt with additional things, such as writing tests.

Writing automated tests or performing manual testing is often the most important part of getting a patch right. You do not have to be the deep subject matter expert to understand what is supposed to happen, and how to write a test to test it.

Focus means not mixing in new contributor instruction

If people are going to need help with the contribution process, you should probably divert them to a different sprint event.

Participants need to trust the time will be productive

In order to make one of these events successful, you are targeting these key participants and they need to trust you as the event organizer that their time is not going to be wasted. It might feel like we are talking about a lot of time invested upfront to get the sprint planned well. For example, at least four people probably nine hours, or more, each the few weeks beforehand plus hours working on the issues before the sprint happens. This work is essential so that the people who participate feel that they are going to have a very productive time at the sprint, because all the groundwork has been laid for them.

Organization yields success

If you are organizing one of these sprints, it is not just the logistics. All this pre-planning, issue triaging, and communication ahead of time, laying the groundwork for accomplishments that we can celebrate at the end of the sprint, is what is going to make it successful.

Project Management

Project management is an area where we have felt real gaps at some of the most recent sprints. We did not have someone whose sole role was to be a project manager. We end up assigning this role to someone who was also a subject expert, or a committer. That person spends a lot of their time managing the sprint, managing issues, and keeping track of things writing summaries. This often means that one person is double-burdened, and gets burned out by the end of the sprint.

This is an area where we could use help from project managers or people with that kind of skillset. People who might not be interested in writing patches, but are willing to attend sprint planning meetings and the sprint to help keep the issues on track.

There may be people who would be willing to participate as a project manager at sprints, but they do not know that they are needed, or how to get involved. For a project manager to be effective at a focused sprint, they would need experience similar to other participants, like how issue queues function and their own experience doing project management in the issue queue of the project being sprinted on.

For Drupal Core specifically, experience would mean: contributing in the Core issue queue, (which includes valueable work other than making patches). And, also includes familiarity with the release cycle, policies like upgrade path and governance (which are posted in the groups.drupal.org Core group), and core gates.

Project managers can gain this issue queue experience by shadowing an organizer at a focused sprint, attending sprints with a mentoring focus, attending core mentoring office hours, and reaching out to other contributors asking how they can get involved.

The Human Element

The human element in all these Drupal events - the Drupal community - is essential. You have a lot of volunteers giving their time, so do not make them bitter, burned out, and sad. Do not ask people to volunteer and also to pay for the event. Do not be afraid to go out looking for sponsors and ask for money. Allow people to have their own lives. If they need to show up at 10:00 AM and leave at 5:00 PM, even if the rest of you are working all evening, that is okay. Let them have their family life. Let them do what they need to do. Step back and recognize that any contribution you get is valuable and should be appreciated.

Lingering and Continuing Tasks

The follow-up at the end of the sprint can be more important than what happens at the sprint. Being in the room together with that group of people allows you to form a consensus. That consensus, that plan can form the basis of work that goes on for months afterwards.

You want to motivate people. They need to feel good about what happened in the sprint, so that they continue to volunteer their time, their own free time after the sprint. We keep moving the issues forward that got started at the sprint but did not get finished.

For example, Peter went to Dev Days in Hungary and sat down with Daniel Wehner to come up with a plan to rewrite an entire Core subsystem. We came up with a plan and it took us from March until late July to finish the work on this subsystem. At the sprint, we had the first idea. We came to consensus. It took us that long to actually execute the plan, but without being together in the same room at that sprint, we would never have formulated it, or have come to a consensus which formed the next few months of work.

Comparing a focused sprint to other types of sprints

Some of the aspects of a focused sprint are similar to the giant sprints that we do.

Resources for sprint planners: How to plan a sprint is where we document sprint-related advice and tips. For example, you will find estimates for network and bandwidth needs. You should plan on enough access points that have capacity for two and a half devices per person. You want the bandwidth limits per device. It should be no less than 10 megabits per person. For a sprint of about 100 people, you want 60 to 80 megabits down and 20 megabits up. That will handle 300 to 400 devices. Depending on the size, you can scale that for what you need.

The document above is a summary of the write-ups that people have done over the years after their sprint events. We were able to take that information and make an official source for other sprint planners to find. This is another reason why documenting your sprint is really important.

A focused sprint means not mixing in mentoring new contributors, if that is not the focus of the sprint. If the attendees need help with setting up their local environment, suggest another event that focuses on new contributors.

If you want to mentor the next generation of sprint participants, then your focus becomes onboarding new contributors. Cathy runs a local monthly sprint, welcoming and focusing on new contributors, and helps organize sprints at DrupalCons that do that.

On the Friday of a DrupalCon, 200 and 300 people who have never contributed to core before are introduced to how to contribute to Drupal Core. This ensures that as an open source project, Drupal remains healthy far into the future. Get Involved events are really important but they are slightly different and they require some different planning and logistics. The goals of the focused sprints that we discussed here are short work, to be completed within 1-2 months.

At the smaller, focused sprints we tend to have a majority of experts and a couple of people who have contributor experience and kind of know what they are doing (but not really). It means that organic mentoring will happen. Unlike formal mentoring, no one is saying, “Go here and watch this presentation and we will teach you things.” It is more like, “Sit down at this table and do whatever we tell you and ask us questions and we will help you help us.” This type of mentoring is much more informal and happens in the Drupal community all the time. We do this because it is ingrained in our culture. It is how we work when we sit down together.

Related references Thanks

Thanks to Peter Wolanin (pwolanin) for collaborating on this great talk and for getting Acquia to get the transcript afterwards. Thanks to Marco DiSandro, Alina Mackenzie (alimac), and Jess (xjm) for helping with editing.

Mistakes are all mine though! Contact me (YesCT on drupal.org) with feedback.

DrupalSprintsDrupal 8
Catégories: Elsewhere

Metal Toad: Why Drupal 8 won't ship with REST content negotiation

Planet Drupal - mar, 14/07/2015 - 04:59
Why Drupal 8 won't ship with REST content negotiation July 13th, 2015 Dylan Tack

Some friends on Twitter were alarmed by this Drupal change record:
Accept header based routing got replaced by a query parameter
Before:
curl /node/1 -H "Accept: application/hal_json"
After:
curl /node/1?_format=hal_json

The issues leading to this change are too lengthy to capture on Twitter, so I'll give my perspective here.

What was the problem with accept-routing?
  1. Most critically, not all CDNs and caches support content negotiation (see #2364011)
  2. A secondary issue that I think deserves more attention is that even when caches support content-negotiation, the cache hit rate suffers.

The poor hit rate arises because web browsers do not simply declare Accept: text/html, they request a bizarre mishmash of media types depending on the specific browser, version, OS, and even what extensions are installed. A quick test on this site discovered roughly 100 unique Accept headers in 24 hours.

But isn't content-negotiation required to have "pure" REST?
  • No. Roy Fielding has said "Neither choice has anything to do with REST" (referring to a debate between extensions or query parameters).
  • While I don't deny the aesthetic appeal of the Accept header, there are good reasons why Drupal often has to de-prioritize theoretical purity. As mikl wrote on #2364011, "Drupal should be engineered for the web we have, rather than the one we wish we had."
Is ?_format a Drupalism?

The special _format Routing Parameter comes from Symfony, so I think this would be more accurately called a Symfony-ism, if it's an -ism at all. However, given that REST is an architectural style, and not a specific protocol, any API we design will naturally contain some details unique to Drupal.

Can't Varnish normalize the wide variety of Accept headers?

Yes, but if custom normalization routines in Varnish were the only way to have a high-performing cache, then that would be a bad Drupal-ism. It's better to have broad compatibility with current CDNs and caches.

Could a contrib module re-enable content negotiation?

Probably. The Symfony route filters are plug-ins that can be swapped out.

What alternatives were considered?

Some other options were moving REST resources to an /api path, or using extensions like /node/1.json. In the end, the query parameter won out because it had the least impact on the existing routing system.

The Future

I think an ideal solution to both problems would be widespread support for the Alternates: header (RFC 2295). In this way a server can specify what alternate media formats, languages, or encodings are available, and content negotiation can be efficiently performed at the network's edge. Sadly, this RFC appears largely abandoned since it's introduction in 1998, so perhaps the best we can hope for is by the time Drupal 9 is ready, CDNs and browsers will have cleaned up their act.

Catégories: Elsewhere

Matthew Palmer: Why DANE isn't going to win

Planet Debian - mar, 14/07/2015 - 02:00

In a comment to my previous post, Daniele asked the entirely reasonable question,

Would you like to comment on why you think that DNSSEC+DANE are not a possible and much better alternative?

Where DANE fails to be a feasible alternative to the current system is that it is not “widely acknowledged to be superior in every possible way”. A weak demonstration of this is that no browser has implemented DANE support, and very few other TLS-using applications have, either. The only thing I use which has DANE support that I’m aware of is Postfix – and SMTP is an application in which the limitations of DANE have far less impact.

My understanding of the limitations of DANE, for large-scale deployment, are enumerated below.

DNS Is Awful

Quoting Google security engineer Adam Langley:

But many (~4% in past tests) of users can’t resolve a TXT record when they can resolve an A record for the same name. In practice, consumer DNS is hijacked by many devices that do a poor job of implementing DNS.

Consider that TXT records are far, far older than TLSA records. It seems likely that TLSA records would fail to be retrieved greater than 4% of the time. Extrapolate to the likely failure rate for lookup of TLSA records would be, and imagine what that would do to the reliability of DANE verification. It would either be completely unworkable, or else would cause a whole new round of “just click through the security error” training. Ugh.

This also impacts DNSSEC itself. Lots of recursive resolvers don’t validate DNSSEC, and some providers mangle DNS responses in some way, which breaks DNSSEC. Since OSes don’t support DNSSEC validation “by default” (for example, by having the name resolution APIs indicate DNSSEC validation status), browsers would essentially have to ship their own validating resolver code.

Some people have concerns around the “single point of control” for DNS records, too. While the “weakest link” nature of the CA model is terribad, there is a significant body of opinion that replacing it with a single, minimally-accountable organisation like ICANN isn’t a great trade.

Finally, performance is also a concern. Having to go out-of-band to retrieve TLSA records delays page generation, and nobody likes slow page loads.

DNSSEC Is Awful

Lots of people don’t like DNSSEC, for all sorts of reasons. While I don’t think it is quite as bad as people make out (I’ve deployed it for most zones I manage, there are some legitimate issues that mean browser vendors aren’t willing to rely on DNSSEC.

1024 bit RSA keys are quite common throughout the DNSSEC system. Getting rid of 1024 bit keys in the PKI has been a long-running effort; doing the same for DNSSEC is likely to take quite a while. Yes, rapid rotation is possible, by splitting key-signing and zone-signing (a good design choice), but since it can’t be enforced, it’s entirely likely that long-lived 1024 bit keys for signing DNSSEC zones is the rule, rather than exception.

DNS Providers are Awful

While we all poke fun at CAs who get compromised, consider how often someone’s DNS control panel gets compromised. Now ponder the fact that, if DANE is supported, TLSA records can be manipulated in that DNS control panel. Those records would then automatically be DNSSEC signed by the DNS provider and served up to anyone who comes along. Ouch.

In theory, of course, you should choose a suitably secure DNS provider, to prevent this problem. Given that there are regular hijackings of high-profile domains (which, presumably, the owners of those domains would also want to prevent), there is something in the DNS service provider market which prevents optimal consumer behaviour. Market for lemons, perchance?

Conclusion

None of these problems are unsolvable, although none are trivial. I like DANE as a concept, and I’d really, really like to see it succeed. However, the problems I’ve listed above are all reasonable objections, made by people who have their hands in browser codebases, and so unless they’re fixed, I don’t see that anyone’s going to be able to rely on DANE on the Internet for a long, long time to come.

Catégories: Elsewhere

Modules Unraveled: Modules Unraveled is now Completely FREE!

Planet Drupal - mar, 14/07/2015 - 00:30
Published: Mon, 07/13/15Download this episode

Hey everyone,

Super exciting news this week! I've secured sponsors for the next two months to provide EVERY video on ModulesUnraveled.com absolutely FREE for you!

It's a bit of a long story, so if you don't care, just go learn some Drupal. But, I thought you might be interested in the back story, so here goes...

(P.S. If you're not a reader, I recorded this as an 8 minute podcast just for you.)

Why Modules Unraveled is now FREE for everyone

Late last year, there was a moment when I realized that it had been a long time since I had thought about why I started Modules Unraveled in the first place, and whether or not I was still on course with that original vision. I decided that I wasn't.

For reference, Modules Unraveled started with a video demonstrating how to setup Organic Groups in Drupal 7, back in 2011, when Amitai took over development, and did a complete re-write. Nothing was the same, and there were support requests all over the internet from people who didn't know how to use the new version.

I wanted to use it in a project I was starting at the time, so I went through the twisted, and difficult process of figuring out how the new module was supposed to be used. When I finally did, I recorded a video showing exactly what I had learned, so that others could skip the hours (and let's be honest, days!) that I had spent figuring it out, and just use the module the way it was intended.

Basically, I wanted to help everyone use Drupal to do amazing things.

At the time, I was teaching in the public schools full-time, but had the desire to do more web development and create videos like the one for Organic Groups. So, I started getting up at 3am... yes. 3:00 in the morning... and during that time I worked on videos until 6am when I would get ready to go to my full-time job.

Then, I started to charge for some videos. I figured, if I was saving people time, it was worth the $29 investment to learn how to use something like the Simplenews module, which has its own complexities. People apparently agreed with me, because the orders started coming in. Then I created more series' and put those up for sale, and everything was on an upward trajectory.

In the spring of 2012, I looked at what I was making between the hours of 3:00 and 6:00 in the morning, and extrapolated that to see what I could make full time. Based on that, I decided that it would make sense to quit my full-time teaching position, and focus on developing sites, and videos full time. (Too early as it turned out, but I'll explain that later.)

So, I was working for myself, from home, and everything seemed to be going great. The income was incredibly irregular though, so eventually, I switched the site from a pay-per-series model, to a subscription model. That was nice, because it provided a bit more predictable income, but though there were good months, on average, it still hadn't ramped up to what I was making as a full time teacher.

Because of this, I started to focus more and more on the money that I needed to make, instead of providing amazing quality videos that could help thousands of Drupal developers create their sites more quickly, and with less headache, like the original Organic Groups series did.

So, in December of of 2014, when I re-evaluated whether or not I was fulfilling my original mission, the answer was a resounding "No." I saw the thousands and thousands of site visitors in Google Analytics, and the meager handful that were actually signing up as a paying subscriber to access the videos. And the interesting thing is that it wasn't the lack of subscribers that hurt the most, it was that such a broad audience was coming to my site, because I had something they needed, but then immediately leaving because of the subscription requirement.

These were the exact people I had set out to help. And I was turning them away. I had reached a wide audience of people who didn't know what I was saying, because I was charging them to listen.

So, I wasn't making enough on the subscriptions alone to provide for my family, but I kept churning out new videos in the hope that eventually, the snow ball would roll in my direction, but it wasn't happening.

I eventually came to grips with that fact, and started trying to figure out other ways to produce an income, but still help the people that I had originally set out to help. I knew if I just got another job, I'd stop making videos. Because they take time. A LOT of time. You see this evidenced all over the web. YouTube is littered with Drupal tutorials teaching you how to do this or that, but there are rarely more than a handful done by any one individual. And, because video production, and teaching are not generally their areas of expertise, the quality is widely varying (to put it nicely.)

The obvious monetization strategy was advertising. I had never had third party ads on my site, and really didn't like the idea, but I had to try something new, because what I was doing wasn't working. (And one definition of insanity after all, is doing the same thing over and over, expecting a different result. I didn't want to be insane.)

So, I immediately started to contact businesses that I had some form of personal connection with. Some were ones that had products I used, some were ones where I knew someone(s) personally within the business, and others were ones that close friends of mine had personally recommended.

I wanted to see if anyone would be interested in advertising on my site. Some said yes, and some said no (one even suggested buying me outright, but after thorough discussion with my wife, and time in prayer, it didn't align with my life goals.)

The ones that said yes had a hard time nailing down a dollar amount (which is understandable, since I didn't have metrics to give them, having always been subscriber only), and for four or five months, I felt strung along, and didn't know if it was ever going to work out.

Then, I went to DrupalCon in LA. I wasn't planning to go, but then I won a conference ticket from the amazing people at Four Kitchens (thank you again!) and then just had to figure out a way to pay my room and flight. The only way I could convince my wife (who would be left alone with a two year old, and five month old) to let me go, was to convince her that I resolved to make something happen while I was there and that it would be a good investment.

I followed through. To give you an idea, I went to one (1) session the entire week, and spent the rest of my time in the expo hall, and hanging out with people who might be interested in becoming a sponsor (as well as a few old friends, that I don't get to see except at DrupalCons).

This was MUCH more fruitful than my previous, online-only, attempts. The net result was that six sponsors agreed to advertise, and combined, they would replace the existing membership income, and a little more. It wasn't much more, but was enough to let me run a two month trial to see how it would go, since I have absolutely no idea if it will be beneficial to anyone. My hope though, is that it will be beneficial for everyone, and I can sign additional sponsors, and/or charge higher rates.

One of those sponsors let me know that, after reviewing their budget, they would not be able to advertise, but the other five are still on board. You can see them, and (please!) thank them on the "Sponsors" page.

So, here we are! The site is completely free for anyone that wants to learn what I teach, and I get to find out if advertising will work on Modules Unraveled.

I'm happy!

If you want to learn Organic Groups, Search API, Simplenews, Git Basics, or anything else, check out the videos on this site. They're all FREE!

Want to become a sponsor?

I'd be a fool to leave it at that, and not mention that if you're interested in becoming a sponsor of the site, or the podcast, contact me, and I'll get you the information you need.

You MUST be able to legitimately serve my audience, and prove your worth in order to be a sponsor. But, if you meet that criteria, I'd be delighted to talk to you!

Thanks for taking the time to read this. It means a lot to me! And if you have any further questions, please don't hesitate to ask!

-Brian

Tags: planet-drupal
Catégories: Elsewhere

Four Kitchens: Four Kitchens is ready for Drupal 8!

Planet Drupal - lun, 13/07/2015 - 22:36

Acquia has just announced their active support for Drupal 8 on their hosting platform. As Acquia Partners, we’ve been hard at work preparing for the upcoming Drupal 8 release. Four Kitchens will continue to lead and innovate in the Drupal 8 era. In fact, our work in Drupal 8 has already begun - continue reading to learn more!

Drupal News
Catégories: Elsewhere

Bits from Debian: Debian Perl Sprint 2015

Planet Debian - lun, 13/07/2015 - 21:00

The Debian Perl team had its first sprint in May and it was a success: 7 members met in Barcelona the weekend from May 22nd to May 24th to kick off the development around perl for Stretch and to work on QA tasks across the more than 3000 packages that the team maintains.

Even though the participants enjoyed the beautiful weather and the food very much, a good amount of work was also done:

  • 53 bugs were filed or worked on, 31 uploads were accepted.
  • The current practice of patch management (quilt) was discussed and possible alternatives were shown (git-debcherry and git-dpm).
  • Improvements were made in the Debian Perl Tools (dpt) and discussed how to get track of upstream git history and tags.
  • Team's policies, documentation and recurring tasks were reviewed and updated.
  • Perl 5.22 release was prepared and src:perl plans for Stretch were discussed.
  • autopkgtest whitelists were reviewed, new packages added, and IRC notificacions by KGB were discussed.
  • Outstanding migrations were reviewed.
  • Reproducibility issues with POD_MAN_DATE were commented.

The full report was posted to the relevant Debian mailing lists.

The participants would like to thank the Computer Architecture Department of the Universitat Politècnica de Catalunya for hosting us, and all donors to the Debian project who helped to cover a large part of our expenses.

Catégories: Elsewhere

Drupal core announcements: Drupal 8 beta 13 on Wednesday, July 22, 2015

Planet Drupal - lun, 13/07/2015 - 20:07
Start:  2015-07-22 00:00 - 23:30 UTC Online meeting (eg. IRC meeting) Organizers:  xjm catch

The next beta release for Drupal 8 will be beta 13! (Read more about beta releases.) The beta is scheduled for Wednesday, July 22, 2015.

To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on July 22.

Catégories: Elsewhere

Open Source Training: Use Rules to Build Drupal Membership Sites

Planet Drupal - lun, 13/07/2015 - 19:56
We often have OSTraining members who want to build membership sites in Drupal.

There are a variety of ways in which you can control access to your content. We've covered the Content Access and Taxonomy Access modules before.

However, using the Rules module has several advantages for membership sites:

Catégories: Elsewhere

OSTraining: New Video Class: phpMyAdmin

Planet Drupal - lun, 13/07/2015 - 16:06

Here at OSTraining we teach Drupal, Joomla, WordPress and touch on other platforms such as Magento. All of these platforms use MySQL as their default database.

phpMyAdmin is free software written in PHP, intended to handle the administration of MySQL. phpMyAdmin is a very reliable tool when you need to directly access the data in your database.

Catégories: Elsewhere

ThinkDrop Consulting: A Call to Action: Aegir, The Next Generation at NYCCamp 2015

Planet Drupal - lun, 13/07/2015 - 15:42
Aegir Summit & DevOps Camp at NYCcamp 2015

This Thursday starts NYCcamp, which is gearing up to be a huge event.

This year they've expanded even more beyond Drupal to all free & open source technologies.

Most important to us at ThinkDrop is the first ever Aegir Summit. Most of the Aegir maintainers will be there discussing all of the cool things we are doing with it, and where to go from here. For the full schedule and to register, see http://nyccamp.org/summit/aegir-summit.

On Thursday is an Aegir Site Factory training session.  The main Aegir Summit takes place on Friday

Aegir: The Next Generation

This event is going to be a turning point for the Aegir project.  Three of the maintainers, Christopher Gervais, Cameron Eagans, and myself met at DrupalCon Los Angeles over lunch to discuss what to do next with the project.

We all agreed that there are many issues with Aegir as it stands. We saw that containerization was going to be the way to go in the future.  We all agree that Aegir is so monolithic, so complex, and so full of legacy code that it might be easier to just start over using modern tools like symfony, ansible, and docker.

We even agreed that we (might) need a new name.

From this, Cameron wrote up the Aegir NG proposal on hackpad so we could all contribute our ideas.

At the Aegir Summit, we will be having a panel discussion to present these ideas to the community and get feedback on where to go from here.

I urge all of you to attend, or keep tabs from afar.

The Future of Open Source Hosting

We know that many, many people need the promise of Aegir: easily deploy and update sites at scale. We all know that Aegir has many problems with delivering this promise

We know that outside of it's rather die hard fanbase, Aegir is not really well liked because of these problems.

If you are one of those people, I urge you to join the Aegir Next Generation cause.  We are going to fix Aegir for good, and we need your help.

Registration Ends Tomorrow!

Registration for Aegir training ends today, Monday July 13 at midnight ET. Registration for the Aegir Summit ends Tuesday, July 14 at midnight ET.

If you are attending NYCcamp, please register for the Aegir Summit. Even if you can only attend the panel, I promise you, it will be worth it!

Register for Aegir Summit at http://nyccamp.org/summit/aegir-summit.  Register to attend the "Open Agency Site Factory" training at http://nyccamp.org/training/open-agency-site-factory-ops-freedom-aegir

Tags: aegirnyccampdevshopPlanet Drupal
Catégories: Elsewhere

Microserve: Organising a DrupalCamp - Tips and feedback from DrupalCamp Bristol 2015

Planet Drupal - lun, 13/07/2015 - 15:19

As the Chair of the DrupalCamp Bristol Committee, I thought it would be great to share what I took away from organising Bristol's first DrupalCamp. I'm sure there's a few things to be learnt from this, and if not then at least it will make an interesting read!

The Figures

Friday total sales: 74
Friday turnout: 64

Saturday total sales: 132
Saturday turnout: 109

Income (to be finalised): £12,805.00
Expenditure (to be finalised): £11,964.16

I'd be happy to share the figures with any new camp organisers, and answer any questions you might have - simply drop me an email.

A big thank you would also be appropriate at this point to Kris Klinkhammer for all her help at the Drupal Association.

What went well?

The actual camp weekend was fantastic and we received a lot of great feedback. We had picked two amazing venues and a summer date, and luckily for us the weather did not disappoint; we even had lunch served outside!

We were worried at first when we realised we had to choose a different venue for each day, but in the end I think that worked out in our favour. St George's Hall in particular was a fantastic choice as our attendees were delighted to see the event held in such a unique venue, and started the weekend off in very high spirits.


- St Georges Hall: www.stgeorgesbristol.co.uk/venue-info/

A decision I’m glad we made was to introduce a Drinks Sponsor as a tier between Organisational and Gold Sponsors. Their fee was £1,000 which was put directly behind the bar of a superb venue - Goldbrick House - which was directly behind St George’s Hall. This decision had two advantages; not only were we not handling any cash, and therefore not subject to the 10% DA fees, but a bar tab of that size is a great way to ensure that all your attendees carry on late into the evening which creates a great networking opportunity.

At the core of the event we also had a fantastic variety of talks, so a big thank you to each and everyone of them.


- Léonie Watson giving her Saturday keynote on "The metamorphosis of accessibility"

We were also pretty lucky with the committee, since we had a total of 9 people and it meant no need for any other volunteers over the weekend. We used Trello for communication (separating a board for each key area) and had monthly meetings at the Microserve offices to ensure everything was on track.

Little tip: The initial meetings will be long. Get some rules in place, figure out how to make quick decisions, elect a chair early. The first few meetings were twice as long as the others, so get a few Pizza's expensed!

What didn’t go so well?

We had initially attempted to have a sub-event on each day; Training would be held on the Friday within the same venue, and Sprints would be held on the Saturday. Unfortunately we barely sold any Training tickets so we had to cancel this, and although we had a great room for the Sprints, we simply didn’t publicise this enough and therefore it was barely used. We'd have liked to invite more people to sprint by giving them a free ticket, but because the sprints were in the same place as the camp, we had to acknowledge that each person would still be subject to the same "per head" cost - food & drink, t-shirt, merchandise etc - so we didn't do this unfortunately.

I should also thank Circle Interactive who provided us with a great deal on training. Although we weren’t at a financial loss by cancelling it they had put their time into putting something together and they were very understanding when we cancelled.

Where could we improve?

What are the main points I'll be taking into year 2 and what is my advice to anyone approaching their first DrupalCamp?

Take things easy on year one

We thought we had adhered to this rule by not having a Sunday conference day, but we should have also applied this to Training. We do look forward to putting a heavier focus on that next year though!

Don’t think of everything as linear

We didn’t start selling tickets till the website was complete, we didn’t start on the website till we had agreed all the key information and we didn’t promote to speakers and sponsors till we had all details. In hindsight we could have taken a much less linear approach, which would have boosted sales early and got our speakers and sponsors on-board faster.

There's a couple of points I should empahsise on the back of this one: 

  1. 8 months planning will suddenly catch up with you when you're 2 months away from the event and the ticket sales aren't what you expected. It really is important to not feel too comfortable in the early stages, and to get tickets and speaker requests out early.
  2. DrupalCamp already has a name for itself, so early bird tickets will sell regardless. We could have tweeted about early bird tickets before we even had the venues or any detail sorted; as long as the date is confirmed there'll be an audience who are happy to snap the tickets up without knowing the finer details!
Improve communication groups

We had email groups so everyone received everything (such as contact form submissions and EventBrite queries), yet it wasn’t always clear whose job it was to reply to certain things. One example here is sessions submissions which arrived via the website; it took a few weeks before somebody stepped up to manage this and confirm all the submissions, which really was hassle we could have avoided. As soon as someone offers to talk, get it confirmed asap!

Pass responsibility on better throughout the process

It was good that all the team found sponsors and speakers, but we continued communication this way instead of passing communications on to the appropriate team member. If we were chasing payments, logos, or session info for example, we would ask the connected individual to do it as opposed to the person whose role it was to look after sponsors or speakers.

Accept you will use discount codes, and put these into your marketing strategy

Admittedly this is the one thing I completely overlooked, as we had only thought about early bird Saturday tickets. We ended up creating a variety of discount codes which didn't really follow any plan, and became a little bit messy. We sent out camp specific discount codes to Brighton and London which was a nice gesture, but in the final month when we felt numbers were lagging a bit for the business day we ended up giving our speakers and sponsors heavily discounted ticket codes to pass on to other team members and friends. Although this worked to an extent, it didn't follow any structure and we ended up having a couple of refund requests from attendees who purchased full price tickets and felt a bit hard done by.

Sessions and Speakers

Not surprisingly we had a great variety of feedback on this, both positive and negative. We also asked "What topics / speakers would you like to see at a future DrupalCamp?" so we now have some great feedback to help shape our next camp.

From an organisers point of view one of the largest problems we faced was a lack of gender diversity amongst speakers. I should clarify that although we were lucky enough to secure Léonie Watson for the Saturday keynote, there wasn't a single session submitted by a female speaker, which was really a shame. 

I could probably write a whole post covering this area, so I'll go into more detail on how we are trying to be more inclusive for DC Bristol 2016 in another blog post at a later date.

How did you think it went?

We want to thank each and every person who attended the event, and we'd also like to ask for your feedback in order to make next year bigger and better.

We have a link to a survey hosted on Survey Monkey here. We would very much appreciate it if you could give us your feedback!


- People enjoying lunch outside in the sun


- The DCB 2015 Committee (minus Jon Hadley)

Rick Donohoe
Catégories: Elsewhere

Dries Buytaert: Acquia announces it is ready for Drupal 8

Planet Drupal - lun, 13/07/2015 - 15:02

I'm excited to announce that starting today, Acquia is announcing we're ready to fully support our customers with Drupal 8. This means our professional services, our support, our product engineering, our cloud services … the entire company is ready to help anyone with Drupal 8 starting today.

While Drupal 8 is not yet released (as it has always been said, Drupal 8 will be "ready when it's ready"), the list of release blockers is dwindling ever closer to zero, and a beta-to-beta upgrade path will soon be provided in core. These factors, along with Acquia's amazing team of more than 150 Drupal experts (including a dedicated Drupal 8 engineering team that has contributed to fixing more than 1,200 Drupal 8 issues), gives us full confidence that we can make our customers successful with Drupal 8 starting today.

In the process of working with customers on their Drupal 8 projects, we will contribute Drupal 8 core patches, port modules, help improve Drupal 8's performance and more.

I'm excited about this milestone, as Drupal 8 will be a truly ground-breaking release. I'm most excited about the architectural enhancements that strongly position Drupal 8 for what I've called the Big reverse of the Web. For the web to reach its full potential, it will go through a massive re-platforming. From Flipboard to the upcoming release of Apple News, it's clear that the web is advancing into the “post-browser” era, where more and more content is "pushed" to you by smart aggregators. In this world, the traditional end-point of the browser and website become less relevant, requiring a new approach that increases the importance of structured content, metadata and advanced caching. With Drupal 8, we've built an API-driven architecture that is well suited to this new “content as a service” approach, and Drupal 8 is ahead of competitive offerings that still treat content as pages. Check out my DrupalCon Los Angeles keynote for more details.

Catégories: Elsewhere

Annertech: Integration patterns for connecting your website with your CRM

Planet Drupal - lun, 13/07/2015 - 14:26
Integration patterns for connecting your website with your CRM

Previously we wrote about connecting your website with external systems, and specifically, the benefits of connecting your site with your CRM . As with many problems, there are many ways to approach this.

Catégories: Elsewhere

Lunar: Reproducible builds: week 11 in Stretch cycle

Planet Debian - lun, 13/07/2015 - 00:23
Debian is undertaking a huge effort to develop a reproducible builds system. I'd like to thank you for that. This could be Debian's most important project, with how badly computer security has been going.

— PerniciousPunk in Reddit's Ask me anything! to Neil McGovern, DPL.

What happened in the reproducible builds effort this week:

Toolchain fixes

More tools are getting patched to use the value of the SOURCE_DATE_EPOCH environment variable as the current time:

In the “reproducible” experimental toolchain which have been uploaded:

Johannes Schauer followed up on making sbuild build path deterministic with several ideas.

Packages fixed

The following 311 packages became reproducible due to changes in their build dependencies : 4ti2, alot, angband, appstream-glib, argvalidate, armada-backlight, ascii, ask, astroquery, atheist, aubio, autorevision, awesome-extra, bibtool, boot-info-script, bpython, brian, btrfs-tools, bugs-everywhere, capnproto, cbm, ccfits, cddlib, cflow, cfourcc, cgit, chaussette, checkbox-ng, cinnamon-settings-daemon, clfswm, clipper, compton, cppcheck, crmsh, cupt, cutechess, d-itg, dahdi-tools, dapl, darnwdl, dbusada, debian-security-support, debomatic, dime, dipy, dnsruby, doctrine, drmips, dsc-statistics, dune-common, dune-istl, dune-localfunctions, easytag, ent, epr-api, esajpip, eyed3, fastjet, fatresize, fflas-ffpack, flann, flex, flint, fltk1.3, fonts-dustin, fonts-play, fonts-uralic, freecontact, freedoom, gap-guava, gap-scscp, genometools, geogebra, git-reintegrate, git-remote-bzr, git-remote-hg, gitmagic, givaro, gnash, gocr, gorm.app, gprbuild, grapefruit, greed, gtkspellmm, gummiboot, gyp, heat-cfntools, herold, htp, httpfs2, i3status, imagetooth, imapcopy, imaprowl, irker, jansson, jmapviewer, jsdoc-toolkit, jwm, katarakt, khronos-opencl-man, khronos-opengl-man4, lastpass-cli, lava-coordinator, lava-tool, lavapdu, letterize, lhapdf, libam7xxx, libburn, libccrtp, libclaw, libcommoncpp2, libdaemon, libdbusmenu-qt, libdc0, libevhtp, libexosip2, libfreenect, libgwenhywfar, libhmsbeagle, libitpp, libldm, libmodbus, libmtp, libmwaw, libnfo, libpam-abl, libphysfs, libplayer, libqb, libsecret, libserial, libsidplayfp, libtime-y2038-perl, libxr, lift, linbox, linthesia, livestreamer, lizardfs, lmdb, log4c, logbook, lrslib, lvtk, m-tx, mailman-api, matroxset, miniupnpd, mknbi, monkeysign, mpi4py, mpmath, mpqc, mpris-remote, musicbrainzngs, network-manager, nifticlib, obfsproxy, ogre-1.9, opal, openchange, opensc, packaging-tutorial, padevchooser, pajeng, paprefs, pavumeter, pcl, pdmenu, pepper, perroquet, pgrouting, pixz, pngcheck, po4a, powerline, probabel, profitbricks-client, prosody, pstreams, pyacidobasic, pyepr, pymilter, pytest, python-amqp, python-apt, python-carrot, python-django, python-ethtool, python-mock, python-odf, python-pathtools, python-pskc, python-psutil, python-pypump, python-repoze.tm2, python-repoze.what, qdjango, qpid-proton, qsapecng, radare2, reclass, repsnapper, resource-agents, rgain, rttool, ruby-aggregate, ruby-albino, ruby-archive-tar-minitar, ruby-bcat, ruby-blankslate, ruby-coffee-script, ruby-colored, ruby-dbd-mysql, ruby-dbd-odbc, ruby-dbd-pg, ruby-dbd-sqlite3, ruby-dbi, ruby-dirty-memoize, ruby-encryptor, ruby-erubis, ruby-fast-xs, ruby-fusefs, ruby-gd, ruby-git, ruby-globalhotkeys, ruby-god, ruby-hike, ruby-hmac, ruby-integration, ruby-jnunemaker-matchy, ruby-memoize, ruby-merb-core, ruby-merb-haml, ruby-merb-helpers, ruby-metaid, ruby-mina, ruby-net-irc, ruby-net-netrc, ruby-odbc, ruby-ole, ruby-packet, ruby-parseconfig, ruby-platform, ruby-plist, ruby-popen4, ruby-rchardet, ruby-romkan, ruby-ronn, ruby-rubyforge, ruby-rubytorrent, ruby-samuel, ruby-shoulda-matchers, ruby-sourcify, ruby-test-spec, ruby-validatable, ruby-wirble, ruby-xml-simple, ruby-zoom, rumor, rurple-ng, ryu, sam2p, scikit-learn, serd, shellex, shorewall-doc, shunit2, simbody, simplejson, smcroute, soqt, sord, spacezero, spamassassin-heatu, spamprobe, sphinxcontrib-youtube, splitpatch, sratom, stompserver, syncevolution, tgt, ticgit, tinyproxy, tor, tox, transmissionrpc, tweeper, udpcast, units-filter, viennacl, visp, vite, vmfs-tools, waffle, waitress, wavtool-pl, webkit2pdf, wfmath, wit, wreport, x11proto-input, xbae, xdg-utils, xdotool, xsystem35, yapsy, yaz.

Please note that some packages in the above list are falsely reproducible. In the experimental toolchain, debhelper exported TZ=UTC and this made packages capturing the current date (without the time) reproducible in the current test environment.

The following packages became reproducible after getting fixed:

Ben Hutchings upstreamed several patches to fix Linux reproducibility issues which were quickly merged.

Some uploads fixed some reproducibility issues but not all of them:

Uploads that should fix packages not in main:

  • fglrx-driver/1:15.7-1 uploaded by Patrick Matthäi, fixed by Andreas Beckmann.
  • pycuda/2015.1.2-1 uploaded by Tomasz Rybak, patch by Juan Picca.

Patches submitted which have not made their way to the archive yet:

  • #787675 on ricochet by Daniel Kahn Gillmor: use the debian/changelog date in the manpage.
  • #791648 on fish by Chris Lamb: sort header files in documentation.
  • #791691 on fritzing by Chris Lamb: sort the documentation author list using the C locale.
  • #791834 on bitcoin by Reiner Herrmann: sort sources files using the C locale.
  • #791845 on yacas by Reiner Herrmann: sort hints using the C locale.
  • #791851 on scowl by Reiner Herrmann: sort dictionary files using the C locale.
  • #791913 on ceph by Chris Lamb: sort configuration file names.
  • #791923 on alpine by Chris Lamb: use debian/changelog date as build date and use debian as the builder hostname.
  • #791960 on leveldb by Reiner Herrmann: sort sources files using th e C locale.
  • #792054 on ben by Reiner Herrmann: use debian/changelog date as bui ld date.
  • #792056 on val-and-rick by Reiner Herrmann: sort sources by filenames.
reproducible.debian.net

A new package set has been added for lua maintainers. (h01ger)

tracker.debian.org now only shows reproducibility issues for unstable.

Holger and Mattia worked on several bugfixes and enhancements: finished initial test setup for NetBSD, rewriting more shell scripts in Python, saving UDD requests, and more…

debbindiff development

Reiner Herrmann fixed text comparison of files with different encoding.

Documentation update

Juan Picca added to the commands needed for a local test chroot installation of the locales-all package.

Package reviews

286 obsolete reviews have been removed, 278 added and 243 updated this week.

43 new bugs for packages failing to build from sources have been filled by Chris West (Faux), Mattia Rizzolo, and h01ger.

The following new issues have been added: timestamps_in_manpages_generated_by_ronn, timestamps_in_documentation_generated_by_org_mode, and timestamps_in_pdf_generated_by_matplotlib.

Misc.

Reiner Herrmann has submitted patches for OpenWrt.

Chris Lamb cleaned up some code and removed cruft in the misc.git repository. Mattia Rizzolo updated the prebuilder script to match what is currently done on reproducible.debian.net.

Catégories: Elsewhere

Lars Wirzenius: /u/liw no more

Planet Debian - dim, 12/07/2015 - 08:17

I've used Reddit for many years. I used it for many years without an account, but eventually I made one. The site has always had its share of unpleasantness, people who're more interested in tearing down than in building. In recent years, it's gotten worse, and getting out of hand.

During the fairly short reign of Ellen Pao as CEO, I found things to be getting better. The site was starting to make it clear that harrassment, for example, was unacceptable. Unsurprisingly, this made some of the nastier people quite upset.

Pao has now resigned, and a new CEO has started. He had an "Ask Me Anything" session yesterday, and made it clear that he's changing things. From my point of view, it's changing to the worse. He made it clear that as long as Reddit itself does not get into legal trouble, and harrassment isn't too overt or particularly public, it's OK now.

I've closed my Reddit account.

Catégories: Elsewhere

Joey Hess: sweet summer

Planet Debian - sam, 11/07/2015 - 22:23

Having a wonderful summer, full of simple sweet pleasures. Mom visited today, and I made her this blackberry chocolate tart. Picking berries, swimming in the river, perfect summer day.

Earlier this summer, camped at in the dunes on Ocracoke island with many family and friends. Thunderstorms away across the sound flashed and grumbled long in the night, but mostly missed us. Jupiter and Venus in conjunction overhead, and the arch of the milky way completed the show.

Catégories: Elsewhere

Drupal core announcements: Drupal core security release window on Wednesday, July 15

Planet Drupal - sam, 11/07/2015 - 01:56
Start:  2015-07-15 (All day) America/New_York Online meeting (eg. IRC meeting) Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, July 15.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix/feature release on this date; the next window for a Drupal core bug fix/feature release is Wednesday, August 5.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur - Elsewhere