[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] Problems with the gpsd website move

From: Ed W
Subject: Re: [gpsd-users] Problems with the gpsd website move
Date: Mon, 27 Feb 2012 11:17:54 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2


When I say "same system", I don't mean same hardware host.  I mean
that I want the pieces to talk to each other, in ways that only
a dedicated forge does or can.  For example: on either Savannah or GNA, when
I push a commit with a log message that mentions a bug identifier #nnnn,
the log message of that commit is added to the tracker comment thread
for #nnnn.

OK, that I can tackle. What you ask seems like a reasonable goal. In fact it also seems to be a very hard task to achieve, google seems devoid of a long list of strongly integrated solutions. Of those that I am aware of, excluding github itself, the main one I have been tracking is Redmine, which is a kind of Trac system but with good git integration. Trac is alleged to have a workable git feature if you hack it around a bit?

However, exactly what you have asked for is *why* a bunch of projects have started switching to github. Github has what appears to be a very decent issue tracker *with* integration into your git commits

For example, here is a random issue from the Rails project (just the first closed issue I clicked on in the list)

Here you can see individual users, comments on the issue, quick links to patches suggested to fix the issue. And if we click into the final commit we can see the actual commit which is used, and from that commit we can reverse back into the issue tracker itself:

Another thing I want is for devs to have one canonical ID that is
used everywhere in the project metadata and message queues.  That
gets broken if the project services are scattered over different
machines with different logins.

Well, you would have one canonical id for everything except email under my suggestion. Also it would be *possible*, but not guaranteed that you would have the same ID for email also - that will be down to the developer's individual choice.

So phrased another way - if the developers also agree with you that one canonical ID is valuable then they *can* use a single ID for the entire shooting match, code, mails, issue tracking, etc. This seems to hit the desired end result?

Yet a third thing I want (and *nobody* gets this right; it's a main
reason why I think I'm going to have to build a forge that doesn't
suck) is not to have to have separate credentials and a separate
authentication procedure for editing forge metadata and managing
mailing lists.  Mailman has allowed forge designers to take the
lazy way out for too long.

If you are saying that uses mailman, then I think it's clear you loose nothing by switching away? By definition this would mean that the mailing lists are already separate from the rest of the credentials?

Therefore it appears to be somewhere between better and "no difference" to switch to github since your mailing list integration gets no worse by switching?

For mail the options seem to be:
- Run your own mailman (etc) service
- Get some big provider to run the mailman service, eg nongnu,, berlios, etc - Get some suspiciously commercial provider to run the mail service, at least they have experience, eg google groups

Pick any - none seem to offer tight integration with your git server (nor do I personally see any benefit in doing so?)

Google groops is a spam-ridden shitpile that I won't touch.  But
that's a detail.

I think personal experience probably skews things a lot here. I don't see any intrinsic reason why there should be more or less spam directed to a mailing list at any big aggregator?

In the past it's been popular to write bots to signup to all the mailing lists at all the big hubs. I dare say that google groups is an interesting target in the same way.

Personally I see very little spam on all the mailing lists I read. Looking now I see that quite a lot are run with @googlegroups mailing lists. I don't obviously note more or less spam to those groups. In fact I would say that all have near vanishingly small levels of spam...

It's clear that you will need some kind of active spam management on ALL mailing lists since they are clearly targets for abuse, but I don't have the experience to say whether those measures vary between "hubs". What I can observe as a downstream user is that a) a LOT of people are using google groups for mailing lists and b) I don't see a lot of spam from any hubs these days, so there must exist some way to throttle it substantially?

The real problem is that you're increasing the number
of per-project identity keys for a dev from two to three when it
really ought to decrease to one.

That's NOT the case though.

Nongnu appears to need: a) SSH key, b) nongnu login, c) mailing list id

This is exactly the same number of logins that you need with my proposed solution. In fact for many people the number of *additional* logins *decreases* since a staggering number of people have Live, Google, Yahoo logins tucked away for various purposes already, and an increasing number of developers already have github accounts for interacting with arguably the largest "forge" of them all

Is that not compelling?

Roughly we can see it as forge A vs forge B. Features of B are arguably superior, only it's missing tight integration with mailing lists, something that forge A only has weak integration anyway

Sounds to me like you've never run a project and never had to wonder
"who is that?" when somebody wanders on a mailing list or IRC, email address
only, using a different identity than the one on their forge credentials.
Even on a project as small as GPSD this causes me confusion sometimes.
Balkanizing identity keys has real costs that blow up quadratically with
the number of devs and multiplicatively with te number of identity spaces
you have to match.

This sounds like one of those theoretical problems?

The linux kernel seems to be getting on ok. They *encourage* that your git commit email address is the same as your mailing list handle. Although this isn't enforced it seems to work. There is no obvious reason you couldn't encourage the same on your project? This would largely seem to reduce the number of IDs to 1 (no matter which forge is used), although it does require cooperation from developers (but on the flip side it's a convention that is used quite widely for lots of projects)

It seems like you could migrate to github by:
- Download existing html site into your local src code directory
- Put html site under git version management
- Create new github page
- Git push the html up to github
- Git push the main src code up
- Setup issue tracking if you want it
- Err... apart from finessing the above, and setting up redirects, I
think that's actually about it?
No.  How do I set up hooks for commit notifications?

You have limited hooks here:

However, what are you using hooks for at present? Perhaps there is another way to solve the same problem?

Where are my
mailing lists?  Why aren't they properly integrated with the

Just like right now, the mailing lists are external in either mailman or google groups. This doesn't seem to be any worse than the current situation?

However, I really don't see the problem. *Management* of the mailing lists (ie the small number of people who control the list) is hopefully an infrequent task and just a case of clicking into some webpage, where your browser should remember your credentials and you move on and do your thing. *Usage* of the mailing list will always be down to users themselves who are quite free to pick some credentials that don't match their git credentials

However, whilst the above is theoretical, the trend is that geeky developers tend to cluster behind a small number of email addresses and can largely be identified by a small number of IDs, ie that/those email addresses.

Keen to help you find a good solution, but I don't see how switching forge to github (as an example) doesn't improve the status quo. All that you loose is that the management of the mailing lists is at a different domain name to the code. This is a) fixable if you care, and b) who cares?

It's easy to find massive, well known projects on both Github and gitorious - why not check out how some of those projects conduct themselves and see if there aren't some useful experiences there?

Does that help?

Ed W

reply via email to

[Prev in Thread] Current Thread [Next in Thread]