-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Over the next 48 hours I'm going to be pulling together our CentOS Google Summer of Code application.
Our shortfall last year was i) number of ideas, and ii) mentors associated with ideas.
We can always adjust ii) as we go, but we really need a nice, wide pool of ideas.
Here is what our application and ideas looked like last year:
http://wiki.centos.org/GSoC/2014/Ideas http://wiki.centos.org/GSoC/2014/Application
I'll be reaching out to SIG members/leaders directly to work on ideas.
Ideally we have something more like 20 ideas with good starting details.
Just a heads up -- several times in the past the GSoC organizers have put Fedora Project and JBoss Community together due to a relationship with Red Hat. While I've argued against that practice (totally unrelated projects, etc.), I do understand the organizers' rationale - -- they have a limited number of slots (budget.) Thus I'm preparing for that possibility and talking with the Fedora Project organizers[1].
- - Karsten
[1] tl;dnr here is that especially with the SIGs work, ideas for EPEL, similar tooling, etc. there are a lot of efforts that can benefit both projects. Especially since Fedora already has the mentoring culture, this could be a great way for the CentOS Project to learn how to do a GSoC without as much associated pain. - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On 18/02/15 18:31, Karsten Wade wrote:
Over the next 48 hours I'm going to be pulling together our CentOS Google Summer of Code application.
Our shortfall last year was i) number of ideas, and ii) mentors associated with ideas.
We can always adjust ii) as we go, but we really need a nice, wide pool of ideas.
Here is what our application and ideas looked like last year:
http://wiki.centos.org/GSoC/2014/Ideas http://wiki.centos.org/GSoC/2014/Application
I'll be reaching out to SIG members/leaders directly to work on ideas.
After the conversation from the 10th Feb, I've been in touch with a bunch of folks in the SIGs and also been collecting ideas around the core project side of things. Will try and get them onto the wiki in the next day or so.
Everyone on the core sig should signup as mentors, and from the conversations I've had we should get a few more people from the SIG's as well.
Merge Open Build Service (http://openbuildservice.org/) and Koji build system
On 2/18/2015 11:31 AM, Karsten Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Over the next 48 hours I'm going to be pulling together our CentOS Google Summer of Code application.
Our shortfall last year was i) number of ideas, and ii) mentors associated with ideas.
We can always adjust ii) as we go, but we really need a nice, wide pool of ideas.
Here is what our application and ideas looked like last year:
http://wiki.centos.org/GSoC/2014/Ideas http://wiki.centos.org/GSoC/2014/Application
I'll be reaching out to SIG members/leaders directly to work on ideas.
Ideally we have something more like 20 ideas with good starting details.
Just a heads up -- several times in the past the GSoC organizers have put Fedora Project and JBoss Community together due to a relationship with Red Hat. While I've argued against that practice (totally unrelated projects, etc.), I do understand the organizers' rationale
- -- they have a limited number of slots (budget.) Thus I'm preparing
for that possibility and talking with the Fedora Project organizers[1].
- Karsten
[1] tl;dnr here is that especially with the SIGs work, ideas for EPEL, similar tooling, etc. there are a lot of efforts that can benefit both projects. Especially since Fedora already has the mentoring culture, this could be a great way for the CentOS Project to learn how to do a GSoC without as much associated pain.
Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlTk2m4ACgkQ2ZIOBq0ODEF8+QCgl7kAqA7F+LWb3F6atIyg3XwQ ZZMAoMtmbP85ElHCRAwckdiWsDPWFXIO =8tH4 -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hi
On 19/02/15 01:27, norwoods wrote:
Merge Open Build Service (http://openbuildservice.org/) and Koji build system
thats a very interesting idea.
At the base layers, a build is really just converting sources into binary. or collecting binary bits and making an ISO or a Live Media or a Cloud image or a Container etc; but the actual convertion side of things is all finite.
So with that in mind, the big difference in OpenBuildService and Koji is that Koji perhaps has a more focused approach to letting teams contribute, in their own pace and space, towards ( one or more ) product / goals. Whereas Openbuildservice just churns sources to binaries in an environment for user facing ( and much smaller ) task sets.
A merge then might be a case of openbuildservice using koji at the backend and retaining its web UI ?
On Thu, Feb 19, 2015 at 09:38:09AM +0000, Karanbir Singh wrote:
Hi
On 19/02/15 01:27, norwoods wrote:
Merge Open Build Service (http://openbuildservice.org/) and Koji build system
thats a very interesting idea.
At the base layers, a build is really just converting sources into binary. or collecting binary bits and making an ISO or a Live Media or a Cloud image or a Container etc; but the actual convertion side of things is all finite.
So with that in mind, the big difference in OpenBuildService and Koji is that Koji perhaps has a more focused approach to letting teams contribute, in their own pace and space, towards ( one or more ) product / goals. Whereas Openbuildservice just churns sources to binaries in an environment for user facing ( and much smaller ) task sets.
A merge then might be a case of openbuildservice using koji at the backend and retaining its web UI ?
IIRC there is also a big concern on build reproducibility on koji which I'm not sure is approached in the same way by OBS.
While the idea is interesting, I have two remarks: a) we should get Mike involved in this b) does this fit in the scope of a GSoC? Sounds to me that this will require more than 3 months of work, in which case we would probably want to reduce the scope of the proposal to 1) something doable and 2) something useful (for which we clearly need Mike's input)
My 2cts, Pierre
On 19/02/15 10:07, Pierre-Yves Chibon wrote:
On Thu, Feb 19, 2015 at 09:38:09AM +0000, Karanbir Singh wrote:
Hi
On 19/02/15 01:27, norwoods wrote:
Merge Open Build Service (http://openbuildservice.org/) and Koji build system
thats a very interesting idea.
At the base layers, a build is really just converting sources into binary. or collecting binary bits and making an ISO or a Live Media or a Cloud image or a Container etc; but the actual convertion side of things is all finite.
So with that in mind, the big difference in OpenBuildService and Koji is that Koji perhaps has a more focused approach to letting teams contribute, in their own pace and space, towards ( one or more ) product / goals. Whereas Openbuildservice just churns sources to binaries in an environment for user facing ( and much smaller ) task sets.
A merge then might be a case of openbuildservice using koji at the backend and retaining its web UI ?
IIRC there is also a big concern on build reproducibility on koji which I'm not sure is approached in the same way by OBS.
While the idea is interesting, I have two remarks: a) we should get Mike involved in this b) does this fit in the scope of a GSoC? Sounds to me that this will require more than 3 months of work, in which case we would probably want to reduce the scope of the proposal to 1) something doable and 2) something useful (for which we clearly need Mike's input)
I agree on both counts, what I was hoping to try and see was if we can start a convo on what the real wins might be, then break that up into smaller tasks ( ideally, deliverable on their own )
Also, its worth noting that coprs can help with some of the drive-by packaging/building things as well.