Feb 03 13:10:59 <bryce> ======== Release Meeting ========Feb 03 13:11:34 <bryce> I have finished packaging 0.92.1pre1, and windows builds are available too. I was going to upload it last night + announce but the website was down.Feb 03 13:11:59 <doctormon> Thanks bryce!Feb 03 13:12:07 <bryce> but I've also found there are some changes anyway, so I'm going to respin the package and repost the tarballFeb 03 13:12:23 <bryce> there's always something...Feb 03 13:12:31 <su_v> bryce: any plans to also release tarballs on lp?Feb 03 13:12:38 <bryce> anyway, we're past schedule but I think I'll insert a 1 week delayFeb 03 13:12:55 <bryce> su_v, yes indeed. I was going to do that last night in fact.Feb 03 13:12:58 <su_v> tarballs of pre-releasesFeb 03 13:13:12 <su_v> okFeb 03 13:13:45 <bryce> I should add that updating stuff in LP adds several steps to the release process, which make it a bit more time consuming + more opportunities for mistakes...Feb 03 13:14:14 <bryce> however, LP is scriptable so I'm going to look into making a script that updates the records and stuff.Feb 03 13:14:30 <bryce> but bigger question is, do we need the tarballs uploaded to Launchpad?Feb 03 13:14:52 <su_v> website outages ...Feb 03 13:14:54 <bryce> su_v, how are the LP tarballs being utilized currently? Just for backup, or are there other needs?Feb 03 13:15:03 <su_v> bryce: if not done on lp, the whole process is rather secretiveFeb 03 13:15:20 <ScislaC> dang it... I apparently lost my connection close to 20 mins ago and it just now popped up that there was a broken pipe.Feb 03 13:15:35 <su_v> unless someone is a regular visitor to inkscape.org, and regularly checks gallery for latest updates - the pre-release does not happen.Feb 03 13:16:13 <su_v> bryce: source code is managed at lp currently - what's wrong with providing tarballs of release tags there?Feb 03 13:16:23 <bryce> su_v, I do announce them on the mailing list once the packages are readyFeb 03 13:16:54 <bryce> su_v, nothing wrong, just extra work, so I just want to make sure that work is actually useful to folksFeb 03 13:16:57 <su_v> the website does not maintain the code. it's often slow, the announcements happen later (if someone of the web-editor team knows about it), and has sporadic outagesFeb 03 13:17:37 <su_v> bryce: for packagers outside of inkscape who provide pre-release builds, lp might be more reliableFeb 03 13:17:53 <su_v> there at least there is no change that a file name is mangled such that it can't be unpackedFeb 03 13:18:04 <su_v> chance*Feb 03 13:18:40 <bryce> su_v, keep in mind though that if there are two places to download tarballs, then that opens a question on if the tarballs are the *same*.Feb 03 13:18:45 <su_v> with uploads to inkscape.org, you never know (the site in the past was silent if a file name was mangled in any way, or a counter added, or upload refused due to missing metadata)Feb 03 13:18:50 <bryce> that's not been a problem in practice, but is a theoretical issueFeb 03 13:18:57 <su_v> it has beenFeb 03 13:19:05 <su_v> there has been a mangled tarball uploadFeb 03 13:19:23 <su_v> (and I struggled with it myself at the time I was actively uploading packages)Feb 03 13:19:25 <bryce> mangled filename? yes.Feb 03 13:19:36 <su_v> anyway, I know that I'm overly sensitive to this issue.Feb 03 13:19:53 <bryce> no I mean the presence of two canonical sources for the tarball is a theoretical issue, although we've not hit a snag there in practice so farFeb 03 13:20:13 <bryce> su_v, well it's worth considering all angles certainlyFeb 03 13:20:14 <su_v> ignore, I was just curious what is planned for future release processesFeb 03 13:20:37 <bryce> some of those issues are just bugs, and I trust they'll get sorted out in time, just as other problems have gotten solved.Feb 03 13:20:45 <su_v> inkscape.org uploads are not scriptable. lp uploads (and likely those to gitlab or github) are - at least there's also an APIFeb 03 13:20:46 <bryce> the need for a backup is legitFeb 03 13:21:46 <bryce> the new release app will change the processes, but I don't know yet if it will obviate the need for uploading to LP... if nothing else backups will still be important; we'll need to wait and seeFeb 03 13:22:02 <su_v> another issue with resources uploaded to inkscape.org is predictability of the actual URL - gallery item in the past had a random number, not sure how that works nowFeb 03 13:22:26 <su_v> external packagers need to scrape the news page for any new URLs?Feb 03 13:22:59 <bryce> making inkscape.org uploads scriptable is a huge +1 from me. Next to updating the LP record, that is the next most time consuming chore in the process.Feb 03 13:24:57 <bryce> so back on 0.92.1pre1, one of the reasons for the delay was that there was a patch proposed for the dpi conversion dialog that I wanted to includeFeb 03 13:25:33 <bryce> I worked on it a fair bit Monday and Tuesday but I think it needs more attention before it's really ready, so am regretfully pushing it to 0.92.2Feb 03 13:25:34 <su_v> Tavmjong: re flowDiv - AFAICT there are more changes required (blank lines); I'll file a report so that a possible patch can be tracked for 0.92.2Feb 03 13:26:08 <Tavmjong> su_v: OK.Feb 03 13:26:28 <jabiertxof> Hi all! I do a patch to allow in the "DPI-Dialog" auto-grow and auto-shirnk, give more width to de dialog to get less height and indent the 2 optionals radio buttons. The problem is not know how to share it in a 3 patch way. Could share in the bug report the file "file-update.cpp" fixed with 1 and 2 patch applied? Bryce patch 3 is not related to this part of code. Currently Im finishing to recomplile,Feb 03 13:26:30 <jabiertxof> test ans be able to share it. Not found a way to run it a bit upper and run in the middle of the screen.Feb 03 13:27:07 <bryce> the dialog includes a substantial amount of new text, and so I also want to ensure we give ample time for translators to chew on that. Putting it to 0.92.2 gives us that time, and allows us to stick to a short translation window for 0.92.1Feb 03 13:27:39 <Tavmjong> bryce: I don't really understand the status of 0.92.1. Are you accepting any patches at all?Feb 03 13:28:38 <bryce> jabiertxof, I would suggest set up a branch. Apply the three patches and commit them. Then do your patch on top, and post that one as a follow up on the bug report.Feb 03 13:29:43 <bryce> Tavmjong, I'll clarify that in the pre1 announce. We will be in string freeze so no patches that change strings. Bug fixes are ok, but should be _small_ and easy to see are obviously correct. I will review all non-translation / non-packaging changes to the tree.Feb 03 13:29:56 <jabiertxof> ok dont undertand the last part but seems share the new branch no?Feb 03 13:30:21 <Tavmjong> bryce: OK. I'll propose a few tomorrow. Need to go now.Feb 03 13:30:28 <bryce> also, fixes should be landed on trunk. (I need to get a couple of my recent patches put on trunk too, as does the dpi patch stuff)Feb 03 13:30:34 <jabiertxof> no, I see itFeb 03 13:31:45 <su_v> with regard to 0.92.2 - I'd like to note (JFTR) that in case tghs provides updates for osx packaging for the stable release branch, I think those should be milestoned for 0.92.2 (so that if at all there could be an official package based on the that bug-fix release with as few as possible (ideally none) local packages required for packagingFeb 03 13:31:55 <su_v> )Feb 03 13:32:45 <su_v> local patches*Feb 03 13:33:03 <bryce> su_v, yes that seems like a good idea.Feb 03 13:34:13 <bryce> su_v, I imagine that much of the packaging work could even be done externally to the source package, but if there are changes that need landed on 0.92.x to support it, I'd be open to itFeb 03 13:34:32 <su_v> bryce: the packaging scripts are distributed with the tarballFeb 03 13:34:45 <su_v> so they are part of the current source code releaseFeb 03 13:35:07 <su_v> or at least they used to be - if that changes, they should not be included in the tarball, I think.Feb 03 13:36:00 <bryce> for Debian/Ubuntu we used to include the debian packaging in a debian/ directory, but dropped that once the packaging files started being maintained by Debian, as they had their own more proper place to host themFeb 03 13:36:28 <bryce> that has some benefit in that it decouples work they need to do for packaging, from our work in generating the source tarballFeb 03 13:36:55 <bryce> I like this approach in general, and would not mind seeing it adopted by non-linux packaging as well, where it makes sense and people wish to do that.Feb 03 13:37:22 <su_v> so you'd drop packaging/ altogether from the main source tree?Feb 03 13:37:29 <bryce> but again, I'm open to packaging changes on 0.92.x to support resurrecting the osx packaging if that's desiredFeb 03 13:37:34 <su_v> including the scripts for windows installers?Feb 03 13:38:38 <su_v> (for >= 0.93)Feb 03 13:39:05 <bryce> su_v, with Debian/Ubuntu, packaging is often handled as a second branch that is merged onto the source tree. This is how Inkscape's PPAs are set up, for example.Feb 03 13:39:22 <bryce> that allows the packagers freedom to do their work independently of what the upstreams are doingFeb 03 13:39:32 <bryce> I think it's a better model in generalFeb 03 13:40:19 <bryce> I wouldn't push people into doing that though, so like I said if packagers feel it makes more sense and want to keep stuff in the main tree, that's fineFeb 03 13:40:52 <bryce> but I think once we move to git, maintaining packaging in separate repos would have a number of benefits to them over maintaining it in the core treeFeb 03 13:41:25 <su_v> how does git change that?Feb 03 13:41:49 <su_v> (just curious - is this about submodules?)Feb 03 13:42:26 <bryce> su_v, no not about submodules. And to be fair it can probably be done with bzr too, there's nothing vcs-specific, it's just a practice of maintaining separate branches or repos for packaging stuff.Feb 03 13:43:03 <bryce> I specify git mainly because merging in git seems to be a heck of a lot more reliable than bzr merge (IMHO).Feb 03 13:43:57 <bryce> although admittedly it can be done without merges if you are attentive to keeping all packaging bits contained within a distinct subdirectory (e.g. debian/ for Debian packages)Feb 03 13:44:47 <bryce> so on the topic of 0.92.1, one thing we still need are Release NotesFeb 03 13:45:04 <bryce> essentially just a listing of what's different in 0.92.1 compared with 0.92.0Feb 03 13:45:11 <bryce> I would __really__ like help with thisFeb 03 13:45:39 <bryce> basically just bzr log, and summarize.Feb 03 13:47:22 <su_v> I keep logs per pre-release here: https://gist.github.com/su-v/public (just in case, and as tags are available in the branch)Feb 03 13:49:54 <su_v> bryce: I can help for the time being (as long as the current wiki is in place, and is where release note drafts are managed)Feb 03 13:50:09 <bryce> su_v, awesome thanksFeb 03 13:50:37 <bryce> yeah definitely no changes happening to wiki until after 0.92.1 is out the doorFeb 03 13:51:34 <su_v> once the wiki is declared obsolete (and basically killed), you will have to rely on signed-up members of the dev team (or website editors, if the draft is pulled into the CMS)Feb 03 13:51:49 <bryce> we may have some additional fixes between pre1 and pre2, but plan is no significant changes after pre2, so there shouldn't be anything else to add to the release notes from that point onFeb 03 13:52:16 <su_v> the list of notable bug-fixes will be short ;)Feb 03 13:52:53 <su_v> cf https://launchpad.net/inkscape/+milestone/0.92.1Feb 03 13:54:30 <su_v> tow 'high', and seven 'medium'Feb 03 13:54:37 <su_v> *twoFeb 03 13:54:40 <bryce> looking ahead to 0.92.2, I'm anticipating the list of changes for that may be short as well; the dpi dialog at least.Feb 03 13:55:19 <su_v> yeah, the list of regressions introduced with 0.91, plus those introduced with 0.92 will simply passed on to 0.93, in the end.Feb 03 13:55:33 <bryce> timing-wise for 0.92.2 I'm figuring maybe a couple months after 0.92.1 is released. So pre-release activities in March with release in early AprilFeb 03 13:56:00 <su_v> or no longer considered as 'regressions', since introduced earlier (they still are, but not recent)Feb 03 13:56:50 <bryce> for 0.92.2, I'd like to see the gpl3 stuff that Tweenk flagged get sorted out - namely the gimp spinner widget needs removed and replacedFeb 03 13:56:57 <jazzynico> 78 open regressions in 0.92.Feb 03 13:57:15 <bryce> until that's done, Inkscape is essentially GPLv3 as far as distribution goesFeb 03 13:57:38 <jazzynico> trying to fix some, but the list is too long for 0.92.2...Feb 03 13:57:40 * su_v would be so glad to see that GimpSpinScale widget reverted in 0.92.x - it's really a pain to use in many cases for those who prefer numerical inputFeb 03 13:58:02 <bryce> jazzynico, thanks for giving those attention.Feb 03 13:58:42 <bryce> I hope the predictability of the cadence of point releases helps motivate bugworkFeb 03 13:58:55 <su_v> for 0.93 with GKT3, the widget could be rewritten to optimize experience both for tablet and keyboard users (separate digit from slider, at least visually)Feb 03 13:59:10 <su_v> s/keyboard/mouse/Feb 03 14:00:15 <bryce> jazzynico, of the 78 open regressions, out of curiosity how many have assignees?Feb 03 14:01:50 <bryce> I haven't firmed up any dates for when 0.92.2 will come, and can be influenced if there are bugs under way that might need a bit extra timeFeb 03 14:02:23 <bryce> and as I mentioned above, a 0.92.3 is totally possible, tooFeb 03 14:02:24 <jazzynico> bryce: apparently 0.Feb 03 14:02:40 <bryce> jazzynico, ah.Feb 03 14:02:46 * su_v sees 78 reports tagged with 'regression', open and still milestoned for 0.92, without assigneeFeb 03 14:03:21 <su_v> according to lp's advanced searchFeb 03 14:03:48 <su_v> (duplicates excluded)Feb 03 14:04:15 <su_v> but that does not matter - some assignees are not following up, nor un-assign themselvesFeb 03 14:05:01 <bryce> su_v, true, and there may well be work being done by people afraid to take responsibility for the whole bug by assigning it to themselves.Feb 03 14:05:15 <su_v> lp does not support searching for the number of reports with (any) assigneeFeb 03 14:05:29 <su_v> only either without any, or with a specific oneFeb 03 14:05:39 <bryce> but as a general rule of thumb it's proved pretty reliable that bugs without assignees are a bit futile to wait on; most likely they're not getting any development attentionFeb 03 14:06:09 <bryce> ok, so moving on... down the road to 0.93Feb 03 14:06:15 <su_v> bryce: in my experience, assigned reports are often as 'dead' as assigned onesFeb 03 14:06:37 <su_v> as *unassigned onesFeb 03 14:07:16 <bryce> su_v, at the least there's a person I can contact to ask about the status thoughFeb 03 14:07:34 <su_v> since many devs filter out notifications from lp ...Feb 03 14:08:23 <bryce> well, and also if you're going to be inactive it's not like you're going to think to unassign yourself from your bugs, since that would require action ;-)Feb 03 14:08:29 <su_v> I at least gave up attempting to request feedback unless I know that the assignee is likely to respond (see the notification about a comment) at allFeb 03 14:08:58 <bryce> I suppose we could be more aggressive at unassigning folks if they're clearly not responsiveFeb 03 14:09:04 <fguimont> Was there talk of the portland hackathon?Feb 03 14:09:31 <bryce> but in any case, what I'm concerned more about are bugs that *don't* have assigneesFeb 03 14:09:52 <bryce> fguimont, a little, yes. Did you have some questions or ideas?Feb 03 14:10:17 <bryce> fguimont, I'm going to try and get a proposal out to the inkscape-board@ mailing list when I get a chunk of time to focus on itFeb 03 14:11:03 <bryce> anyway, on the topic of 0.93, I would like to get a better understanding of where we areFeb 03 14:11:29 <bryce> e.g. what major problems exist on it that still need addressed before we can consider it viable for releasing.Feb 03 14:11:48 <bryce> and along with that, who is working on those issues, and what timeframe they're looking at to getting them resolved.Feb 03 14:12:39 <bryce> for items that no one's working on, or that the timeframe is indeterminate, are there ways we could back out the changes that caused those problems, or other ways we can mitigate?Feb 03 14:13:50 <bryce> I'm thinking at some point I should put out a call for data, but feel free to throw issues at me right now. (If anyone is still here...)Feb 03 14:14:03 <bryce>Feb 03 14:14:38 <su_v> bryce: you want bug report links, now? ;)Feb 03 14:14:47 <bryce> su_v, sure, I can build a listFeb 03 14:15:01 <su_v> the lists are managed in the bug tracker ...Feb 03 14:15:01 <bryce> (famous last words I know...)Feb 03 14:15:25 <su_v> I'd hope that serious regressions which would warrant to revert a commit have been addressedFeb 03 14:16:03 <su_v> other regressions are likely in need of discussion / review whether reverting the original commit would be feasible, wanted or even provide a solution for the current code baseFeb 03 14:16:36 <fguimont> bryce: I was curious because it's something I'd like to participate in (if possible).7Feb 03 14:16:38 <su_v> also, weighting regressions depends on how the reporter, or a user in general, is affected or notFeb 03 14:16:53 <bryce> su_v, you can point me at the relevant list in the bug tracker if that's easierFeb 03 14:17:02 <su_v> sometimes a specific workflow might be "fixed", but others are now harder to doFeb 03 14:17:50 <su_v> bryce: in the past, most regressions (which could be identified by a commit that exposed them (not necessarily caused them)) had been tagged with 'regression'Feb 03 14:17:57 <bryce> fguimont, cool, we'd love to have you. We haven't settled on topics yet, or dates or anything, but I'll include that in the proposal. Website/Infrastructure is potentially a theme.Feb 03 14:17:59 <su_v> less often for reports after the 0.92 releaseFeb 03 14:18:28 <su_v> so a search for tag 'regression', combined with other search criteria (milestone, or importance), can give you a lisFeb 03 14:18:31 <su_v> tFeb 03 14:18:38 <jazzynico> Note that on some of the regressions I worked on recently, the bug was caused by a typo (or unexpected changes in the code).Feb 03 14:19:27 <jazzynico> So nothing very difficult, but quite time consuming.Feb 03 14:19:47 <fguimont> cool, let me know when you have details. I'm going to try to make it happen on my end. bryceFeb 03 14:19:48 <bryce> su_v, ok, well I'm less interested in laundry lists of issues and more looking for general themes of the top problems that would be most embarrassing to ship unfix.Feb 03 14:20:06 <su_v> I don't want to give you pointers to specific reports, because I know I have priorities set for those which affect me personally (which is irrelevant for release-related concerns)Feb 03 14:20:16 <bryce> fguimont, awesome! where are you generally located btw?Feb 03 14:20:29 <bryce> su_v, ok fair enoughFeb 03 14:21:08 <bryce> I'm trying to shift my viewpoint away from "what bugs are blockers" to more of a "what patches have we got ready in time for this release" attitudeFeb 03 14:21:31 <bryce>Feb 03 14:21:35 <su_v> bryce: maybe jazzynico can do better than me in this regard (I admire how 'cool' / calm he is all the time, facing all new issues and comments in the bug tracker)Feb 03 14:21:59 <fguimont> bryce I'm in Quebec city.Feb 03 14:22:42 <bryce> longer term than 0.93, thinking towards 1.0, there are two competing strategies. A) working towards maximum stability and eliminating all regressions, and B) completing code and infrastructure transitions to get the project where we want to be for the future, to give us a solid base we can build from past 1.0.Feb 03 14:22:56 <su_v> and given how many times I nowadays have to refer to him for bug management tasks (jazzynico, I'm really sorry for that)Feb 03 14:23:19 <bryce> yes jazzynico has an admirably professional demeanor. :-)Feb 03 14:23:44 <bryce> alright, I need to get some actual day job work done. :-/Feb 03 14:23:55 <bryce> any other questions or input on release matters?Feb 03 14:24:00 <jazzynico> thanks, unfortunately I often have to be away from Inkscape.Feb 03 14:24:17 <Lazur> what's the status with the manual?Feb 03 14:24:45 <Lazur> at https://sourceforge.net/p/inkscape/mailman/inkscape-docs/ latest 25 posts don't mention itFeb 03 14:24:47 <su_v> bryce: quick question - will there be a final pre2?Feb 03 14:24:49 <su_v> for 0.92.1Feb 03 14:25:26 <Lazur> http://tavmjong.free.fr/INKSCAPE/ page has dead linksFeb 03 14:25:30 <su_v> (this in the context of creating / updating release notes, wrt expected release date)Feb 03 14:26:13 <jazzynico> I need to go now.Feb 03 14:26:18 <jazzynico> See you soon!Feb 03 14:26:27 <su_v> also, will there be a final call for translators to share updates before 0.92.1 (I noticed that inkscape.pot was updated after pre1)Feb 03 14:26:45 <su_v> jazzynico: thx for all your work, ttyl!Feb 03 14:27:18 <Lazur> Inkscape 0.45.1: English. Inkscape 0.44.1: English, Dutch. Inkscape 0.43: English. are off siteFeb 03 14:27:28 <jazzynico> su_v: okFeb 03 14:28:40 <bryce> su_v, there will be a pre2 package, and hard freeze, then the schedule includes a pre3 I believe, that will be a release candidate so theoretically pre3 should be identical to the release except the numberFeb 03 14:29:08 <bryce> su_v, and between pre2 and pre3 should be extremely minimalFeb 03 14:29:30 <bryce> and yes final call for translatorsFeb 03 14:29:38 <bryce> I'm going to respin pre1 to include that pot updateFeb 03 14:30:03 <bryce> I attempted to update that myself but no longer know how to do it, guess I should ask.Feb 03 14:31:10 <jabiertxof> bryce: patch addedFeb 03 14:32:33 <bryce> ok, closing out the meetingFeb 03 14:32:37 <bryce> ======= EOM ===========Feb 03 14:34:01 <su_v> http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92.1 (Create draft version for Inkscape 0.92.1 release notes)
-
PasteBin
- Lines
- 194
- Words
- 3858
- Size
- 21.9 KB
- Created
- Type
- text/x-irclog
Please log in to leave a comment!
