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

[Ed W]

Hi

> 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)
    https://github.com/rails/rails/pull/5185

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:
    
https://github.com/rails/rails/commit/551566db06f54f35aeadaa320ef073ea1335ad60


> 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 nongnu.org 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, SF.net, 
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:
    http://help.github.com/post-receive-hooks/

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
> bugtracker?

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