The idea of deferring big issues and focusing on actual bugs in the patch release
This topic is on the agenda for discussion tomorrow. In the case of issue 153/154, at least, there seems to be a definite leaning in the direction of deferral. If we lean that way for similar fundamental breaking issues, I added a column to the issue spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxEy2GnOLv4/edit?usp=sharing> to imagine what the patch release workload might look like. The cells in bright yellow are my new proposals/questions for us to consider. You’ll also notice that I have proposed discussing and closing several issues tomorrow, in the pinkish color (mauve?). Judging by our past work cadence, we can likely meet our agreed timeline if we go in the deferral direction. If we don’t, we probably need to seriously rethink the timeline and release strategy. If you’ve got thoughts on the yellow cells ahead of the call (particularly if you can’t make the call), feel free to weigh in on this thread. Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
I'm not sure I can make the calls this week, but I'd like to weigh in. I do not agree that deferral is the right move for these issues (or many of the others that I have submitted). They are breaking changes, and they should not be targeted at 1.0.1, but that doesn't mean we have to wait to work on them and think about them. Targeting an issue for version "2.0.0" does *not* have to mean deferral in the temporal sense -- that it gets worked on later, after other stuff happens. I strongly encourage this group to work on revisions in parallel. It's a very common practice in software engineering to have a "stable" release branch that gets small patches and fixes while work continues on the not-as-stable "development" branch that's targeting a new version. Often times, new features and fixes are worked on in the development branch, and then backported to the stable branch where it makes sense to do so. This is a large part of what semantic versioning enables, and I'm suggesting that UMA do the same. Remember, we get to pick the version numbers and when we use them. We're not simply counting or picking from a fixed set. We don't have to exhaust the numeric space for "1.x" before we decide to work on "2.0". It could be that UMA 1.0.1 is the last UMA 1.x release ever. Or there could be a 1.0.2, or a 1.1.0, or anything like that. But none of that need to delay the 2.0 branch from starting. If this were a project that I was running, I would create a branch in the repository today and tag it "2.0.x", and address 153, 154, and a handful of others in there. If anything can then be backported safely into the 1.0 branch, then let's do that. In short: we don't have to wait, so let's not. -- Justin On 8/12/2015 10:40 AM, Eve Maler wrote:
This topic is on the agenda for discussion tomorrow.
In the case of issue 153/154, at least, there seems to be a definite leaning in the direction of deferral. If we lean that way for similar fundamental breaking issues, I added a column to the issue spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxEy2GnOLv4/edit?usp=sharing> to imagine what the patch release workload might look like. The cells in bright yellow are my new proposals/questions for us to consider. You’ll also notice that I have proposed discussing and closing several issues tomorrow, in the pinkish color (mauve?).
Judging by our past work cadence, we can likely meet our agreed timeline if we go in the deferral direction. If we don’t, we probably need to seriously rethink the timeline and release strategy.
If you’ve got thoughts on the yellow cells ahead of the call (particularly if you can’t make the call), feel free to weigh in on this thread. Thanks,
Eve
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
I agree with you about not meaning temporal deferral — sorry, I just mean tagging them with the “V2.0” milestone or whatever we decide. We already discussed this. Eve
On 12 Aug 2015, at 7:55 AM, Justin Richer <jricher@mit.edu> wrote:
I'm not sure I can make the calls this week, but I'd like to weigh in.
I do not agree that deferral is the right move for these issues (or many of the others that I have submitted). They are breaking changes, and they should not be targeted at 1.0.1, but that doesn't mean we have to wait to work on them and think about them. Targeting an issue for version "2.0.0" does *not* have to mean deferral in the temporal sense -- that it gets worked on later, after other stuff happens. I strongly encourage this group to work on revisions in parallel. It's a very common practice in software engineering to have a "stable" release branch that gets small patches and fixes while work continues on the not-as-stable "development" branch that's targeting a new version. Often times, new features and fixes are worked on in the development branch, and then backported to the stable branch where it makes sense to do so. This is a large part of what semantic versioning enables, and I'm suggesting that UMA do the same.
Remember, we get to pick the version numbers and when we use them. We're not simply counting or picking from a fixed set. We don't have to exhaust the numeric space for "1.x" before we decide to work on "2.0". It could be that UMA 1.0.1 is the last UMA 1.x release ever. Or there could be a 1.0.2, or a 1.1.0, or anything like that. But none of that need to delay the 2.0 branch from starting.
If this were a project that I was running, I would create a branch in the repository today and tag it "2.0.x", and address 153, 154, and a handful of others in there. If anything can then be backported safely into the 1.0 branch, then let's do that.
In short: we don't have to wait, so let's not. -- Justin
On 8/12/2015 10:40 AM, Eve Maler wrote:
This topic is on the agenda for discussion tomorrow.
In the case of issue 153/154, at least, there seems to be a definite leaning in the direction of deferral. If we lean that way for similar fundamental breaking issues, I added a column to the issue spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxEy2GnOLv4/edit?usp=sharing> to imagine what the patch release workload might look like. The cells in bright yellow are my new proposals/questions for us to consider. You’ll also notice that I have proposed discussing and closing several issues tomorrow, in the pinkish color (mauve?).
Judging by our past work cadence, we can likely meet our agreed timeline if we go in the deferral direction. If we don’t, we probably need to seriously rethink the timeline and release strategy.
If you’ve got thoughts on the yellow cells ahead of the call (particularly if you can’t make the call), feel free to weigh in on this thread. Thanks,
Eve
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
To add a bit of color to this… We can work on as many branches as we want simultaneously, but the world — case in point, the world of spec approvals and Kantara member voting and such — is linear (think release engineering). And we can’t pump V2.0.0 (or whatever) through that process before V1.0.1 (or whatever). And that process takes a fairly long time (you can bemoan it, or be glad of the protections it provides). And given that we don’t always have people jumping up and down to take assignments, and bug fixes do need to get made, I also want to make sure some knitting gets stuck to. Eve
On 12 Aug 2015, at 8:00 AM, Eve Maler <eve@xmlgrrl.com> wrote:
I agree with you about not meaning temporal deferral — sorry, I just mean tagging them with the “V2.0” milestone or whatever we decide. We already discussed this.
Eve
On 12 Aug 2015, at 7:55 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
I'm not sure I can make the calls this week, but I'd like to weigh in.
I do not agree that deferral is the right move for these issues (or many of the others that I have submitted). They are breaking changes, and they should not be targeted at 1.0.1, but that doesn't mean we have to wait to work on them and think about them. Targeting an issue for version "2.0.0" does *not* have to mean deferral in the temporal sense -- that it gets worked on later, after other stuff happens. I strongly encourage this group to work on revisions in parallel. It's a very common practice in software engineering to have a "stable" release branch that gets small patches and fixes while work continues on the not-as-stable "development" branch that's targeting a new version. Often times, new features and fixes are worked on in the development branch, and then backported to the stable branch where it makes sense to do so. This is a large part of what semantic versioning enables, and I'm suggesting that UMA do the same.
Remember, we get to pick the version numbers and when we use them. We're not simply counting or picking from a fixed set. We don't have to exhaust the numeric space for "1.x" before we decide to work on "2.0". It could be that UMA 1.0.1 is the last UMA 1.x release ever. Or there could be a 1.0.2, or a 1.1.0, or anything like that. But none of that need to delay the 2.0 branch from starting.
If this were a project that I was running, I would create a branch in the repository today and tag it "2.0.x", and address 153, 154, and a handful of others in there. If anything can then be backported safely into the 1.0 branch, then let's do that.
In short: we don't have to wait, so let's not. -- Justin
On 8/12/2015 10:40 AM, Eve Maler wrote:
This topic is on the agenda for discussion tomorrow.
In the case of issue 153/154, at least, there seems to be a definite leaning in the direction of deferral. If we lean that way for similar fundamental breaking issues, I added a column to the issue spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxEy2GnOLv4/edit?usp=sharing> to imagine what the patch release workload might look like. The cells in bright yellow are my new proposals/questions for us to consider. You’ll also notice that I have proposed discussing and closing several issues tomorrow, in the pinkish color (mauve?).
Judging by our past work cadence, we can likely meet our agreed timeline if we go in the deferral direction. If we don’t, we probably need to seriously rethink the timeline and release strategy.
If you’ve got thoughts on the yellow cells ahead of the call (particularly if you can’t make the call), feel free to weigh in on this thread. Thanks,
Eve
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
participants (2)
-
Eve Maler -
Justin Richer