| *** edcragg has quit IRC | 00:30 | |
| *** gtristan has quit IRC | 05:24 | |
| *** gtristan has joined #baserock | 06:09 | |
| *** gtristan has quit IRC | 06:11 | |
| *** gtristan has joined #baserock | 06:13 | |
| *** toscalix has joined #baserock | 07:58 | |
| *** toscalix has quit IRC | 08:27 | |
| *** CTtpollard has joined #baserock | 08:29 | |
| *** ctbruce has joined #baserock | 08:36 | |
| *** toscalix has joined #baserock | 08:42 | |
| *** tiagogomes has joined #baserock | 08:49 | |
| gtristan | Morning ! | 08:56 |
|---|---|---|
| * gtristan fixed interesting lorry bug today: https://gerrit.baserock.org/1656 | 08:56 | |
| gtristan | Not sure it's an issue on the host where we run the lorry controller | 08:56 |
| gtristan | seems not to be, so it must be a relatively recent regression in hg-fast-export | 09:00 |
| gtristan | Comparing http://hg.fedorahosted.org/hg/libpwquality with http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpwquality.git ... shows it at least worked a few months ago | 09:01 |
| *** bashrc has joined #baserock | 09:07 | |
| pedroalvarez | hm.. given that you are not using lorry in a baserock environment, I'd say this issue is present in your OS and not in lorry controller's host | 09:21 |
| pedroalvarez | I wonder which version are you running (of hg-fast-import) | 09:21 |
| pedroalvarez | i would guess yours is more recent | 09:21 |
| gtristan | pedroalvarez, something quite recent | 09:21 |
| gtristan | debian stretch (testing) here | 09:21 |
| pedroalvarez | the workaround looks good to me. | 09:22 |
| gtristan | hg-fast-import has no --version option | 09:22 |
| gtristan | yeah I think it's "safe" anyway | 09:22 |
| *** cyndis_ is now known as cyndis | 09:22 | |
| gtristan | and will avoid possible issues were the lorry controller host to be upgraded | 09:22 |
| pedroalvarez | I agree | 09:28 |
| pedroalvarez | jjardon: that's cool, I shall test it | 09:29 |
| pedroalvarez | wow, gerrit is full of your patches gtristan | 09:30 |
| pedroalvarez | I should review 25 times each | 09:30 |
| pedroalvarez | gtristan: question, are you planning to install 2 different versions of webkit? | 09:35 |
| pedroalvarez | or is this not webkit at all? https://gerrit.baserock.org/#/c/1621/1/open-source-lorries/WebKitGtk1-tarball.lorry | 09:35 |
| pedroalvarez | I take is only a new version | 09:37 |
| pedroalvarez | a new version for the lorry, although the version is older | 09:37 |
| pedroalvarez | gtristan: could you please not create a different lorry for it, and just change existing one? | 09:38 |
| pedroalvarez | the previous version lorried won't disappear | 09:38 |
| gtristan | pedroalvarez, it's infact an older version of the same API | 09:49 |
| gtristan | well sorry badly phrased | 09:49 |
| gtristan | its the "old API" branch (webkit1) built from the same freaky svn repo | 09:49 |
| gtristan | pedroalvarez, I can take that approach yes, it will only mean that in that lorried git history... there will potentially be intermingled versions, starting with the latest stable webkit2 (2.10.x), followed by the latest stable webkit1 (2.4.x) | 09:50 |
| gtristan | So potentially, there can be another release of *both* branches (say, if security fixes are backported to webkit1 API branch, which is totally plausible as many apps are still using the old API) | 09:51 |
| gtristan | pedroalvarez, so yeah, I have no problem changing that, just pointing out... what it means :) | 09:52 |
| gtristan | do we preffer to have one lorry for each ? or one lorry with intermingled releases ? | 09:52 |
| pedroalvarez | It will be easier to find the right version if we only have one lorry | 09:52 |
| persia | Unless we have needs to run webkit from both branches in different systems | 09:53 |
| pedroalvarez | that wouldn't be a problem | 09:53 |
| pedroalvarez | (from the lorry controller point of view) | 09:53 |
| gtristan | it's not really problematic to have them in the same git | 09:53 |
| gtristan | as you can build both from it | 09:53 |
| gtristan | just a matter of preference really :) | 09:54 |
| gtristan | pedroalvarez, ok I'll change it :D | 09:54 |
| gtristan | no worry | 09:54 |
| pedroalvarez | the belevolent dictator has spoken | 09:54 |
| gtristan | pedroalvarez, can we approve the other lorries in the queue ? there are a couple of them which need to be up so I can gitmodulize them | 09:55 |
| rjek | I have? | 09:55 |
| pedroalvarez | yes, I was doing so, but found webkit one, so I stopped reviewing | 09:55 |
| pedroalvarez | all of them depend on the webkit change | 09:55 |
| gtristan | pedroalvarez, I mean... the lorries do not depend on the webkit lorry | 09:57 |
| gtristan | I have for example, new lorries just pushed to gerrit today | 09:57 |
| gtristan | they have to be actually lorried, before I can update the definitions branch with new refs | 09:57 |
| pedroalvarez | I'd say that you have put all the changes on the same branch, and sent them all toghether for review | 09:59 |
| gtristan | pedroalvarez, specifically, telepathy-idle, telepathy-gabble, have wocky as a submodule | 09:59 |
| pedroalvarez | that makes gerrit think that latter commits depend on former commits | 09:59 |
| gtristan | and pidgin needs a downstream patch in order to build the latest stable against new gstreamer API | 10:00 |
| gtristan | eh ? | 10:00 |
| gtristan | pedroalvarez, the lorry changes are always all master | 10:00 |
| gtristan | note I am specifically talking about patches to 'lorries' repo | 10:00 |
| pedroalvarez | yes yes | 10:00 |
| pedroalvarez | my question is, have you done all the commits to add all of these lorries on the same branch? | 10:01 |
| pedroalvarez | or have you created different branches to send every of them | 10:01 |
| pedroalvarez | so that every of the patches apply on master | 10:01 |
| tiagogomes | gtristan any special reason for adding pidgin? Is not part of the GNOME core apps | 10:03 |
| pedroalvarez | the latter is too much work, so I;d say that what you have done is: | 10:03 |
| pedroalvarez | - clone lorries repo | 10:03 |
| pedroalvarez | - Add lorry1, commiit | 10:03 |
| pedroalvarez | - Add lorry2, commit | 10:03 |
| pedroalvarez | - .... | 10:03 |
| pedroalvarez | - Send for review | 10:03 |
| pedroalvarez | so gerrit thinks (and IMO is right) that lorry2 can't be merged until lorry1 is merged | 10:04 |
| gtristan | tiagogomes, for a complete empathy UX | 10:06 |
| gtristan | pedroalvarez, all of the lorries are individual commits on master | 10:06 |
| gtristan | I havent been branching in lorries at all | 10:06 |
| gtristan | pedroalvarez, gerrit is on crack if it thinks that | 10:07 |
| gtristan | What, you think I should instead A.) Add lorry, B.) Commit, C.) Send for Review, D.) Return to A ??? | 10:08 |
| pedroalvarez | well, you haven't created a branch, but you have created the commits on the same checkout | 10:08 |
| pedroalvarez | no, your current approach is good | 10:08 |
| gtristan | of course, what, I should have separate checkouts of each ?? | 10:08 |
| gtristan | oh | 10:08 |
| gtristan | ok | 10:08 |
| pedroalvarez | but you can't expect to merge the last commit before one in the middle of the series | 10:09 |
| *** ssam2 has joined #baserock | 10:10 | |
| *** ChanServ sets mode: +v ssam2 | 10:10 | |
| gtristan | pedroalvarez, but there is no series | 10:11 |
| tiagogomes | Empathy is not part of the core apps as well, unfortunately the developers of empathy didn't want to be an integral part of GNOME and be rebranded to just Chat | 10:11 |
| gtristan | I dont get it, how is there a series ? | 10:11 |
| tiagogomes | As they wanted Empathy to be used outside the GNOME desktop as well | 10:12 |
| gtristan | tiagogomes, I dont blame them for that at all | 10:12 |
| gtristan | that should be the case for almost every GNOME module | 10:12 |
| *** edcragg has joined #baserock | 10:12 | |
| gtristan | tiagogomes, whether empathy considers itself "gnome" or not, it is still considered a core part of GNOME according to: https://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-3.18.modules#n535 | 10:14 |
| gtristan | but anyway | 10:14 |
| gtristan | I think it's an important part of having an impressive GNOME desktop UX, and dont think it's really relevant | 10:15 |
| tiagogomes | Neither do I, sorry for disturbing you | 10:16 |
| * pedroalvarez cries | 10:16 | |
| jjardon | tiagogomes: do they? | 10:17 |
| pedroalvarez | failing to explain :/ | 10:17 |
| gtristan | pedroalvarez, https://gerrit.baserock.org/#/c/1657/ | 10:17 |
| gtristan | Kill Gerrit. | 10:18 |
| pedroalvarez | learn gerrit | 10:18 |
| gtristan | It doesnt do all the fancy automated crap we "wanted" it to do | 10:18 |
| gtristan | and it only gets in the way. | 10:18 |
| pedroalvarez | it gives us the possibility to add the fancy automated crap | 10:18 |
| gtristan | Thats not a logical argument | 10:19 |
| pedroalvarez | and this is not a gerrit problem | 10:19 |
| jjardon | And yeah, empathy is part of the core GNOME modules. it has not been in active development for a couple of years though | 10:19 |
| gtristan | pedroalvarez, Example: I could have implemented composite widget templates in GTK+ just in GtkWidget... But, the maintainers would not except that had I not ported each composite widget to actually use them | 10:20 |
| gtristan | pedroalvarez, point being, changes like this need to be unilaterally applied | 10:20 |
| pedroalvarez | then, your workflow to send unrelated patch-series is not working | 10:20 |
| gtristan | You dont implement a stumbling block in the hope that it will make things happen in the future, you implement it AND implement the features and apply it unilaterally. | 10:20 |
| pedroalvarez | what you have done now, is like if you had put all the commits on the same PR on github | 10:21 |
| ssam2 | gtristan: you can still send patches via the mailing list if you find it easier | 10:21 |
| ssam2 | gtristan: it's more annoying for us to merge them that way, though | 10:21 |
| gtristan | ssam2, bugzilla, or storyboard-if-it-accepts-attachments, mailing list is not a way to track patches | 10:22 |
| pedroalvarez | gtristan: then what do you suggest? | 10:22 |
| gtristan | the "gerrit was a replacement for the mailing list" is not a valid argument, *nobody* does patch reviews on mailing lists | 10:22 |
| ssam2 | Linux? | 10:23 |
| pedroalvarez | baserock for delta/* repos | 10:23 |
| gtristan | pedroalvarez, Ok, you said my approach was a valid one (see above, separate commits for each lorry)... tell me then, if that's not the case *what* is the correct approach ? | 10:23 |
| pedroalvarez | right | 10:23 |
| gtristan | All of the lorry commits are to be considered separate and orthogonal to definitions commits, they are not even the same repo | 10:24 |
| gtristan | The requirement however, is that the lorry commits actually get applied, before I can even submit for review the upcoming definitions branch | 10:24 |
| pedroalvarez | - clone repo | 10:24 |
| pedroalvarez | - do changes related to feature 1 (n commits) | 10:24 |
| pedroalvarez | - send for review | 10:24 |
| pedroalvarez | - go to a clean checkout | 10:24 |
| pedroalvarez | - do changes related to feature 2 (m commits) | 10:24 |
| pedroalvarez | - send for review | 10:24 |
| gtristan | Are you *fucking* serious ? | 10:25 |
| gtristan | Sorry but that is a disaster | 10:25 |
| pedroalvarez | please, moderate language | 10:25 |
| pedroalvarez | can you compare it to other workflows in other patch trakers? | 10:26 |
| * gtristan goes to eat | 10:26 | |
| gtristan | pedroalvarez, yes sure, I can use git-bz to send patches to bugzilla, I can create branches if I'm a "committer" (not a maintainer, note the difference) and have someone approve it in a bug report | 10:26 |
| gtristan | I can use git am to generate the patch sets and attach them to bugs for review | 10:27 |
| gtristan | In smaller/insignificant change cases (i.e. documentation fixes, lorry files, etc), as a committer I can get my patches reviewed on IRC, even, and just have the maintainer give me an OK | 10:29 |
| gtristan | (only cases which do not really merit properly being documented in a bug tracker) | 10:30 |
| pedroalvarez | so this is just a: we have to move to bugzilla? | 10:30 |
| pedroalvarez | I personally don't want patches utracked | 10:31 |
| gtristan | This is a "gerrit is totally screwed" and "it's a replacement for a mailing list" is just not a valid argument | 10:31 |
| gtristan | *because* bugzilla, because we are in 2015 and we have better ways of doing things than mailing list reviews | 10:31 |
| gtristan | pedroalvarez, even documentation fixes ? | 10:31 |
| gtristan | right now, I'm sorry but baserock sources are horribly untracked | 10:32 |
| gtristan | I can *not* do a git annotate on the sources, find the commit log and find pages of discussion documenting why the critical 2 line change was introduced | 10:32 |
| gtristan | I can however do that, with most projects | 10:32 |
| pedroalvarez | because they use bugzilla? | 10:33 |
| gtristan | Because they use *a bug tracker* | 10:33 |
| ssam2 | gtristan: sure you can .. with http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git | 10:33 |
| ssam2 | oh, I see what you mean | 10:33 |
| pedroalvarez | I'm sorry, I don't want to continue with this | 10:33 |
| gtristan | ssam2, right, commits should refer to the bug which discusses the change | 10:33 |
| ssam2 | yeah it would be nice to have links between code and bugs. | 10:33 |
| ssam2 | i try to link to ml discussions in commit messages if one is relevant | 10:34 |
| pedroalvarez | I'm happy with gerrit right now, and I wouldn't want to move to something else | 10:34 |
| rjek | Commit messages often include a "fixes #1234" for tracking to a bug report. I don't see why a commit message can't include "discussed <message id of thread>" | 10:34 |
| *** locallycompact has joined #baserock | 10:34 | |
| gtristan | rjek, that is a possible approach yes, but it's more clunky than using a bug tracker; because looking at the history of a change in a mailing list is not great, searching a mailing list is not great for tracking the interrelatedness of various other bugs, either | 10:35 |
| * rjek normally just pastes the message ID into google and it finds a public archive | 10:36 | |
| *** gtristan has quit IRC | 10:40 | |
| * persia reads a bit of backscroll and opines that there can be significant value in separating the bug tracker from the patch tracker | 11:09 | |
| * SotK agrees with persia | 11:09 | |
| SotK | I suggest that workflow for fixing a bug would be 1. File bug in storyboard, 2. Discuss in storyboard comments, 3. Send patch to Gerrit and link the story in commit message, 4. Review on Gerrit, 5. Merged with Gerrit | 11:11 |
| SotK | you can view the discussion via the link in the commit message, and the review process using the change-id | 11:12 |
| persia | One of the largest benefits to this is that it unconflates the user view and the developer view of the issue. | 11:13 |
| persia | Some user issues require several different development activities. | 11:13 |
| persia | Some developer activities affect several different user issues. | 11:13 |
| persia | Some users have a hard time consuming developer discussion about the technicalities of fixes, and many users get annoyed with messages like "there is a fix available, just use it!" when a patch is being reviewed, and needs adjustment for little things (e.g. whitespace fixes), or when a patch isn't safe to apply except as part of a general series or topic (which is hard to represent in a bug tracker without confusing different user issues) | 11:15 |
| persia | That said, one needs to have close integration between the bug tracker and patch tracker, so that folk that care are able to easily follow the status of things. | 11:16 |
| *** gtristan has joined #baserock | 11:33 | |
| * gtristan reads on https://irclogs.baserock.org/%23baserock.2015-12-18.log.html | 11:37 | |
| gtristan | persia, the problem I have with the bug tracker <--> gerrit <--> git commit log approach is basically linking it all is an overhead, getting people to properly mark the bug ID in a commit message has always been tricky, policy-wise | 11:38 |
| gtristan | that said I can see the "user" perspective | 11:38 |
| gtristan | honestly, even in small 2 or 3 person projects I've always used a bug tracker, and admit that I dont care as much about the user except that they actually file the reports, even without (or "before") users, bug tracking is essential to documenting project development | 11:40 |
| gtristan | And | 11:42 |
| gtristan | Sorry for my "outburst" | 11:42 |
| gtristan | This is a topic which has annoyed me for a while, I dont think gerrit is up-to-task to be honest, I dont see the point of having it if it's not doing the amazing things it was chosen for, either. | 11:43 |
| gtristan | s/up-to-task/up to the task/ rather | 11:43 |
| * gtristan finds himself more often working around gerrit's short comings than appreciating anything that it actually does | 11:44 | |
| *** paulsherwood has quit IRC | 11:45 | |
| *** paulsherwood has joined #baserock | 11:45 | |
| jjardon | Hi, is there a way in definitions to express "run configure commands of this chunk only in armv7lhf architectures" | 12:00 |
| radiofree | that would be nice | 12:00 |
| persia | gtristan: I'd say that even for projects with up to 8 active developers the separation is less necessary. For projects with tens of developers, it becomes important, and at hundreds of developers critical. | 12:01 |
| gtristan | persia, separation of bug tracking and patch review ? | 12:02 |
| persia | gerrit is usually described as "the least bad of the patch tracking solutions". I have yet to meet anyone (including gerrit developers) that acutally likes it. | 12:02 |
| persia | gtristan: Yes. | 12:02 |
| gtristan | persia, curiously, do you have a real world example ? Im curious to see that | 12:02 |
| persia | In Baserock, nothing is consuming the gerrit event streams, so we're not getting any of the automation which does things like validate the association between gerrit and a issue tracker, validation of code format or functionality, etc. | 12:03 |
| gtristan | I mean, of a project that uses gerrit and gets good mileage from it (or splits bug tracking and code review in some other way) | 12:03 |
| jjardon | gtristan: hey, thanks for the drm patch review: with that i was able to start a GNOME wayland session and seems to work okish here (I do not see the mouse pointer but maybe that's related with other issue) | 12:04 |
| gtristan | persia, right, my argument was that it should not have been applied without that, i.e. regarding unilateral changes | 12:04 |
| radiofree | gtristan: qt? | 12:04 |
| toscalix | gtristan: kde uses gerrit and bugzilla. Is that the kind of example you were askin for? | 12:04 |
| toscalix | yes, qt | 12:05 |
| radiofree | the | 12:05 |
| radiofree | https://codereview.qt-project.org/#/q/status:open,n,z even | 12:05 |
| gtristan | toscalix, Yes, I'm curious how that works | 12:05 |
| * gtristan opens link | 12:05 | |
| ssam2 | jjardon: no way to specify that except using the shell `if` and $MORPH_ARCH, at present | 12:05 |
| gtristan | toscalix, Do "users" really file bugs, btw ? | 12:06 |
| gtristan | toscalix, and would you say that it's an overhead to track discussion in a gerrit AND bug report instead of having that in the same page ? | 12:06 |
| toscalix | gtristan: kde in that regards is pretty much like gnome | 12:06 |
| SotK | gtristan: OpenStack use Gerrit and Launchpad (some parts use StoryBoard instead of Launchpad) | 12:06 |
| gtristan | in other words, users do not file bugs | 12:06 |
| radiofree | qt uses jira for the bug tracking https://bugreports.qt.io/secure/Dashboard.jspa | 12:07 |
| radiofree | which they link to gerrit | 12:07 |
| radiofree | i tried to find one that worked, but gave up, but see the "gerrit" tab https://bugreports.qt.io/browse/QTBUG-47902 | 12:08 |
| toscalix | gtristan: in a big project, where you have to maintain several versions of the same "product", conversations about bugs and development are different. So it makes sense to use different tools. | 12:08 |
| toscalix | the point with gnome and kde is that.... they take little care about previous/old versions | 12:08 |
| toscalix | so in that context... almost every activity is development | 12:09 |
| toscalix | so your view makes sense | 12:09 |
| persia | I've seen lots of groups use jira+gerrit. | 12:09 |
| persia | To be fair, KDE does maintain two ABIs all the time, but the response to most bugs against the old ABI is "upgrade". | 12:09 |
| * gtristan is looking for issues in https://codereview.qt-project.org/#/q/status:open,n,z where a patchset was actually discussed | 12:10 | |
| gtristan | and new patchsets uploaded in response to maintainer comments | 12:10 |
| jjardon | ssam2: ok, thanks | 12:10 |
| toscalix | persia: yep | 12:10 |
| radiofree | gtristan: yeah, qt actually seems like a terrible example here | 12:10 |
| gtristan | i.e., how do I see the whole picture, of why something was changed multiple times before landing | 12:10 |
| persia | Also, we had a session about this sort of thing at one of the Baserock meetups, where we decided to use mantis+gerrit, but were overridden by the fact that someone got storyboard running about 15 minutes after a small subset of us had decided on mantis, and before we were able to announce the decision at the end-of-day wrapup. | 12:11 |
| persia | (that said, I happen to personally like Storyboard, so I'm not opposed to what happened: I mostly only wish we had newer Storyboard in Baserock) | 12:11 |
| gtristan | I am not against storyboard (I have yet to see it really), but I am certainly against the version of storyboard in baserock :-/ | 12:12 |
| persia | In an ideal world, one sees the whole picture, from the developer perspective, in the patch tracker. The issue tracker only indicates that a solution (or partial solution for multi-task bugs) is under review. | 12:12 |
| gtristan | the fact that baserock is years into development, and that we have a total of 65 bugs filed, is quite telling | 12:12 |
| ssam2 | we have several older attempts at having a bug tracker which are full of dead and obsolete bugs | 12:13 |
| ssam2 | some internal to Codethink | 12:13 |
| persia | To be fair, most of that is because bugs being sent to the mailing list was the old model, and nobody every tried to capture all the old ones and put them in Storyboard. | 12:13 |
| gtristan | persia, one part of this ideal world I have a hard time with, is, only a subset of the issues which require tracking have an associated patch | 12:14 |
| persia | gtristan: Yes. As noted, the implementation used in Baserock is a poor example. | 12:14 |
| persia | I like what OpenStack is doing with Launchpad+Gerrit, but ever since Malone became only one component of Launchpad, I've found it is less useful as an issue tracker. | 12:15 |
| gtristan | This link https://code.google.com/p/gerrit/wiki/ShowCases mentions LibreOffice, I think they are pretty organized, wonder how that is working for them | 12:16 |
| gtristan | Just spent some time talking in #libreoffice-dev... | 12:40 |
| gtristan | Here is a good example: https://gerrit.libreoffice.org/#/c/20744/ | 12:40 |
| gtristan | The commit message of course links appropriately to: https://bugs.documentfoundation.org/show_bug.cgi?id=96113 | 12:40 |
| gtristan | That could of course equally link to storyboard | 12:41 |
| gtristan | Of course, this is the opposite ideal world, *most* discussion actually happens in the bug tracker | 12:42 |
| gtristan | and gerrit is used at the latest phase, when a patch is submitted for the issue | 12:42 |
| gtristan | where hardly any discussion happens, but at least the commit links to the bug report | 12:42 |
| *** tristan_baserock has joined #baserock | 13:01 | |
| * tristan_baserock types from empathy in Baserock GNOME VM | 13:01 | |
| gtristan | Aha ! | 13:01 |
| radiofree | heh, irc in baserock! | 13:03 |
| CTtpollard | :) | 13:04 |
| edcragg | awesome! | 13:04 |
| * tristan_baserock tries XMPP google chat | 13:04 | |
| tristan_baserock | awesome jjardon | 13:06 |
| *** tristan_baserock has quit IRC | 13:06 | |
| *** tristan_baserock has joined #baserock | 13:06 | |
| jjardon | gtristan: nice! :) | 13:06 |
| * tristan_baserock reaches jjardon from baserock VM :) | 13:07 | |
| tristan_baserock | integrated notifications work :D | 13:08 |
| tristan_baserock | haha | 13:08 |
| Zara | hm, does baserock have a code of conduct yet? can't find anything. | 13:14 |
| radiofree | i don't think so | 13:16 |
| Zara | :/ should probably fix that. I've been pretty impressed with the way people approach discussion in openstack; maybe we can grab theirs. | 13:20 |
| jmacs | +1 | 13:21 |
| jjardon | we have this one in GNOME: https://wiki.gnome.org/Foundation/CodeOfConduct | 13:22 |
| *** tristan_baserock has left #baserock | 13:27 | |
| persia | gtristan: Thanks for the example. I actually think that is a good example: all the useful user-facing discussion happened in the issue tracker. The first version of the patch happened to be correct and landed. Where it matters more is when a patch that is not in the right format, or fixes the bug in a way that breaks other things, or is coded in the wrong coding style, etc. lands for an issue, where these sorts of things can be discussed in the | 14:04 |
| persia | patch tracker, without confusing the archive of the user-facing issue with details of the implementation of the fix. | 14:04 |
| *** gtristan has quit IRC | 14:05 | |
| persia | When I was more involved in Ubuntu, sometimes the user-facing issue would be clear and obvious and well-reported, so that anyone capable could fix it in 5 minutes, but it wasn't high priority, so it would be marked "low-hanging fruit", which newcomers were encouraged to attempt. The problem was that the process of mentoring the newcomer to get a consumable patch required a fair number of revisions, and having that in Malone, so that the user was | 14:05 |
| persia | part of the virtual mailing list for the discussion caused significant complaint. | 14:05 |
| persia | And it's too late at night for this conversation :( | 14:05 |
| *** toscalix has quit IRC | 15:06 | |
| *** toscalix has joined #baserock | 15:09 | |
| pedroalvarez | well, storyboard.baserock.org now is running latest :) | 15:43 |
| pedroalvarez | persia: ^^ | 15:43 |
| persia | pedroalvarez: excellent! Is this a snapshot, or does it track the output of Storyboard CI? | 15:44 |
| pedroalvarez | don't get the question | 15:45 |
| pedroalvarez | is not going to be auto-upgraded | 15:45 |
| pedroalvarez | (if that was the question) | 15:45 |
| persia | That was the question :) | 15:45 |
| ssam2 | it is vastly better!! pedro brings us an early Christmsa! | 15:46 |
| ssam2 | *christmas even | 15:46 |
| pedroalvarez | the first instance of storyboard with email support | 15:46 |
| tiagogomes | I can't login, should I be able to? | 15:47 |
| persia | Yes. | 15:48 |
| *** edcragg has quit IRC | 16:09 | |
| *** ctbruce has quit IRC | 16:55 | |
| *** ssam2 has quit IRC | 16:58 | |
| *** CTtpollard has quit IRC | 17:10 | |
| *** toscalix has quit IRC | 17:23 | |
| *** bashrc has quit IRC | 17:58 | |
| *** locallycompact has quit IRC | 18:19 | |
| *** tiagogomes has quit IRC | 18:47 | |
| *** gtristan has joined #baserock | 19:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!