gmane.comp.gnome.gaim.devel

Re: [ANN] pidgin git import v5

John Bailey — 2012-05-25T23:47:03

The vast majority of our analysis was conducted in a conversation in the
devel< at >conference.pidgin.im XMPP MUC.  This has been pointed out before.  Since
I'm the one responsible for the discussion, it would have been my responsibility
to provide some sort of log or summarization.  I do not log chats, so I had no
logs to post or summarize.  This discussion is the one in which we threw out
options like darcs, bzr, etc.  If this is a sticking point for anyone, there's
nothing that can be done about it now.

As I recall, the general consensus we reached from that discussion was that both
git and hg were sufficient for our needs.  Sure, each has interesting, unique
features that the other does not, but both tools meet our core needs, which for
the record were:
* Distributed, with capability to have a central "official" repository
* Faster than monotone
* Less of a bandwidth hog than monotone
* Supported in more tools than monotone
* Capable of supporting our workflow
* Able to convert our monotone database (

Merging master password branch...

Elliott Sales de Andrade — 2012-05-25T20:13:59

Hi all,

We should probably get around to merging this stuff... It does
compile, and run in some fashion, at least. I haven't really had to
modify it much lately, so I'd like everyone to take a look at some of
the API changes before merging. I'm mostly concerned with the
libpurple changes. For the rest, you can just check out monotone.

The following are high-level sorts of things or specific comments.
Please check monotone for the details.

accounts.h
* Add `cb` and `data` parameters to `purple_account_[gs]et_password`
for the caller to be notified when a password is truly saved/read. I
don't think any callers use the saved-cb though.

connection.h
* Add `gboolean purple_connection_had_error(const PurpleConnection
*gc);` -- Seems a bit of a hack to me based on the name. I'm sure it
can be done better.

plugin.h
* #define PURPLE_PLUGIN_FLAG_AUTOLOAD  0x02 -- Can't we just do the
same thing the SSL plugins do?

New Keyring API:
* Header comment points out that some GError's may not be useful. We
don't really

Re: [ANN] pidgin git import v5

Felipe Contreras — 2012-05-25T09:57:45


Let me ask you this; why do you think Adium did release an analysis
for their options?[1]

Why Adium selection was all about can and can'ts, and Pidgin selection is not?


IOW; the result of the "analysis" boils down to "we like hg". How is
that different what I've been pointing out?


Of course that's it, but this is a tautology; Pidgin developers are
going to choose what they are going to choose, what else would they
do?

At the danger of sounding belligerent (let me assure you that's not my
intention), I propose you follow this thought experiment; lets suppose
in a parallel universe the Pidgin developers did not do *any* of their
due diligence while choosing their next SCM; how would that universe
look like? Would it be very different? What is the proof that we are
not living in such a universe?

When you say "It's about what the majority of current, active
developers on the project are using", it doesn't look like there was
much due diligence involved.

But before you assume this is an act of aggressio

Re: [ANN] pidgin git import v5

Eoin Coffey — 2012-05-24T23:29:52

I've been an observer on this list for a good long while now, and I've
seen this thread come up a lot.

Are there good reasons to pick git? Sure
Are there good reasons to pick hg? Sure

Are the complements of the two feature sets big enough that you've
crippled a project one way or another regardless of which you choose?
I don't believe so.

So making arguments about *how* git *can* do this, or *technically* hg
*doesn't* do this one thing "right" is all well and good, but they're
occurring in a vacuum.  This is not about parity and theoretical
"can"s and "can't"s.  It's about what the majority of current, active
developers on the project are using. If that means hg, well that's it
I guess. Or monotone, that's cool too. I mean isn't one of the BSDs
still releasing quality software with CVS?

I love git, and use it at work and for personal stuff, and I think
it's brilliant.  And Felipe I get that you love it to, and you want so
bad to spread it's gospel, and you feel very passionately that it is
the ultimate r

Re: [ANN] pidgin git import v5

Peter Lawler — 2012-05-24T23:11:30

Blatantly false. Your motive is highly relevant as any analysis produced
would have to meet your standard. Thus, whoever produced such an
analysis would have to consider not just what you want but why so that a
full, detailed and exacting paper could be produced to satisfy your
demand for such a paper.

<snip>
Seems like a request to me.

Once again, you're requesting an analysis be provided whilst
simultaneously claiming you're not requesting anything. Your repeated
attempts to bully and intimidate volunteers to doing is disgraceful. It
would appear that you are shameless.

You're the person who wants this thing done. You've not convinced me,
nor it'd seem anyone else on this list, of a need for me to lift a
finger to do this thing for you. You then passively suggest that the
decision is bad.

You're allegedly not requesting anyone do anything, then request someone
to do something, then say that you won't do it yourself, and the thing
you're after wouldn't help anyone anyway.


hahahahahaha ... hahaha

Go

Re: [ANN] pidgin git import v5

Felipe Contreras — 2012-05-24T21:34:26

Red herring: appeal to motive; my motives are irrelevant, the analysis
is still missing.


I am not requesting anything, I am merely pointing out the facts, and
the _suggestion_ is obvious.

In case you missed the text you are replying to:


All you have to do is say "We will not provide an analysis", that's it.

Of course, you know how bad that sounds, and it's understandable that
you are reluctant to say so, but that should prompt you to provide an
analysis, not to avoid the fact.

Since nobody has stepped forward and said so, I wanted to leave it clear
for the record. That's all.


You want _me_ to provide an analysis of why pidgin developers are
choosing mercurial? I don't think anybody can provide such analysis and
leave the decision in good light without missing some important
information. Feel free to prove me wrong.

I might come up with sucn analysis, but I doubt it would help anyone.

In any case, I'm not interested in discussing my motives, or my agenda,
or any other red herrings. I believe there

Re: [ANN] pidgin git import v5

Николай Антонов — 2012-05-24T20:40:47

24.05.2012 00:57, Peter Lawler написал:

I am unhappy too:
5 month have passed, but sources didn't moved to hg/git/svn!
I do not want to argue about hg vs git... but please migrate!
Monotone does easy things not trivial.
Users/developers shouldn't think about database, monotone version, 
path's... etc. Just "XXX clone URL" and work with code!


// sory for my english

_______________________________________________
Devel mailing list
Devel< at >pidgin.im
http://pidgin.im/cgi-bin/mailman/listinfo/devel

Re: [ANN] pidgin git import v5

Peter Lawler — 2012-05-23T20:57:06

IAJACPW, but from my reading of the threads in January it seemed to me
that a bunch of points were gone through, a decision was taken to go
with .hg.

You, and only you, seem unhappy with the decision taken and then called
for an in depth analysis. I don't think that it'd be unreasonable to
conclude that this is because you're unhappy with the decision and you
want the decision to go to hg to be changed. I would ask you, if you -
or anyone else - were to produce such an analysis and hg was still
chosen, what would you request then?

On this point, I note that it's been around 5 months since you mentioned
wanting to see an analysis. No one else on the list seems to have cared
for one, with or without as much passion as you have. I encourage you to
produce one ASAP.

Regards,

Pete.

Re: [ANN] pidgin git import v5

Felipe Contreras — 2012-05-23T20:35:41

Discussed yes, analyzed in detail and carefully list the pros and cons
of each option--no.


I have read that thread yet again, and these are all the points I see:

 * Adium uses hg
 * Instantbird used hg
 X hg supports subrepo (libpurple won't be splitted)
 X git branches are braindead (not substantaited)
 * git supports committer
 X TortoiseHg (TortoiseGit)
 X I prefer X (that's not an analysis)

These points are not summarized anywhere, and the closest thing to a
summary is this:
http://pidgin.im/pipermail/devel/2011-January/010083.html

Of course, there's no real summary of the points, just basically counting votes.


So in summary there's no *real reason* for choosing mercurial, other
than more people like it.


The "developers" have changed since the last voting, and would
continue to change, which is why it's important to come with a better
reason than "we liked monotone".

You can certainly leave that as your reason, I'm merely pointing out
that it's not a strong one, and many newcomers would find t

Re: [ANN] pidgin git import v5

Richard Laager — 2012-05-23T17:43:21

This has been discussed publicly on the mailing list.

I think this thread has most to all of the points raised:
http://pidgin.im/pipermail/devel/2011-January/010062.html

Summary:

We don't see huge differences between the two and would like to provide
both repositories to accommodate the preferences of patch submitters.

Given that, there's really only a question of which one is the
"official" trunk. That decision affects "developers" (upstream
committers) only, and most prefer Mercurial for some combination of A)
it's what they're used to, B) they like its history model (especially
branching) better, and/or C) they like the human interface with the tool
better.

Also (and this is a small advantage), both Adium and Instantbird use
Mercurial. Adium, at least, has a copy of libpurple in their tree, so
using the same repository format gives them the option to either rebase
against our repository or, more likely, easily use it as a subrepo (what
git calls a submodule). To be fair, if the "official" repository

Re: [ANN] pidgin git import v5

Felipe Contreras — 2012-05-23T12:28:57

Since you skipped the relevant part, I'm just going to state it for
the record: the Pidgin project does *not* plan to have a publicly
available analysis for the rationale to moving to mercurial like other
projects have[1][2][3][4].


How are they not helpful?

Current situation:
  You move *everything* to mercurial at date X, one week later you
find a mistake in the conversion; you are screwed. No changes are
allowed, ever.

Situation with git:
  You split the repository into the old, and the new commits, you find
a mistake in the conversion of old commits, you fix it, and the new
history doesn't change.

That is a *huge* difference.

Say Jorge doesn't want the full history, so he only clones the new
repository, say you want the full history, so you run the
'./get_full_history.sh' script, and then you have it. What is the
problem?

And supposing you want *everyone* to have the full history, then
simply add the required commands to './autogen.sh'. Problem solved.


Good.


The convention is up to you, as lon

GSoC 2012: Android port

Michael Zangl — 2012-05-23T11:05:10

Hello,

I was accepted as GSoC student to do an Android port of libpurple.
The original proposal and a planned timeline can be seen here [1].

The last two weeks I was mainly trying to get everything to build, and
after many hours of trying, patching, configure-scripts-reading and
waiting I got all dependencies of libpurple to compile and finally
libpurple itself.

The basic class structure is already in MTN, but there are no function
implementations. Methods marked as native are extracted to header files
to be implemented and enum constants from C files are autmatically
converted to java source files so that they can be used from java
without any manual hacking. This makes enum conversion a lot easier.

There ist already a documentation on how to set up a development
computer. In the end of the project, I can do a release so that not
everybody who wants to use the library in his projects needs to compile
everything from scratch and install all those tools.

Next week is mainly getting the Android SDK to pac

Re: [ANN] pidgin git import v5

Richard Laager — 2012-05-23T03:53:23

Yes, that can be dropped.


In my opinion, grafts don't really help much because you can't push/pull
them (or has that changed?).


I believe that's the plan.


I don't think anyone questions that we should use this, when we have
this information.


If this is all the information one has, I think it's just plain wrong
that git forces you to add additional bogus information. But since it
does, this would be the convention, correct?

john <john< at >snow.com>
John Snow <unknown>

Re: [ANN] pidgin git import v5

Felipe Contreras — 2012-05-22T10:42:01

Hi,

On Mon, May 21, 2012 at 8:17 PM, Richard Laager <rlaager< at >wiktel.com> wrote:

In general yes, but Monotone-Date is useless for example (unless you
think 'mtn git_export' would have a bug regarding dates, but this was
tested quite extensively and would be very unlikely).

But in any case, I didn't notice any increase in the repository size,
so shouldn't be a problem.


The hack was quite easy; simply adding the branches by parsing the
first 'Monotone-Branch' text found. Since hg-git already has the
functionality of parsing extra data from git commits by reading a
'--HG--' section.

Probably a bigger hack would be needed to convert mtn/git ids to hg
ids, so I'm thinking on having the whole thing in a separate branch
with hacks and everything so it's easy to run. But to be honest, I'm
not willing to spend a lot of time on making the git->hg conversion
production ready, I mostly did that as a proof of concept.


There's a few new authors that need mapping. Looks like nobody
followed my advice to keep author

gsoc12 : pidgin plugin website

Nikhil Bafna — 2012-05-22T07:21:16

Hi.

I am Nikhil Bafna, a 4th year undergrad at BITS Pilani, India.

I am one of the 4 selected gsoc tudents to work with Pidgin this summer. My project proposal is "Building a Pidgin Plugin Website, from where user can easily discover & download plugins for their platform and rate & review them as well, intuitively. Developers would use it upload, modify and delete information about their plugins, maintain change log and get feedback from the user community."

The complete proposal for the project can be viewed here.

The period of coding for GSoC officially started yesterday, 21st May and will continue up to 20th of August. Throughout this period, I will post weekly updates on my work :-)


To provide a brief sum down of the project, I will be coding it in python + django + postgre. I have divided the project into 5 major chunks -

User frontend
User backend
Developer frontend
Developed backend
Integration with Pidgin Client
The version control system is Monotone and for the time being I will be hosting t

Re: [ANN] pidgin git import v5

Richard Laager — 2012-05-21T18:17:44

I see no harm in keeping them, and more data seems better than less.


Nice!


If you can finish those two items up, I see no reason we can't do the
final migration.*

I'd like to finish author mapping the entire history, but if I can't get
that done in time, let's not hold up the transition. So far, I haven't
had much incentive to work on that, since other things were holding up
the transition anyway.

* This is based on a quick read of your email. I haven't yet looked at
the repositories output by the script.

[ANN] pidgin git import v5

Felipe Contreras — 2012-05-21T16:02:38

Hi,

Here's a new version of the conversion scripts.

The major change is that I wrote a script to compare a git and
mercurial repo, thanks to this script, I've managed to track various
discrepancies between the mercurial and git scripts. After fixing all
those discrepancies, the repositories match 100% (except formatting
differences; hg convert seems to strip some lines from the commit
messages, and git author limitations: 'John Doe' -> 'John Doe
<unknown>'). All the graph matches as well; there's no single commit
lost.

I haven't checked the file contents yet, but I don't think there will
be any issues in 'mtn git_export'.

Also, there is now support to split certain unmerged branches to
separate repositories. This is better than the mercurial scripts
version because a) it actually works, and b) there's no need to figure
which branches have been merged or not; git figures that out
automatically. And of course it's *much* faster.

Finally, I've enabled the --log-revids and --log-certs options to 'mtn
git_ex

[PATCH 20/21] fix-svn-author-certs: use new format

Felipe Contreras — 2012-05-13T14:14:28

Signed-off-by: Felipe Contreras <felipe.contreras< at >gmail.com>
---
 fix-svn-author-certs.py |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/fix-svn-author-certs.py b/fix-svn-author-certs.py
index 9545d67..af3df0a 100755
--- a/fix-svn-author-certs.py
+++ b/fix-svn-author-certs.py
< at >< at > -43,7 +43,12 < at >< at > with open("svn-revisions", "r") as f:
             svn_map[svn_revision] = [mtn_revision]
 
 svn_authormap = {}
-with open("svn-patch-authors", "r") as f:
+with open("svn_authors_map.txt", "r") as f:
+    for l in f:
+        key, value = l.rstrip().split(" = ")
+        svn_authormap[key] = value
+
+with open("svn_authors.txt", "r") as f:
     for l in f:
         mark = l.find("#") >= 0
         l = l.replace(" # ", " ").strip()
< at >< at > -54,6 +59,11 < at >< at > with open("svn-patch-authors", "r") as f:
             author = author[:author.index("(")].strip()
         except ValueError:
             pass
+        if mark and author in svn_authormap:
+            author = svn_authormap[au

[PATCH 21/21] fix-svn-author-certs: trivial cleanup

Felipe Contreras — 2012-05-13T14:14:29

Signed-off-by: Felipe Contreras <felipe.contreras< at >gmail.com>
---
 fix-svn-author-certs.py |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/fix-svn-author-certs.py b/fix-svn-author-certs.py
index af3df0a..0b95410 100755
--- a/fix-svn-author-certs.py
+++ b/fix-svn-author-certs.py
< at >< at > -24,12 +24,7 < at >< at > if key:
 author_map = {}
 with open("authormap", "r") as f:
     for l in f:
-        try:
-            index = l.index("=")
-        except ValueError:
-            continue
-        author = l[:index].strip()
-        name = l[index+1:].strip()
+        author, name = l.rstrip().split(" = ")
         if author and name:
             author_map[author.lower()] = name

[PATCH 19/21] Add new svn authors mappings

Felipe Contreras — 2012-05-13T14:14:27

Basically splitting 'svn-patch-authors' in two.

Signed-off-by: Felipe Contreras <felipe.contreras< at >gmail.com>
---
 svn_authors.txt     | 2593 +++++++++++++++++++++++++++++++++++++++++++++++++++
 svn_authors_map.txt |  173 ++++
 2 files changed, 2766 insertions(+)
 create mode 100644 svn_authors.txt
 create mode 100644 svn_authors_map.txt

diff --git a/svn_authors.txt b/svn_authors.txt
new file mode 100644
diff --git a/svn_authors_map.txt b/svn_authors_map.txt
new file mode 100644

[PATCH 18/21] Remove 'print-svn-authors'

Felipe Contreras — 2012-05-13T14:14:26

It's not relevant any more. And it doesn't work after last patch.

Signed-off-by: Felipe Contreras <felipe.contreras< at >gmail.com>
---
 print-svn-authors.py |   29 -----------------------------
 1 file changed, 29 deletions(-)
 delete mode 100755 print-svn-authors.py

diff --git a/print-svn-authors.py b/print-svn-authors.py
deleted file mode 100755
index 4075b09..0000000
--- a/print-svn-authors.py
+++ /dev/null
< at >< at > -1,29 +0,0 < at >< at >
-#!/usr/bin/python
-# vim: ai ts=4 sts=4 et sw=4
-
-import os
-import sys
-
-author_map = {}
-with open("authormap", "r") as f:
-    for l in f:
-        author, name = l.rstrip().split(" = ")
-        if author and name:
-            author_map[author.lower()] = name
-
-svn_authormap = {}
-with open("svn-patch-authors", "r") as f:
-    for l in f:
-        l = l.replace(" # ", " ").strip()
-        index = l.index(" ")
-        revision = l[:index]
-        author = l[index+1:]
-        try:
-            tmp = author[:author.index("(")].strip()
-        except ValueError:
-            t