On 11 February 2016 at 09:15, Bryce Harrington
<bryce@...961...> wrote:
On Mon, Feb 08, 2016 at 10:31:05AM +0100, Sebastian Zartner wrote:
> Dear Martin, dear Bryce,
>
> thank you very much for replying and giving some more details on this.
>
> On 7 February 2016 at 02:54, Bryce Harrington <bryce@...961...> wrote:
> >
> > On Thu, Feb 04, 2016 at 08:42:38AM -0500, Martin Owens wrote:
> > > On Thu, 2016-02-04 at 10:23 +0100, Sebastian Zartner wrote:
> > > > While I am currently not involved in the Inkscape development at
all,
> > > > I have some experience with release processes and may help to define
a
> > > > proper development and release cycle.
> > >
> > > Dear Sebastian,
> > >
> > > There is a process for releases and the main component is a release
> > > sponsor or main coordinator. I believe the lack of sponsor is the main
> > > reason for not getting a 0.92 version released any sooner. Although I
> > > would love to see one on the sooner side.
> >
> > No, the duty here is on me. It's not a problem of lack of a belly
> > button for the task, but more of a time overcommitment issue.
> >
> > For 0.92, the specific thing blocking the release from proceeding is
> > needing to get the cmake build system fully squared away. To that end,
> > I recently posted a list of remaining tasks where I need help:
> >
> >
http://wiki.inkscape.org/wiki/index.php/CMake_Tasks
> >
> > Some of those may already be done, but need to be doublechecked. Once
> > all the 0.92 priorities are crossed off, then I think we can go ahead
> > and proceed with the release.
> >
> > Besides cmake, the one other thing that must be done is a review of the
> > current release stability. But so long as we don't have any development
> > work in intermediate stages, and no absolutely killer bugs, I think we
> > could cut a release and plan on a point release. We did a pretty
> > through scrub last time we were all focusing on getting 0.92 done, and
> > assuming things haven't majorly deteriorated since then, I think this
> > would be fine.
> >
> > > Bryce, do you have links we can share with Sebastian showing the
> > > organisational side for 0.91? Maybe they can help make the process
> > > better for the next release?
> >
> > Yeah I've been keeping the release coordination links on wiki pretty up
> > to date with the specifics of the process. However, with the build
> > system and now potentially the vcs system likely to change soon, a lot
> > is in flux.
> >
> > The #1 best thing that can be done right now to improve the release
> > process is to strengthen the build system. A lot of manual tasks in the
> > release will go away or be more easily automated once we can get unified
> > onto cmake (indeed this is my primary motivation for hammering on the
> > cmake transition).
> >
> > Automating the procedure of actually uploading the distribution package
> > to the website and making the associated web collateral get updated
> > would be a big improvement too, but honestly that work is pretty small
> > scope in the grand scheme of things. But boiling the release process
> > down to a single script or small number of scripts that can be run, is a
> > long term goal. With our current release cadence the benefit will be
> > minimal, but if we move to a faster cadence it could help a lot. I seem
> > to recall once we decide to cut a release, it is on the order of a
> > couple evenings to get it out.
> >
> > Frankly the actual mechanics of doing a release, while more cumbersome
> > than they should be, aren't where we usually get hung up and delayed.
> > What causes the delays are unfinished work and bugs, and needing to
> > verify that we are indeed stable enough to release. And that's an area
> > I would definitely love to see some discussion around how we could
> > improve.
>
> Regarding unfinished work and bugs I agree with Olof that this needs
> some changes in the workflow. What I would do different in regard of
> Olof's proposal is to create a branch for every (bigger) feature
> instead of having one dev branch. Also, a release may not be done at a
> fixed date, you may also do it depending on the number of new
> features/changes. If you remember, I already mentioned that earlier[1]
> (and you already agreed to this[2]).
> This would also play nicely with the workflow on GitHub and its pull
> requests if your discussion about switching to git concludes to use it
> as platform.
I hear you. I am a strong proponent of use of branches, particularly
for features, but really any work that isn't trivial. In theory, what
you're describing should be a very good system.
Unfortunately in practice there are other aspects that make it not so
easy.
Most notably, volunteer developers like to see their work used by
others (both for technical reasons - i.e. testing, as well as for
earning kudos from users). But if you are diligent and disciplined
about keeping your work off on a branch, it's unlikely you'll be able to
get either of these. Someone who is not branch-disciplined and instead
pushes directly to trunk, gets both rapid feedback from testing and
more instant recognition of their work.
So, essentially, the incentive structure kind of works against feature
branches.
If we were a company we could simply mandate workflows, but in a
volunteer project like ours, we risk alienating developers or at least
reducing the incentives they get for keeping up their efforts.
Not to say that feature branches are a bad idea - like I said up front,
I'm a strong advocate for that and use it myself. I think a lot of
developers also do work on branches on their own initiative. But
implementing it project-wide has some trickiness to it.
Last release I did experiment with having people work on their feature
branches, and then land them into an 'experimental' branch parallel to
the stable release tree, and then we merged that work in post-release.
I don't think I could call it a resounding success; I think people
mostly put up with it, or maybe even just took a development vacation.
With there being a split between stable and experimental, a lot of
people simply ran one or the other depending on their interest, thus
splitting our testing efforts. Bugfixing activity was not noticeably
better, and I don't think I could honestly say it improved our release
velocity. It did increase the workload and complexity for our bug team.
In terms of stability, I don't think I'd necessarily say the
experimental branch ended up being that much more buggy than the stable
branch; folks were pretty good about cleaning up problems as they
cropped up.
It is possible that things could be different with git. Merging in git
seems like it ends up working better than with bzr (maybe it's just
me). git rebase and format-patch and other such tools are well suited
for doing more highly distributed feature coding work.
Again, thank you for the insights, Bryce!
Let me also give you some insight into the workflow of the Firebug
Working Group as an example, for which I was a long-term volunteer
contributor and which is driven by a handful of volunteers besides one
fulltime (paid) maintainer.
Its development initially happened using Subversion on Google Code,
where there was basically only a master branch and everybody pushed
their code directly there. It had a unit testing suite, which needed
to be triggered manually, though.
When Google announced that Google Code will be shut down the team had
to decide where to move. And as Google Code already provided an
exporter to GitHub and due to good experiences from some of the team
members, the decision was quickly made for it.
With the move to GitHub we also set up a new workflow[1] by moving
from the single-branch system to using branches. The core contributors
were still able to push their code directly to master, though the
guideline was to use branches for bigger changes and to never break
the master branch. So, everybody started creating branches for new
features and bigger changes, ran the unit tests on their changes and
once they were all green, merged the branch to master. And Git(Hub)'s
tooling makes it very easy to work with branches and follow this
workflow. The maintainer made a release about every week (!) and
outlined in a blog post[2] the changes and newly added features.
Having this in mind, coming back to the points you mentioned:
volunteer developers like to see their work used by others for
technical reasons - i.e. testing
Reviewing changes is an important part of the workflow, especially the
first contributions.
as well as for earning kudos from users
Correct. That's one reason why you should do releases regularily and
promote their changes.
But if you are diligent and disciplined about keeping your
work off on a branch, it's unlikely you'll be able to get either
of these.
I'd say having an overburdened workflow is the reason for that.
E.g. having an extra experimental branch besides the master branch
sounds like it makes things unnecessary complicated and likely repels
(volunteer) contributors. I.e. only use one level of branching and -
if human resources are insuficient for reviewing every change - allow
(core) contributors to merge their changes to master.
Someone who is not branch-disciplined and instead
pushes directly to trunk, gets both rapid feedback from testing and
more instant recognition of their work.
Yes, but direct pushing is also more likely to break trunk. But you're
right, that will also provide instant recognition. ;-)
Though a slim process of merging branches also allows to get quick recognition.
So, the main point is to create an easy and transparent workflow,
which allows to keep trunk/master stable and provides some control
over what gets deployed.
Sebastian
[1]
https://getfirebug.com/wiki/index.php/GIT_Development_Workflow
[2]
https://blog.getfirebug.com/page/3/