swaldman: A cute fluffy sheep curled up dreaming of Dreamwidth. Labelled "Simon: Bodger". (dw-dev)
[personal profile] swaldman
Nice flowchart here.

It's not new, but I haven't seen it here before :-)
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
Forgot to say -- if you forget to claim a bug formally, but you submit a pull request that refers to that bug using the "#123" format in a commit, then that will also automatically assign the bug to you.
kaberett: A sleeping koalasheep (Avatar: the Last Airbender), with the dreamwidth logo above. (dreamkoalasheep)
[personal profile] kaberett
I've synthesised discussions about and practical use of GHI into a single wiki page. Please shout if you want anything added or changed!

I've also gone through and replaced as many references to Bugzilla with references to GHI as (1) makes sense and (2) I am immediately able. There's about 20 pages still on my hit-list, not all of which I have the knowledge to deal with - if you feel like pitching in, please take one and let me know when it's done (or, if you don't have wiki access, let me know what the appropriate edits would be).

List of pages outstanding )
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
We discovered that you have to be a committer on a repository in order to claim a bug for yourself on Github. If you're not one, you have to ask someone to assign the bug to you.

This didn't really seem feasible, so we've fixed it. You can now claim an issue by leaving a comment with the words "claim", "claimed", or "claiming".

Case doesn't matter -- you can use capital letters if you want. You can also have other words be part of the comment, so you don't need to memorize a specific format. "I'm claiming this" will work just as well as "Claimed!".

Claiming will only work if the current issue is not yet claimed -- this will avoid the problem of accidentally grabbing the bug from someone else during a long discussion about claiming something else in a different context.

You *do* need to be part of the Dreamwidth contributors team on Github before assigning issues will work so we've gone and added everyone who's been active in the past year (if you got an email from Github welcoming you the Dreamwidth contributors team that's what that's about!). If you're a new contributor, you'll be automatically added when you give your CLA to [staff profile] denise.

For existing contributors, do double-check if you're on any of the Dreamwidth teams. If it shows you a list of teams you're on, you're good! If we missed you somehow and tells you that you're not on any teams, let us know and we'll add you ASAP.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu

We have two main branches in the Dreamwidth repositories: master and develop.

master was intended to be used but... never really got any love.

So here's what I propose: remove all the instructions in our documentation which mention master, and just have 'develop`.

Since develop is where all work goes, nothing in the dev workflow will officially change. But occasionally we have accidents where master gets merged into developinstead of the other way around, or someone finds themselves on master when they should be on develop instead -- and removing any mention of master from our instructions should prevent that from ever happening again.

As for what will happen to master... we never actually used it, and at this point ingrained habits for develop + all setups old and new assume develop, so I suggest we continue not using master the way we currently do.

kareila: "Mom, I'm hungry." "Hush, I'm coding. You ate yesterday." (coding)
[personal profile] kareila
Hi all! During Saturday's dev chat, one of the discussions that came up was the current status of our work on improving the process of using Github Issues as our bug tracker.

Here is where we are right now:

It is now possible for anyone to use inline text tags to categorize new issues. [personal profile] fu has put up a rough draft of the instructions for this process, along with a list of the labels that are currently recognized. We are also planning to allow issues to be "claimed" in a similar manner, although the format for doing that hasn't been finalized yet.

Another part of Github Issues that we've been experimenting with is the use of milestones. If you look at the milestones on dw-free you can see, for example, the status of open bugs on certain major projects like Foundation and mobile styles. I think this could be really useful, especially in light of recent comments saying that we haven't been doing a good job of communicating the progress of our major development projects within the development community.

There are also other milestones currently displayed on that page such as "unclaimed", "curated", and "in progress" - a lively discussion ensued as to whether these would be better used as tags instead of milestones, and I'd like to continue that discussion below. The main issue with milestones on Github in general is that a bug cannot be assigned to more than one milestone. From a workflow perspective, we would expect to see a progression of untriaged -> unassigned -> claimed/in progress -> pull request -> closed, and the fact that an issue cannot exist in more than one of those states at a time makes it a good candidate for the use of milestones - but could conflict with using milestones for the purpose of tracking large projects.

There was also a great deal of confusion as to what "curated" was supposed to mean in this context. [staff profile] mark said what he desired was a list of three or so "top priority" unclaimed bugs, so that he could easily decide what to spend his limited time on. Again, this may be a better candidate for a tag than a milestone, and maybe with a label that is easier to interpret.

The last issue mentioned is that we still haven't come up with tags for indicating which area of the code is involved with a bug (e.g. styles, notifications, etc.), which is something we relied on pretty heavily with our previous Bugzilla setup in order to find new things to work on.

Please continue the discussion in comments!
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
1) People who do not have write access to the repo can't change labels or milestones, so ignore all the bits about changing labels and milestones in yesterday's entry. Somebody with commit access will have to add the labels and change the milestones when an issue is submitted and when somebody decides to start working on an issue.

2) We did discover that it's possible to assign issues to people once we add them to a read-only team membership of the repo. I've added people who have open pull requests and assigned the issues they're working on to them.
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
This entry will be stickied in [site community profile] dw_dev for at least a few weeks; please point people at it if they haven't seen it!

Apologies for the delay on writing up guidance on this, folks; we were wrangling out the last of the details. (Or rather, we were wrangling enough of the details for me to make this post; I'm sure there are multiple remaining details unwrangled, which we'll figure out as we go.)

Starting now, and thanks to Bugzilla's sad demise, we will be starting a trial period of using Github Issues to keep track of our bugs. It's possible that it won't work out for us, but right now the downsides are outweighed by the very strong advantage of having everything in one place and the heavy integration.

We will not be importing the entire Bugzilla database, for two reasons: one, putting together something to port over all the data is effort that would be best spent elsewhere, and two, it's been a long time since we've been through the list to cull things that are no longer features that are no longer needed and bugs that are no longer manifesting. We decided that starting fresh with a blank slate and only entering things as they come up will be a good way of making sure the list is only full of relevant things.

This post will be about two things: how to log bugs and how to find bugs to work on. There will be a future post on how a particular item (issue) will move through the workflow with you; we have a few last little things to clear up there first, but I wanted to get this posted as soon as possible so people could start work again.

Of note:



* Please only use this process for code-related bugs. We're not yet 100% certain what the process for docs bugs will be. For now, if you spot a FAQ that needs to be changed or needs to be written, report it with a comment on this entry in dw-docs.

* DO NOT use this process for security bugs. If you think you've found a security bug and want to report it, email webmaster@dreamwidth.org (private support category) and we'll take it from there.

* Part of this transition involves declaring total bug amnesty. If you had a bug assigned to you in Bugzilla, and decide that you don't want it anymore (or if you've forgotten about it completely), you're off the hook. (Not that you couldn't have been off the hook at any time anyway, but I know how hard it is to admit defeat sometimes.)

* On the other hand, if you had a bug assigned to you in Bugzilla, and you're still working on it or were almost ready to submit a pull request, we still want it! Open a new issue in Github for it and carry on.

* Just because we're not making a concerted effort to migrate every open bug from the old Bugzilla database doesn't mean that we don't want bugs to be re-reported. If you logged a bug in Bugzilla (or remember a bug from Bugzilla), and the bug is still happening and still annoying you, please open an issue for it. I will be trying to go through the last year or so of still-open bugs from Bugzilla to find "bugs that are still bugs" and re-create them, but I can't guarantee how long it will take me and I'd rather the bugs get logged sooner than I can commit for-sure to doing it, especially so that we have a nice collection of stuff for people to pick from if they just want to pick something up and hack.

That having been said:

Logging bugs )

Finding bugs to work on )

There you have it! It will probably take a little bit of getting used to (I know it took me a bit to figure it all out) but -- having gone through the process a few times in the course of figuring things out -- it really is very straightforward once you start doing it. The biggest gotcha, I think, is going to be remembering to set the milestone for all the unclaimed bugs. (That's part of the reason why we're considering using labels for that functionality instead of milestones; there are benefits and detriments to both. Fu and I will decide in a week or two once we see how a small scale test works out.)

Please take this chance to log all the bugs you're still working on, and all the bugs you can think of as still affecting you, over the next few days! Once that's been done, I'll start going through the various "upkeep" tasks (new themes, new embed sources, etc) and add those, then start working through the [site community profile] dw_suggestions posts tagged "bugzilla: migrated" to see which ones should be moved over to GHI.

([personal profile] ninetydegrees, I know you have spreadsheets for themes that were in Bugzilla and not yet patched; if you want to add those, that would be awesome, but if you don't have the time/energy, I will get to them when I fill in the various "is: upkeep" things.) (Also, I will explain the "is: upkeep" and how that differs from other "is: foo" tags in a few paragraphs!)

Again, I'm sorry for my delay in writing up the guidance for What We're Doing With This -- things took a little more discussion. Thank you all for being so willing to roll with things and try out new workflows.

If you run into questions as you work, just holler.

Appendix: What the labels mean: a work in progress )
swaldman: A cute fluffy sheep curled up dreaming of Dreamwidth. Labelled "Simon: Bodger". (dw-dev)
[personal profile] swaldman
~/dw (develop)$ git status
# On branch develop
# Your branch is ahead of 'upstream/develop' by 540 commits.

Did we ever figure out what causes this? I have a theory, but I don't really understand...

(Theory: the dwu script does "git pull --ff-only upstream develop" straight from the remote repo into the local develop branch. This doesn't update the local copy of "remotes/upstream/develop" that was created by a "git fetch" sometime in the past. This is what the current branch is being compared to. I have no idea whether this makes sense, and if so how to deal with it...)
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
[staff profile] mark

I've created release-1.17 branches in both repos in preparation for tomorrow's code push. If you have anything you really want to land in tomorrow's code push, please let me or [personal profile] fu know and we'll see if we can get it in before then.

This frees the develop branch for continuing development. Anything that lands there will be slated for release in the NEXT code push (which will hopefully be next week, on account of next week being OSCON, and our typical enjoyment of Conference Driven Development).

foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
So, sometimes Bugzilla can be slow to reference/search, or sometimes you want to break up a bigger bug into a set of tinier bugs without cluttering up Bugzilla or making a bunch of comments to your bug in Bugzilla that you then have to manually scan for information.

Your personal GitHub fork can have its own simple bug tracker! Log in, go to your fork of dw-free or dw-nonfree, and find the settings in the button bar. Go check the box next to issues. Voila! You now have a very simple, fast issue tracker you can use in a way that is most convenient to you. The link to the issues interface will be a button in the toolbar. Here's mine so far:

https://github.com/foxfirefey/dw-free/issues

You can note that I'm putting the Bugzilla bug number in the header of each issue, just so I know what bug each issue belongs to. I have also made myself a milestone for the next code push (tomorrow!), so I can filter down to which issues I want to have finished by then.

You can also check the wiki box to have your own personal wiki notebook for taking your research notes that aren't relevant to anyone else by checking the wiki box on that settings page.

I hope this is useful for you! I'm thinking it will be very useful for me.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu

There are two ways to leave per-line comments when reviewing a pull request:

  • opening up each commit in a separate tab and going through them one-by-one (commits are listed in both the Discussion and the Commits tabs)

  • going to the Files Changed tab, and seeing the entire final result

I used to open up each commit individually, but:

  • if the person is forced to rebase (either to get rid of extra commits, or to clean up their history), the discussion is lost

  • under the discussions tab, there's no context, just the comment, which makes it possible to know that there's activity going on, but very difficult to keep track of exact context

  • it's possible that something you reviewed in one commit was fixed later on in the commit series, invalidating your comment

  • in the email notification, the "view it on github" link shows you the commit, not the associated pull request (and there's no easy way to find which pull request a commit is on, given just the commit)

I'd been ignoring the Files Changed tab for some reason, but I've now found that they actually don't have any the disadvantages of the per-commit view:

  • if the person is forced to rebase, old discussion is preserved in the pull request. If the rebase altered the diff, you'll get an "comment made on outdated diff"; if the diff is the same after a rebase, it shows up like it did before

  • under the discussions tab, it shows the context of the diff you're commenting on, along with your comment, which makes it very easy to keep track of the exact reason a comment was made (especially on short comments hehe)

  • you see the final version of the code that's being submitted

  • in the email notification, "view it on github" links to the pull request where all the discussion is taking place

All this is to say that if you're poking around and want to comment on something you see in someone else's pull request (and we do encourage code review in this manner!), use the Files Changed tab. It's much more useful.

Some examples:

  • actual pull request where you can see how easy it is to tell that a review comment has been handled (and what still needs work, or what doesn't need to be changed after all)

  • test pull request where I committed a change, commented using both the commit/files changed view, rebased+force pushed the rebase (which blew away the comment on the commit, but retained the comment on files changed), and then made the diff outdated -- which collapsed the discussion but still kept it visible

foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
I just had to figure out how to make a branch I was developing be based on the "develop" branch instead of the "master" branch. The command to do this ended up being, as far as I can tell:

git rebase --onto develop master Bug3426/editotherstyles

The advice that finally made sense came from this guide and was explained thusly:
git rebase --onto topicC topicA topicB

Where topicC is the newbase, topicA is the oldbase, and topicB is the reference for what HEAD of topicC will become.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
I had some weird behavior on my computer (running Mac OSX), because we had an image file named Sinisteria.jpeg, and another named sinisteria.jpeg, so I committed a fix.

Depending on your OS, you may need to run an extra step next time you upgrade. You'll need this for Mac OSX for sure, I can't remember how Windows and Linux deal with case in filenames.

Pull in updates as usual. This will delete Sinisteria.jpeg (uppercase)

$ git pull

Updating ecc1d71..7cb6ab7
Fast-forward
htdocs/img/styles/paperme/Sinisteria.jpeg | Bin 786 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 htdocs/img/styles/paperme/Sinisteria.jpeg


Then check if you accidentally deleted sinisteria.jpeg (lowercase)

$ git status
# On branch develop
# Changes not staged for commit:
# (use "git add/rm ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# deleted: htdocs/img/styles/paperme/sinisteria.jpeg
#


If you didn't see the "deleted: ..." bit, you're fine. No need to do anything more.

If you do see the "deleted:..." bit, then do this:
git checkout -- htdocs/img/styles/paperme/sinisteria.jpeg

Now check again to make sure that worked:
$ git status
# On branch develop
nothing to commit (working directory clean)


Done!
foxfirefey: A picture of GIR. (gir)
[personal profile] foxfirefey
So, as far as I can tell from my researching over the past few days, the only real way to get a pull request to review it is to:

* Manually add the submitter's dw-* repo as a remote in the repo on your hack (or Github I suppose, but there is no GUI advantage here).
* Manually pull the branch in question

Is there a better way to do this? Am I missing something? This seems really, well, annoying, with manually crafting URLs and whatnot, and not very user friendly. (I'm trying to make some documents on reviewing pull requests for people who are not [personal profile] fu, since we need to try and spread out that work a little.)
foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
They've been being hit by DDOS attacks--so if you're trying to do something with our Github and it isn't responding, know that this might be the cause!
foxfirefey: Fox stealing an egg. (Default)
[personal profile] foxfirefey
For the folks who like digging into things like this: codeq (warning: Javascript generated blog page, ew)
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
We still want to buy you books, and since this week O'Reilly is having a sale on resources about Git (our new version control system), we'll even buy you more than one of them if you spot stuff that you think will help :)

Browse the list of eligible titles (or the wider O'Reilly catalog) and if you'd like a copy of the book or the videos, let me know: we'll buy you that plus another title. (Maybe a book on Perl, or Javascript, or jQuery, or UI design, or or or...) I'm trying to figure out a way with O'Reilly that will make it easier for us to pay for ebooks that are then delivered to your O'Reilly account, but in the meantime, we can either do it where you buy it through your O'Reilly account so you can have future access to it and we'll write you a reimbursement check, or I buy it through my O'Reilly account with the DW card and send the file to you. Or you can get the hard copy, of course, if you don't want an ebook version; it's up to you.

Either way: let us buy you stuff! People have been really hesitant to take us up on this, but I promise you, we really want to, and if you meet the criteria (5 patches in last 12 months, at least one in the past two months), we mean you even if you think you haven't done 'enough'.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
As of this code push, we're using the Git repository for our code on production. If you haven't moved your own repositories over to Git yet, you should soon!

[personal profile] foxfirefey has a handy list of resources for the Git transition.

We just had our 101st pull request to the dw-free repository over on Github! Two of those were test pulls, but the others are all legit ;-)

The dw-nonfree repository, on the other hand, has only had 14 pull requests. Since we don't really want much here other than branding stuff, this is as it should be.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
Quick note:

We'd like you to use your Dreamwidth username / email when committing. This makes it a lot easier for us to track who did what in the future. It also helps us match the author of the commit with who you are, and lets us confirm that we've received your CLA.

Edit your config (~/.gitconfig) and add this section:

[user]
name = USERNAME
email = USERNAME@dreamwidth.org


Then add your USERNAME@dreamwidth.org email to your Github account, so that the commits on Github will link to your identity on Github.

Please don't forget to tweak this setting on both your local computer and your Dreamhack if you do commits on both. Thank you!

If you're working on other projects, you can also just edit your author identity in just the Dreamwidth repositories (Thanks [personal profile] shadowspar)

Profile

dw_dev: The word "develop" using the Swirly D logo.  (Default)
Dreamwidth Open Source Development

April 2017

S M T W T F S
      1
234567 8
9101112131415
16 1718 19202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Apr. 29th, 2017 07:35 am
Powered by Dreamwidth Studios