[Devel] Our three next releases

[Asheesh Laroia]

Excerpts from J W's message of Fri Sep 10 10:21:36 +0000 2010:
> Sorry, belated reply, just finished moving to my new place and by
> happy stroke of luck I have wireless.

And my own belated reply!

> > We haven't really done "releases" of the OpenHatch code -- when
> > things look good, we just deploy the "master" branch.
> What's wrong with that? I like instantly deployed features. Having to
> wait for a feature to be deployed because of an arbitrary label being
> applied to it seems counter productive especially for a new and
> growing website.

You made me think -- good point. Okay. (-:

Having proper releases might be a bit too intensely structured.

> > But that
> > means it's been hard to answer users when they ask us, "What's
> > new?"
> What's so hard about doing a 'got log'?
> Sure some people aren't devs and wouldn't know about that, but what's
> wrong with an rss feed of the last 5/10/20 commits to the code base?
> :)

Well, the "git log" doesn't explain the big picture. Maybe that's okay,
though. But I really like the idea of having a blog post every week or two
saying what's changed, or highlighting some neat project within OpenHatch.

But that always strikes me as a lot of work. Maybe that's just because I'm
silly. You're right -- that's a separate topic, though.

> > Going forward, I want the project to get in the habit of
> > doing more regular releases, like a "normal" open source project.
> Fair enough but I would point out that while openhatch is an open
> source project, it's also a website.  Which is more important? Not to
> create a false dichotomy, just making sure we keep it in mind.

Yeah -- I take your points. (-:

> > If you want to work on things out of order, that's okay too. The
> > nice thing about releases with themes is that if we have community
> > consensus on them, then we can identify who is interested in
> > working on what sorts of things. So long as you don't break
> > anything else, we would still happily accept patches that do things
> > that aren't in the scope of the current release.
> One of the best parts of that would be that I or anyone else keeps
> working on whatever they want to, and it's up to you to coordinate the
> release with everybody. Hmm, well it's a pro and a con I think.

Jack Grigg mentioned on IRC to me that he likes the idea of having releases
so that we can bring people into parts of the codebase that they haven't much
worked on so far.

I see your point about releases being kind of "sticky" and slowing down
deployment -- and I have no particular desire to slow down deployment!

So, a new proposal: If I want to focus work on some subproject, I'll just
send an email to devel@ (and maybe write a blog post) indicating that's
what I want to do.

And if you all want to do that, too, send such an email. And we'll figure out
if it's what we want to do, and go from there.

As for your later points...

> Why would anyone else need access?
> Do you really trust anyone else with access? Frankly, I wouldn't.
> Maybe I'm just an untrusting person.  I mean, the codebase is already
> open and available for anyone else to implement their own openhatch,
> are you intending to make _access_ to your server open source as well?
> O.o
>
> I understand and agree with your concern about the bottleneck, but I
> think the solution requires more trusted parties instead of being more
> lenient about who to trust, if that's even what you were suggesting at
> all.

Yeah, I guess I want to remove the bottlenecks that don't necessarily require
changing who can SSH in. More in a separate email.

> >  To name another  one, I'm the only one
> > who receives emails with Python stacktraces when there are
> > exceptions, making it hard for others to know what bugs the site
> > has.
> Where do the stack traces come from? Users with problems or the server
> itself emailing you it's problems when it has them? You could send
> both to the mailing list I think. At the risk of decreasing the signal
> to noise ratio. Perhaps a separate list?

The problem is, they contain session IDs, which are vaguely sensitive.

But most of the time, the session IDs don't matter -- just the stacktrace,
and that's not ever (I think...) privacy-sensitive.

Here's a bug report: https://openhatch.org/bugs/issue137

> > into the website. Maybe as people finish training missions, it
> > appears in the front page's activity feed. I'm not sure -- and that
> > decision is probably the single biggest thing holding us back from
> > removing the "BETA" banner on the training missions.
> I like that idea, its close to the achievements suggestion, trying to
> make it more appealing to do missions by gaining some kind of
> arbitrary social standing statistic.

(-:

> > In this release, I want to really polish up the training missions
> > we have and invite people to write new ones.
> >
> > Version 6: Automatic adding of bug importers
> > --------------------------------------------
> >
> > Jack has been doing awesome work on the bug tracker importers. He
> > even wrote a simple web interface to let project admins add bug
> > trackers automatically. It lives in the "next" branch.
> This I have to see..

$ git fetch
$ git checkout origin/next -b whoa_its_amazing
$ ./bin/migrate

(-:

> > I want to have versions 4 and 5 done so that we can focus on
> > getting that going. It would be totally awesome if we can stop
> > telling projects to add sections to the wiki, but instead let them
> > add bug trackers and then watch them get crawled automatically.
> >
> > In this release, I want to make it super easy for people to add
> > their projects' bug trackers to be crawled by OpenHatch.
> Openhatch doesn't do github or ticgit or ditz yet. This makes me sad
> on the inside. ;-)

Does that mean you'll help add them? (-:

> > The Distant Future (like, October, hopefully)
> > ---------------------------------------------
> >
> > I think it'd be great to have one more tech-focused release. In
> > particular, I want one focusing on performance and scalability (the
> > map is famously slow, and the whole site could be a bit snappier).
> Understatement of the century. Love the site but sometimes I pull hair
> out waiting for it to load.

Zing, okay!

-- Asheesh.

-- 
As to the Adjective: when in doubt, strike it out.
		-- Mark Twain, "Pudd'nhead Wilson's Calendar"