Proposal of development process for snapcraft

The following text relates to the documentation and recording of how we develop. This includes:

  • the tools we use
  • what we require for a PR
  • the milestones we generate
  • debian/changelog creation
  • the tagging and generation of release notes

So here it is, we require that every PR have a launchpad bug assigned to it, a link to the PR in the bug and that bug assigned to a specific milestone. This requirement comes from before we started using Trello, regardless of the use of Trello or not, the nice attribute this has is that we have backwards and forwards traceability from bug to PR and PR to bug which we can get an eagle view of by looking at the milestone bug page which by doing so, we know the status of every feature in a release at any given time.

With Trello we have an added burden of sort of keeping tabs the same way for people not in our day to day, let’s call them stakeholders, I like Trello, but its lack of easy integration into github makes it pretty hard to keep up to date.

The debian/changelog is generated by running gbp dch --since <tag>, this creates a nice entry point changelog for us to edit a bit further and adds LP: # formed bug links and given the way github works today, PR numbers too.
Links to bugs in debian/changelog make little sense now that we SRU everything and were told that it makes life complicated for developers.

All this said and I have made no point yet. I am trying to convince myself to just drop the requirement of having a bug assigned to every PR, reduce the use of Trello a bit with regards to breaking down items and instead embracing this here forum + using milestones from github instead. This would leave bugs on launchpad to solve as pure bugs that need solving from somewhere in the community.

So how would this look like. We go over the set of things we can do in a two week iteration with (in 99% of the cases a new version of snapcraft out). My proposal is to instead of adding things to a lane on Trello to actually just create a new wiki post with the features we want to work on. This would be the sprint promises. As the sprint progresses we would be adding links or branching into new posts (nothing heavyweight) and adding ticks to the things we start getting done.

Not sure what people think of this, but browsing launchpad these days is not as easy so most people have a hard time of figuring out what is going on and I don’t really want to triplicate information everywhere, this ain’t the government!

Thanks for keeping this discussion going on.

First, a big +1 to using less trello. We already have to deal with github and launchpad which don’t play very well together, and adding trello to the mix complicates the process without giving us a lot of value.

Then, this will be like the third time I insist, but I’m sorry (#notsorry:). Handling bugs in github will make easier the lives of bug reporters and bug fixers. I would really want to use launchpad only for the SRU bug that Sergio and I work on every 2 weeks, and things specific to the deb packaging. We would be able to use github project boards and milestones to give full traceability of our work, with little effort.

If we can’t do that, then I would agree to reduce the traceability. Making one launchpad bug per github PR is too much. Leaving launchpad only for real bugs, also means that the launchpad milestones don’t make a lot of sense anymore. We can cover for some of it with github tools.

Independent of all that, I think that a post with the sprint promises and progress would improve a lot our communication with stakeholders, specially all the ones that don’t attend the meeting. And for the ones that attend the meeting, I don’t think they are looking at trello after the meeting anyway.

But you lost me when you mentioned the wiki. @sergiusens, did you mean the github wiki? Now that we have this nice forum, we can make a post every two weeks with the plans for the sprint, I don’t see a reason to use a wiki. Maybe you meant to make a post in the forum, and keep updating it. +1 in that case too.

Posts on this forum have a wiki mode so anyone can edit the first post that starts the discussion. This would allow for anyone to mark something as done on that top post.

Having a bug per PR feels like transforming the bug tracker into a pull request tracker, so dropping that practice sounds reasonable on itself.

As for Trello, we’ve also discussed today the idea of dropping it in favor of using the forum for management of high-level goals. That sounds doable for the volume of objectives we manage, and it’s a clear win due to the visibility of the process and its integration with conversations.

For PRs targeting a release, though, GitHub milestones are the way to go. This is a trivial tagging process so the list may be burned down to its end, so no reason to keep it anywhere else but next to the PR itself:

1 Like

Thanks for the comments, the bug per PR was a thing of a planning thing where we said this is the list of things we will get done for this sprint, but then we got Trello and kept our ways (I like Trello, but it feels so disconnected to a point where I really just think we are using it for the sake of using it -> dogma).

We’ll be moving to github milestones and tagging PRs now with an update to our Contributors.md

Adding my two cents here. Lots of devs expect to be able to do everything through GitHub when they interact with a project. The first time I saw the Snapcraft repo on GH I was looking for the issue tracker, and when I found it I was thought, “now I’m going to be really disoriented tracking this bug.”

All of the desires I’ve seen detailed here can be replicated on GH. It’ll also lower the barrier of entry for outside contributors to get involved as they likely already GH accounts. Win-Win-Win #winning

2 Likes

I’ve created https://github.com/snapcore/snapcraft/pull/1233 to get rid of the guidelines for creating bug reports.