headers
Carlo de Wolf | 1 Feb 16:19
Picon
Favicon
Gravatar

https://github.com/fedoraproject

Hello members of the Board,

I would like to petition the Board to endorse 
https://github.com/fedoraproject as a secondary outlet of hosted code.

Some projects that go into Fedora have their upstream hosted on GitHub. 
To get these projects into Fedora not only spec files need to be 
created, in most cases patches need to be created as well. While these 
patches themselves are available in the corresponding rpm git repo 
(pkgs.fedoraproject.org) they are not easily usable for upstream 
developers. (And in most cases "hand"-crafted, instead of maintained in 
a real branch.) An upstream developer is used to work on a git branch.

Whilst it is possible to maintain such a git branch at fedorahosted.org 
it would suffer from a lack of integration with the upstream branch 
hosted on GitHub itself.

Note that this petition does not ask for alleviation of hosting on 
fedorahosted.org should that be required. In that case 
https://github.com/fedoraproject would serve as a mirror of 
fedorahosted.org.

I do say that Fedora should endorse and administrate the account known 
as fedoraproject on GitHub for the sole purpose of providing an extra 
outlet of Fedora branches related to GitHub hosted upstream projects.

Note that I'm completely ignorant of actual possibilities and I hereby 
apologize for said ignorance.

Thanks in advance,
(Continue reading)

Permalink | Reply | 20 comments |
headers
Josh Boyer | 1 Feb 16:29
Picon

https://github.com/fedoraproject

On Wed, Feb 1, 2012 at 10:19 AM, Carlo de Wolf <cdewolf <at> redhat.com> wrote:
> Hello members of the Board,
>
> I would like to petition the Board to endorse
> https://github.com/fedoraproject as a secondary outlet of hosted code.

What exactly are you envisioning when you say "endorse"?

> Some projects that go into Fedora have their upstream hosted on GitHub. To
> get these projects into Fedora not only spec files need to be created, in
> most cases patches need to be created as well. While these patches
> themselves are available in the corresponding rpm git repo
> (pkgs.fedoraproject.org) they are not easily usable for upstream developers.
> (And in most cases "hand"-crafted, instead of maintained in a real branch.)
> An upstream developer is used to work on a git branch.

The Fedora package maintainers should be sending the patches to the
upstream project already.  The goal (while not always feasible) is to carry
as few patches in the Fedora packages as possible.

> Whilst it is possible to maintain such a git branch at fedorahosted.org it
> would suffer from a lack of integration with the upstream branch hosted on
> GitHub itself.
>
> Note that this petition does not ask for alleviation of hosting on
> fedorahosted.org should that be required. In that case
> https://github.com/fedoraproject would serve as a mirror of
> fedorahosted.org.

fedorahosted.org is in place to host projects pertaining mostly to Fedora
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Wolff III | 1 Feb 16:29
Picon

https://github.com/fedoraproject

On Wed, Feb 01, 2012 at 16:19:08 +0100,
  Carlo de Wolf <cdewolf <at> redhat.com> wrote:
> 
> Whilst it is possible to maintain such a git branch at
> fedorahosted.org it would suffer from a lack of integration with the
> upstream branch hosted on GitHub itself.

Wouldn't make more sense for maintainers to either get their own github
accounts or just keep a local checkout of upstreams they are interested in
so that they can work easier with upstreams?

The form of patches used in rpms doesn't really match what upstreams would
need, so i am not sure what a project repo in github would provide that
maintainers can't get on their own?
_______________________________________________
advisory-board mailing list
advisory-board <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
Permalink | Reply | 14 comments |
headers
Christopher Meng | 1 Feb 16:37
Picon
Gravatar

https://github.com/fedoraproject

Well.This is not repoforge.Please dont take more difficulty to the developers

On 2/1/12, Bruno Wolff III <bruno <at> wolff.to> wrote:
> On Wed, Feb 01, 2012 at 16:19:08 +0100,
>   Carlo de Wolf <cdewolf <at> redhat.com> wrote:
>>
>> Whilst it is possible to maintain such a git branch at
>> fedorahosted.org it would suffer from a lack of integration with the
>> upstream branch hosted on GitHub itself.
>
> Wouldn't make more sense for maintainers to either get their own github
> accounts or just keep a local checkout of upstreams they are interested in
> so that they can work easier with upstreams?
>
> The form of patches used in rpms doesn't really match what upstreams would
> need, so i am not sure what a project repo in github would provide that
> maintainers can't get on their own?
> _______________________________________________
> advisory-board mailing list
> advisory-board <at> lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/advisory-board

--

-- 

Best Regards,
Christopher Meng------'Cicku'

My personal blog is http://cicku.me,hope you can visit and say something
about it.
More Contact info see here:http://about.me/cicku
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rex Dieter | 1 Feb 16:42
Favicon
Gravatar

https://github.com/fedoraproject

On 02/01/2012 09:19 AM, Carlo de Wolf wrote:
> Hello members of the Board,
>
> I would like to petition the Board to endorse
> https://github.com/fedoraproject as a secondary outlet of hosted code.
...
> I do say that Fedora should endorse and administrate the account

So, let's try not to complicate the issue here.

We all had a chat in #fedora-advisory-board earlier, and the primary 
request here is for trademark approval, so that the disclaimer "This 
site is not affiliated with or endorsed by the Fedora Project" can be 
removed.

that addresses the "endorse" part.

As to the second part "administrate the account", that's not in the 
board's ability to do so.  I'd suggest you (those making this request) 
be the one's empowered to take such responsibility.

-- rex
_______________________________________________
advisory-board mailing list
advisory-board <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
Permalink | Reply | 0 comments |
headers
Carlo de Wolf | 1 Feb 16:50
Picon
Favicon
Gravatar

https://github.com/fedoraproject

On 02/01/2012 04:29 PM, Bruno Wolff III wrote:
> On Wed, Feb 01, 2012 at 16:19:08 +0100,
>    Carlo de Wolf<cdewolf <at> redhat.com>  wrote:
>> Whilst it is possible to maintain such a git branch at
>> fedorahosted.org it would suffer from a lack of integration with the
>> upstream branch hosted on GitHub itself.
> Wouldn't make more sense for maintainers to either get their own github
> accounts or just keep a local checkout of upstreams they are interested in
> so that they can work easier with upstreams?

That works, until you get to a point where both upstream developers and 
packagers need to work together.

https://github.com/fedoraproject/jboss-as/commit/47a33041eb75290629fec7869604f39c19881366 
is something an upstream developer can work with right
away.

https://github.com/fedoraproject/jboss-as-rpm/blob/master/SOURCES/0002-Fix-initd-script.patch 
is something only useful and usable by rpmbuild. (Note that this repo 
must be relocated to pkgs.fedoraproject.org.)

Still not that big of an issue until you get multiple upstream 
developers and packagers that need to do a concentrated effort on a 
single piece.

>
> The form of patches used in rpms doesn't really match what upstreams would
> need, so i am not sure what a project repo in github would provide that
> maintainers can't get on their own?
(Continue reading)

Permalink | Reply | 12 comments |
headers
Bruno Wolff III | 1 Feb 16:52
Picon

https://github.com/fedoraproject

On Wed, Feb 01, 2012 at 16:50:49 +0100,
  Carlo de Wolf <cdewolf <at> redhat.com> wrote:
> >On Wed, Feb 01, 2012 at 16:19:08 +0100,
> >   Carlo de Wolf<cdewolf <at> redhat.com>  wrote:
> >>Whilst it is possible to maintain such a git branch at
> >>fedorahosted.org it would suffer from a lack of integration with the
> >>upstream branch hosted on GitHub itself.
> >Wouldn't make more sense for maintainers to either get their own github
> >accounts or just keep a local checkout of upstreams they are interested in
> >so that they can work easier with upstreams?
> 
> That works, until you get to a point where both upstream developers
> and packagers need to work together.

Packagers can still ask for upstream commit access.

> https://github.com/fedoraproject/jboss-as/commit/47a33041eb75290629fec7869604f39c19881366
> is something an upstream developer can work with right away.
> 
> https://github.com/fedoraproject/jboss-as-rpm/blob/master/SOURCES/0002-Fix-initd-script.patch
> is something only useful and usable by rpmbuild. (Note that this
> repo must be relocated to pkgs.fedoraproject.org.)

That's more or less what I said. That's why I don't see a reason for Fedora
to have their own github mirror.

However even if a packager can't get upstream commit access they can still
keep a local checkout of the upstream repo and use that for both creating
patches for Fedora and for sending patches back upstream (either having
thir own git server or emailing patches created using git).
(Continue reading)

Permalink | Reply | 11 comments |
headers
Richard Shaw | 1 Feb 16:58
Picon
Gravatar

https://github.com/fedoraproject

On Wed, Feb 1, 2012 at 9:52 AM, Bruno Wolff III <bruno <at> wolff.to> wrote:
> However even if a packager can't get upstream commit access they can still
> keep a local checkout of the upstream repo and use that for both creating
> patches for Fedora and for sending patches back upstream (either having
> thir own git server or emailing patches created using git).

I've been working with several github projects and I believe the
preferred method (if the patches are upstreamable) is to create a fork
of the github project, create a branch in your fork, and then do a
pull request to get upstream to evaluate your patch. It's a little
convoluted, especially if you haven't acclimated to the way git works,
but it does work well.

Richard
_______________________________________________
advisory-board mailing list
advisory-board <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
Permalink | Reply | 10 comments |
headers
Carlo de Wolf | 1 Feb 17:04
Picon
Favicon
Gravatar

https://github.com/fedoraproject

On 02/01/2012 04:58 PM, Richard Shaw wrote:
> On Wed, Feb 1, 2012 at 9:52 AM, Bruno Wolff III<bruno <at> wolff.to>  wrote:
>> However even if a packager can't get upstream commit access they can still
>> keep a local checkout of the upstream repo and use that for both creating
>> patches for Fedora and for sending patches back upstream (either having
>> thir own git server or emailing patches created using git).
> I've been working with several github projects and I believe the
> preferred method (if the patches are upstreamable) is to create a fork
> of the github project, create a branch in your fork, and then do a
> pull request to get upstream to evaluate your patch. It's a little
> convoluted, especially if you haven't acclimated to the way git works,
> but it does work well.
>
> Richard
> _______________________________________________
> advisory-board mailing list
> advisory-board <at> lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/advisory-board

True.

Non-upstreamable patches like 
https://github.com/fedoraproject/jboss-as/commit/7aa8fee7fb6b50270dc8b95be9c1ba08e579b3ad 
however still require collaboration.
Both in terms of evaluating functional loss by upstream developers (in 
this case it's a minor thing) and further enhancement by packagers.

Carlo
_______________________________________________
advisory-board mailing list
(Continue reading)

Permalink | Reply | 9 comments |
headers
Guillermo Gómez | 1 Feb 19:50
Picon
Gravatar

Gomix, My Board member tasks/goals

Time for me to express my tasks and goals as a Board member.

Motivation, for none is a secret that i'm biased on the language
issues we have in a project such as Fedora, then, my tasks are
language oriented, i'm talking about spanish. Main high barriers i'll
we be challenging are:

1. Teaching, easying, mentoring and sponsoring new Fedora packagers
** Basically it means drive rpmdev latam RPM branch (not limited to it)
** Doubling the actual figures of rpmdev graduates (goal => from 11 to 22 )
** Become a packaging sponsor or find other candidates to achieve
further autonomy

2. Teaching, easying, mentoring and coauthoring new docs for Fedora
Documentation Projects
** Castillian as the native lang for it as it is actually for Software
Management Guide (SMG)
** Basically it means drive rpmdev latam DOC branch
** Double the actual quantity (goal => from 1 to 2)
** Fedora Robotics Guide (Valentin Basel main author)
** Keep maintaining SMG for another year minimun

3. Teaching, easying, mentoring and codevel a new sw development for Fedora
** Drive rpmdev latam DEV branch
** Software incubator for latam developers
** Ruby and/or Python, Webapps as a possible focus
** A Webapp for Fedora
** Gamification to make it fun
** Goal => 1 succesfully developed and deployable app
(Continue reading)

Permalink | Reply | 0 comments |

Gmane