Since open source development workflows have moved towards services like GitHub and Bitbucket, we have decided to move Reference Policy's repositories to GitHub. The project wiki is now available here:
https://github.com/TresysTechnology/refpolicy/wiki
The repository can be checked out using the following:
$ git clone https://github.com/TresysTechnology/refpolicy.git
$ cd refpolicy
$ git submodule init
$ git submodule update
Alternatively, use GitHub's forking features to clone the repositories to your own GitHub account.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Mon, 9 Jun 2014 10:54:24 Christopher J. PeBenito wrote:
> Since open source development workflows have moved towards services like
> GitHub and Bitbucket, we have decided to move Reference Policy's
> repositories to GitHub. The project wiki is now available here:
http://www.cultureoffset.org/
Are you sure that GitHub is a good choice?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Il 14/giu/2014 03:46 "Russell Coker" <[email protected]> ha scritto:
>
> On Mon, 9 Jun 2014 10:54:24 Christopher J. PeBenito wrote:
> > Since open source development workflows have moved towards services like
> > GitHub and Bitbucket, we have decided to move Reference Policy's
> > repositories to GitHub. The project wiki is now available here:
>
> http://www.cultureoffset.org/
>
> Are you sure that GitHub is a good choice?
Every one know GitHub. Also the git book talk about it. No perfect as a
platform but as project you can Gain more visibility.
IMHO
Best regards
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20140614/97802440/attachment.html
On Sat, 14 Jun 2014 09:20:29 Elia Pinto wrote:
> > http://www.cultureoffset.org/
> >
> > Are you sure that GitHub is a good choice?
>
> Every one know GitHub. Also the git book talk about it. No perfect as a
> platform but as project you can Gain more visibility.
The SE Linux project has been active for 14 years. People have given lectures
about it at many (all?) major Linux conferences (I've done OLS, LCA, and Linux
Kongress). Articles have been written about it in many (all?) major Linux
magazines (I've done Linux Journal). It's a default feature in Fedora and
RHEL and available in other distributions as well. Blog posts about it can be
seen on most of the major Linux Planet feeds.
I don't think that we have a lack of visibility.
Judging by names I've seen on these mailing lists and people I've met it seems
obvious to me that the proportion of female developers in the SE Linux project
is significantly lower than what you see in proprietary software development.
I think this is a problem we should try to solve.
Also this isn't just about female developers, when one minority group is
treated badly members of others won't expect to be treated well either.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Dear Maintainers,
I see you've incorporated commits from an Github pull request for the
first time [1]. I personally think this could be problematic, as there
hasn't been any announcement/discussion of these commits on the mailing
list.
Could you please clear up your opinion towards pull requests - whether
they will be accepted or not and whether mailing list patch submission
or pull-requests are prefered.
I personally would propose that pull requests should be either
1) disallowed, so that patch submission is only possible on the ML
(This approach is also taken by Git itself and by Linux, to name
prominent examples) or
2) allowed, but with the requirement that the patches or at least an
announcement is also posted on the ML.
Of course, the last paragraph represents my personal opinion and I'm
very interested how the maintainers and the other contributors think
about it.
[1] https://github.com/TresysTechnology/refpolicy/pull/1
Regards,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140626/2e6f5c63/attachment.bin
On 6/26/2014 4:07 PM, Luis Ressel wrote:
> Dear Maintainers,
>
> I see you've incorporated commits from an Github pull request for the
> first time [1]. I personally think this could be problematic, as there
> hasn't been any announcement/discussion of these commits on the mailing
> list.
>
> Could you please clear up your opinion towards pull requests - whether
> they will be accepted or not and whether mailing list patch submission
> or pull-requests are prefered.
>
> I personally would propose that pull requests should be either
> 1) disallowed, so that patch submission is only possible on the ML
> (This approach is also taken by Git itself and by Linux, to name
> prominent examples) or
> 2) allowed, but with the requirement that the patches or at least an
> announcement is also posted on the ML.
Patch submissions via pull requests will be allowed, though you do make
a good point about discussion. If you have concerns about missing
something, you should use GitHub's "watch" function on the repo to get
notifications.
I'll look in to GitHub's webhooks to see if we can have pull request
notifications sent to the list. Failing that, I'm leaning towards #2.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Fri, 27 Jun 2014 10:45:38 -0400
"Christopher J. PeBenito" <[email protected]> wrote:
> I'll look in to GitHub's webhooks to see if we can have pull request
> notifications sent to the list. Failing that, I'm leaning towards #2.
This sounds like a great idea!
Regards,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140627/c8aa947f/attachment.bin