I would say we keep it simple. In the past we just did this: * close the issue as soon as the fix is in master * comment with which version it's gonna be released: a) not backported: comes out with the next major release in a few months b) backported: will be fixed with the next patch release for current stable, in the next weeks
That should make it clear. No need for excessive tag management. On Aug 15, 2014 3:47 PM, =?ISO-8859-1?Q?J=F6rn_Friedrich_Dreyer?= <[email protected]> wrote: > > I currently have issue[1] open, with two[2] PRs[3] merged. > > While the issue is fixed, our users still have that problem because the > code has not yet been released, which is why I labeled all of them as '7 > - To release'. The issue is not *done* done[4], yet. > > From a developer perspective I just closed the issue now. However, I > know several people who will then ask me "But when will it be released?" > Obviously in the next release. We could track that with the '7 - To > release' label (and the version labels 'v7.x' etc) however I am a > software engineer, which means, I am by definition lazy and try to > automate as much as possible. I don't want to have to manually assign > labels... > > Craig already mentioned to me that he has a few scripts to add labels to > ownCloud repos. So I revisited the labels we are using to track the > lifecycle of an issue and thought about how we can automatically assign > them based on interactions we already make via github. > > See http://yuml.me/8a5865cb for a graphical version. If you want to edit > that go to http://yuml.me/edit/8a5865cb > > Yes, I am abusing a class diagram and yes, your monitor might be to > small to fit it without resizing. Nevertheless, the boxes are the labels > and contain the corresponding tasks. The arrows are labeled with the > condition that can be checked to automatically assign the next label > (and remove the previous one). Only later labels can automatically be > assigned, eg. it does not make sense to assign 'to develop' because > someone sets the milestone to 'current' or 'next'. > > The attentive reader will have observed that I got rid of the '6 - > Reviewing' label because assigning that only prevent others from doing a > review. I added a 'Done Done' label though to make explicit that the > code is available to end users. > > If you are wondering why we are even tracking this have a look at > https://huboard.com/owncloud/core which gives a better overview of what > is being done than plain github. Unfortunately, I did not find a way to > link to a specific milestone. > > Transparency, knowing what is going on and where something stalls is the > first step to allow our community to find spots where they can get started. > > I would like to hear your thoughts about this. If you think this > lifecycle and the automatic transitions make sense I'll have a look at > writing a small web service that subscribes to github events and does > the automagic labeling. In that regard I found botdylan[5] to be a nice > starting point. > > Jörn > > [1] https://github.com/owncloud/core/issues/10009 > [2] https://github.com/owncloud/core/issues/10048 > [3] https://github.com/owncloud/core/issues/10287 > [4] http://www.jamesshore.com/Agile-Book/done_done.html > [5] https://github.com/botdylan/botdylan > > -- > Jörn Friedrich Dreyer ([email protected]) > Senior Software Engineer > ownCloud GmbH > > Your Data, Your Cloud, Your Way! > > ownCloud GmbH, GF: Markus Rex, Holger Dyroff, Frank Karlitschek > Schloßäckerstrasse 26a, 90443 Nürnberg, HRB 28050 (AG Nürnberg) > _______________________________________________ > Devel mailing list > [email protected] > http://mailman.owncloud.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/devel
