Hello all, As a result from the WhenIsGood I sent out[0], the meeting to discuss Fedora Projects Tooling has been set for 2015-05-13 at 14:00 UTC
https://apps.fedoraproject.org/calendar/infrastructure/2015/5/13/?tzone=UTC#...
Hope to see everyone there!
-AdamM
[0] - https://lists.fedoraproject.org/pipermail/rel-eng/2015-May/019972.html
On Fri, May 08, 2015 at 08:59:49AM -0500, Adam Miller wrote:
As a result from the WhenIsGood I sent out[0], the meeting to
discuss Fedora Projects Tooling has been set for 2015-05-13 at 14:00 UTC https://apps.fedoraproject.org/calendar/infrastructure/2015/5/13/?tzone=UTC#... Hope to see everyone there!
Okay, so, what are our next steps here? As I remember the meeting :) there was a lot of support for taiga.io, but we wanted to hold off actually going through the process of packaging it until actually trying it.
I'd like to suggest that we use the hosted taiga.io service for organizing work on
https://fedoraproject.org/wiki/Changes/Two_Week_Atomic https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
Adam mentioned that Ralph has a fedauth plugin, and maybe we could even get them to add that as a sign-in option on the hosted service (right next to "Login with github") — but I suggest just individual accounts until Flock.
Adam's other concern was backups — what do we do if the hosted service folds? I see that there _is_ export/import functionality, and possibly that's scriptable, but we could at least do it manually weekly for the summer (and accept a little bit of risk).
What do you all think?
On Fri, Jun 26, 2015 at 01:18:14PM -0400, Matthew Miller wrote:
On Fri, May 08, 2015 at 08:59:49AM -0500, Adam Miller wrote:
As a result from the WhenIsGood I sent out[0], the meeting to
discuss Fedora Projects Tooling has been set for 2015-05-13 at 14:00 UTC https://apps.fedoraproject.org/calendar/infrastructure/2015/5/13/?tzone=UTC#... Hope to see everyone there!
Okay, so, what are our next steps here? As I remember the meeting :) there was a lot of support for taiga.io, but we wanted to hold off actually going through the process of packaging it until actually trying it.
I'd like to suggest that we use the hosted taiga.io service for organizing work on
https://fedoraproject.org/wiki/Changes/Two_Week_Atomic https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
Adam mentioned that Ralph has a fedauth plugin, and maybe we could even get them to add that as a sign-in option on the hosted service (right next to "Login with github") — but I suggest just individual accounts until Flock.
Adam's other concern was backups — what do we do if the hosted service folds? I see that there _is_ export/import functionality, and possibly that's scriptable, but we could at least do it manually weekly for the summer (and accept a little bit of risk).
What do you all think?
We set up http://taiga.cloud.fedoraproject.org with:
- ansible, so we can repeat it - a fedora openid auth plugin
It's not packaged. So you can try it out first there, and then if we like it we can go through with that.
It's an already out of date version of taiga. It's 1.6.0, and they're already on 1.8.0.
It doesn't currently have backups in place. I've been meaning to do it but I just haven't had/made time. I'll respond to this thread when it's finally done. (we have scripts to manage postgres backups like this already, so it should be easy).
The fedora-hubs group is already using it to some extent.
Other things we want to do *if* we like it and packaging it doesn't throw up any ridiculous hurdles:
- write trac/pagure/bz(?) plugins so that our tickets automatically show up in taiga -- and we can shuffle them around nicely there. - probably other good stuff.
On Fri, Jun 26, 2015 at 04:17:40PM -0400, Ralph Bean wrote:
We set up http://taiga.cloud.fedoraproject.org with:
Oh, cool. So I went ahead and made this. I had previously put a bunch of imagined subtasks on the wiki, and instead I put those here, and will probably change the wiki to just show the very high level. So: http://taiga.cloud.fedoraproject.org/project/two-week-atomic/kanban
I set this up as a Kanban project, with six top-level tasks and a bunch of subtasks. However, I'm not sure that's necessarily the best level for visibility here; it might actually be better to set up those six as individual projects so their individual subtasks can be more visibile. Particularly, I'm concerned about the "in progress" column here — these all might be too big for that.
I *also* enabled the "scrum backlog" feature, which gives a different view on the same things: http://taiga.cloud.fedoraproject.org/project/two-week-atomic/backlog and which also kind of makes me want to have more granularity. But, again, I dunno. That might be too much. Also that wants us to configure sprints and stuff, which is a whole commitment-to-approach.
We might want
On Fri, Jun 26, 2015 at 09:50:58PM -0400, Matthew Miller wrote:
We might want
Apparently it was bedtime. :)
On Fri, Jun 26, 2015 at 8:50 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 26, 2015 at 04:17:40PM -0400, Ralph Bean wrote:
We set up http://taiga.cloud.fedoraproject.org with:
Oh, cool. So I went ahead and made this. I had previously put a bunch of imagined subtasks on the wiki, and instead I put those here, and will probably change the wiki to just show the very high level. So: http://taiga.cloud.fedoraproject.org/project/two-week-atomic/kanban
I set this up as a Kanban project, with six top-level tasks and a bunch of subtasks. However, I'm not sure that's necessarily the best level for visibility here; it might actually be better to set up those six as individual projects so their individual subtasks can be more visibile. Particularly, I'm concerned about the "in progress" column here — these all might be too big for that.
I *also* enabled the "scrum backlog" feature, which gives a different view on the same things: http://taiga.cloud.fedoraproject.org/project/two-week-atomic/backlog and which also kind of makes me want to have more granularity. But, again, I dunno. That might be too much. Also that wants us to configure sprints and stuff, which is a whole commitment-to-approach.
We might want
I forgot to mention, I have a wiki for the Taiga Project.
https://fedoraproject.org/wiki/Infrastructure/TaigaProject
With a note about the Infra meeting where it was tabled:
https://fedoraproject.org/wiki/Infrastructure/TaigaProject#.23.23.23_NOTE_.2...
-AdamM
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
On Fri, Jun 26, 2015 at 09:50:58PM -0400, Matthew Miller wrote:
http://taiga.cloud.fedoraproject.org/project/two-week-atomic/backlog and which also kind of makes me want to have more granularity. But, again, I dunno. That might be too much. Also that wants us to configure sprints and stuff, which is a whole commitment-to-approach.
Okay, so, just to see how it looks, I broke this down into four (4!) sub-projects in Taiga. I kind of wish the system supported Epics (see upstream thoughts on that https://blog.taiga.io/epic-stories.html), but it doesn't.
So, it looks like this:
http://taiga.cloud.fedoraproject.org/project/two-week-atomic-build-sys/kanba... http://taiga.cloud.fedoraproject.org/project/two-week-atomic-test-sys/kanban http://taiga.cloud.fedoraproject.org/project/two-week-atomic-rel-sys/kanban http://taiga.cloud.fedoraproject.org/project/two-week-atomic-websites/kanban
with each project basically corresponding to one of the big blocks from https://fedoraproject.org/wiki/Changes/Two_Week_Atomic#Schematic.
What do you all think? Is this better or worse than everything in one project for task tracking?
OR, do we want to do this entirely differently, with one "release engineering" project and all releng tasks for all of everything (whether Fedora Changes, internal projects, technical debt, etc.)?
On Mon, Jun 29, 2015 at 9:11 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 26, 2015 at 09:50:58PM -0400, Matthew Miller wrote:
http://taiga.cloud.fedoraproject.org/project/two-week-atomic/backlog and which also kind of makes me want to have more granularity. But, again, I dunno. That might be too much. Also that wants us to configure sprints and stuff, which is a whole commitment-to-approach.
Okay, so, just to see how it looks, I broke this down into four (4!) sub-projects in Taiga. I kind of wish the system supported Epics (see upstream thoughts on that https://blog.taiga.io/epic-stories.html), but it doesn't.
So, it looks like this:
http://taiga.cloud.fedoraproject.org/project/two-week-atomic-build-sys/kanba... http://taiga.cloud.fedoraproject.org/project/two-week-atomic-test-sys/kanban http://taiga.cloud.fedoraproject.org/project/two-week-atomic-rel-sys/kanban http://taiga.cloud.fedoraproject.org/project/two-week-atomic-websites/kanban
with each project basically corresponding to one of the big blocks from https://fedoraproject.org/wiki/Changes/Two_Week_Atomic#Schematic.
What do you all think? Is this better or worse than everything in one project for task tracking?
OR, do we want to do this entirely differently, with one "release engineering" project and all releng tasks for all of everything (whether Fedora Changes, internal projects, technical debt, etc.)?
This would be my preference but I'm not sure if everyone would agree. On my old team we would use "tags" to define if a card belongs to a project and just prepend it to the title of the card. So something like "[TwoWeekAtomic] Task 1" for example, and then there would be a project card with an explanation of the project and a list of tasks (with links to cards associated with tasks). That would allow us to quickly see project status and track related tasks on the board.
Just a suggestion. I'm open to alternatives though.
-AdamM
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ rel-eng mailing list rel-eng@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/rel-eng
On Mon, Jun 29, 2015 at 12:11:16PM -0500, Adam Miller wrote:
OR, do we want to do this entirely differently, with one "release engineering" project and all releng tasks for all of everything
This would be my preference but I'm not sure if everyone would agree. On my old team we would use "tags" to define if a card belongs to a project and just prepend it to the title of the card. So something like "[TwoWeekAtomic] Task 1" for example, and then there would be a project card with an explanation of the project and a list of tasks (with links to cards associated with tasks). That would allow us to quickly see project status and track related tasks on the board. Just a suggestion. I'm open to alternatives though.
I wish we could have both views at once. I think the "all work on one wall" approach works well for a single team dedicated to that work, but I'm not sure how to track something like this with it.
A) There's plenty of work that will be not relevant to someone invested in this change but not releng overall. I don't see an easy way in Taiga to filter the Kanban board by tags, making hard to see the state of _this_ project.
B) On the other side, there's plenty of work in this project that isn't release engineering. Where does that work get tracked? Say, for example, someone from Websites, or perhaps (wholly theoretically) a UX designer from Atomic who is making a first contribution to Fedora through this project — where does their work get tracked?
If the filtering were better (and perhaps I'm just missing something) we could solve B by declaring that we're going to track the change as a Rel-Eng project, and that everyone involved should see themselves through that lens. For these two changes (Two-Week Atomic, Layered Images) that might just be okay — perhaps even with the lack of filtering. But does it scale to _all_ of the Changes?
On Mon, Jun 29, 2015 at 1:19 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Jun 29, 2015 at 12:11:16PM -0500, Adam Miller wrote:
OR, do we want to do this entirely differently, with one "release engineering" project and all releng tasks for all of everything
This would be my preference but I'm not sure if everyone would agree. On my old team we would use "tags" to define if a card belongs to a project and just prepend it to the title of the card. So something like "[TwoWeekAtomic] Task 1" for example, and then there would be a project card with an explanation of the project and a list of tasks (with links to cards associated with tasks). That would allow us to quickly see project status and track related tasks on the board. Just a suggestion. I'm open to alternatives though.
I wish we could have both views at once. I think the "all work on one wall" approach works well for a single team dedicated to that work, but I'm not sure how to track something like this with it.
A) There's plenty of work that will be not relevant to someone invested in this change but not releng overall. I don't see an easy way in Taiga to filter the Kanban board by tags, making hard to see the state of _this_ project.
B) On the other side, there's plenty of work in this project that isn't release engineering. Where does that work get tracked? Say, for example, someone from Websites, or perhaps (wholly theoretically) a UX designer from Atomic who is making a first contribution to Fedora through this project — where does their work get tracked?
If the filtering were better (and perhaps I'm just missing something) we could solve B by declaring that we're going to track the change as a Rel-Eng project, and that everyone involved should see themselves through that lens. For these two changes (Two-Week Atomic, Layered Images) that might just be okay — perhaps even with the lack of filtering. But does it scale to _all_ of the Changes?
I think that's going to be hard to predict unless someone goes through and tries mocking it all up in Taiga which is probably a pretty big time sink.
-AdamM
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
On Mon, Jun 29, 2015 at 01:23:40PM -0500, Adam Miller wrote:
I think that's going to be hard to predict unless someone goes through and tries mocking it all up in Taiga which is probably a pretty big time sink.
The feature where you can bulk create cards by pasting in lines of text actually makes this pretty easy.
On Fri, Jun 26, 2015 at 04:17:40PM -0400, Ralph Bean wrote:
We set up http://taiga.cloud.fedoraproject.org [but]... .. <snip> .. It doesn't currently have backups in place. I've been meaning to do it but I just haven't had/made time. I'll respond to this thread when it's finally done. (we have scripts to manage postgres backups like this already, so it should be easy).
OK, backups are in place: http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=fe5eccd3...
On Mon, 29 Jun 2015 09:56:41 -0400 Ralph Bean rbean@redhat.com wrote:
On Fri, Jun 26, 2015 at 04:17:40PM -0400, Ralph Bean wrote:
We set up http://taiga.cloud.fedoraproject.org [but]... .. <snip> .. It doesn't currently have backups in place. I've been meaning to do it but I just haven't had/made time. I'll respond to this thread when it's finally done. (we have scripts to manage postgres backups like this already, so it should be easy).
OK, backups are in place: http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=fe5eccd3...
Actually there's a few more manual steps requred. ;(
* Install rdiff-backup on the instance. * Run an initial backup baseline.
I've done these on taiga now, and backups should be working from now on. We should look at automating those steps.
kevin
On Fri, Jun 26, 2015 at 12:18 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, May 08, 2015 at 08:59:49AM -0500, Adam Miller wrote:
As a result from the WhenIsGood I sent out[0], the meeting to
discuss Fedora Projects Tooling has been set for 2015-05-13 at 14:00 UTC https://apps.fedoraproject.org/calendar/infrastructure/2015/5/13/?tzone=UTC#... Hope to see everyone there!
Okay, so, what are our next steps here? As I remember the meeting :) there was a lot of support for taiga.io, but we wanted to hold off actually going through the process of packaging it until actually trying it.
I'd like to suggest that we use the hosted taiga.io service for organizing work on
https://fedoraproject.org/wiki/Changes/Two_Week_Atomic https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
Adam mentioned that Ralph has a fedauth plugin, and maybe we could even get them to add that as a sign-in option on the hosted service (right next to "Login with github") — but I suggest just individual accounts until Flock.
Adam's other concern was backups — what do we do if the hosted service folds? I see that there _is_ export/import functionality, and possibly that's scriptable, but we could at least do it manually weekly for the summer (and accept a little bit of risk).
What do you all think?
It was decided during a Fedora Infrastructure meeting to table this until Flock so I haven't really put a lot of thought into it since I figured we'd hash things out there.
-AdamM
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
rel-eng@lists.fedoraproject.org