Hello,
I wanted to import a password-protected pfx certificate, but it was not
supported in our certmgr. So I have created a small patch to enable it.
If it's looking good I'll push it in git (or feel free to do instead).
Atsushi Eno
diff --git a/mcs/tools/security/certmgr.cs
Hello again,
This patch adds support for X509Store.TrustedPeople in Mono.Security
and certmgr.
Sorry for that this patch includes the previous change, I was lazy :|
Atsushi Eno
diff --git a/mcs/class/Mono.Security/Mono.Security.X509/X509Stores.cs
Github takes the first line from the commit message to build this page:
http://github.com/mono/mono/commits/master
I think we should modify our current commit messages to not just be the change
log entries, but have a 1 line summary of the patch first like this:
+1 on the commit message change
I'd also like to vote, along with work branches be in user's forks, to use
this model:
http://nvie.com/git-model
-Dale
Github takes the first line from the commit message to build this page:
http://github.com/mono/mono/commits/master
I think we should
Hello,
Additionally, I think we should implement a policy that all work
branches are made in user forks; and the only people who should be
making branches in the mainline github are QA for release managment
practices.
I want to ask you a favor, can you please add to the document:
On Tue, Jul 27, 2010 at 6:22 PM, Geoff Norton gnor...@novell.com wrote:
Github takes the first line from the commit message to build this page:
http://github.com/mono/mono/commits/master
I think we should modify our current commit messages to not just be the
change log entries, but have a 1
On 2010-07-27, at 5:42 PM, Rodrigo Kumpera wrote:
It doesn't make any sense to have work/feature branches on the central
repository given we're using git. It's much easier and cleaner to simply have
them on personal forks. One might not like dealing with extra remotes, but
that would
On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera kump...@gmail.com wrote:
I have another proposition to make. Can we stop using Changelog files? Those
can be generated from the commit logs for tarballs and releases without
losing anything at all. Commit messages would still have to be at least
On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan dale.ra...@sinesignal.com wrote:
+1 on the commit message change
I'd also like to vote, along with work branches be in user's forks, to use
this model:
http://nvie.com/git-model
One detail I really like about this is the non-fast-forwarding merge
For commit messages, how about gnome style ones?
http://live.gnome.org/Git/CommitMessages
We'll end up with messages like this:
http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2:)
Alan.
On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst mark.pro...@gmail.com wrote:
On
On 2010-07-27, at 6:27 PM, Mark Probst wrote:
On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan dale.ra...@sinesignal.com
wrote:
+1 on the commit message change
I'd also like to vote, along with work branches be in user's forks, to use
this model:
http://nvie.com/git-model
One detail I
On 2010-07-27, at 6:21 PM, Alan wrote:
For commit messages, how about gnome style ones?
http://live.gnome.org/Git/CommitMessages
This is actually very nice. My only concern is maintaining the list of [Tag]'s.
-g
We'll end up with messages like this:
On Tue, 27 Jul 2010 18:41:46 -0400
Geoff Norton gnor...@novell.com wrote:
On 2010-07-27, at 6:21 PM, Alan wrote:
For commit messages, how about gnome style ones?
http://live.gnome.org/Git/CommitMessages
This is actually very nice. My only concern is maintaining the list of
On Tue, Jul 27, 2010 at 7:27 PM, Mark Probst mark.pro...@gmail.com wrote:
On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan dale.ra...@sinesignal.com
wrote:
+1 on the commit message change
I'd also like to vote, along with work branches be in user's forks, to
use
this model:
Hi,
I've been trying to think up some more ways to disrupt everyone's
workflow, seeing that we've been so successful with the Git import ;-)
But, these proposals aren't any of those. I actually have some
ideas that I think are useful. These are in increasing order of
intrusiveness, but are
On Tue, Jul 27, 2010 at 3:11 PM, Raja R Harinath harin...@hurrynot.org wrote:
* clean up the main repos
The source trees at github.com/mono/ have a lot of junk^W branches left
over from the SVN days. However, we mostly work on two or three main
branches. For instance, in the mono/ tree, we
16 matches
Mail list logo
