FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-28-2011, 08:25 PM
Bill Nottingham
 
Default Some changes to EPEL package reviews

Just as a FYI:

EPEL now has a 'Package Review' component in bugzilla. If you've got an
EPEL-only package you'd like to get reviewed, feel free to file it there.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-28-2011, 08:25 PM
Bill Nottingham
 
Default Some changes to EPEL package reviews

Just as a FYI:

EPEL now has a 'Package Review' component in bugzilla. If you've got an
EPEL-only package you'd like to get reviewed, feel free to file it there.

Bill
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 04-29-2011, 05:28 AM
Garrett Holmstrom
 
Default Some changes to EPEL package reviews

On 4/28/2011 13:25, Bill Nottingham wrote:
> EPEL now has a 'Package Review' component in bugzilla. If you've got an
> EPEL-only package you'd like to get reviewed, feel free to file it there.

How is this any different, given that process-git-requests creates a
rawhide branch without regard to whether one asks for it or not?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-29-2011, 03:54 PM
Bill Nottingham
 
Default Some changes to EPEL package reviews

Kevin Fenzi (kevin@scrye.com) said:
> > On 4/28/2011 13:25, Bill Nottingham wrote:
> > > EPEL now has a 'Package Review' component in bugzilla. If you've
> > > got an EPEL-only package you'd like to get reviewed, feel free to
> > > file it there.
> >
> > How is this any different, given that process-git-requests creates a
> > rawhide branch without regard to whether one asks for it or not?
>
> I think the idea is that it allows people who wish to see reviews that
> are EPEL only. So, perhaps they have more interest or desire to review
> those.

Correct. And it gives us something to key off of to possibly change
process-git-requests in the future.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-29-2011, 04:12 PM
Jesse Keating
 
Default Some changes to EPEL package reviews

On 4/29/11 8:54 AM, Bill Nottingham wrote:
>>> > > How is this any different, given that process-git-requests creates a
>>> > > rawhide branch without regard to whether one asks for it or not?
>> >
>> > I think the idea is that it allows people who wish to see reviews that
>> > are EPEL only. So, perhaps they have more interest or desire to review
>> > those.
> Correct. And it gives us something to key off of to possibly change
> process-git-requests in the future.

It is somewhat difficult, and odd, to create a git repo that does not
have a master branch. It would be a little more odd to potentially at
some point in the future create the master branch for a package should
it find a home within Fedora.

There need not be much/any content in the master branch, but there
should still be one for each package.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-30-2011, 03:51 AM
Garrett Holmstrom
 
Default Some changes to EPEL package reviews

On 4/29/2011 9:12, Jesse Keating wrote:
> It is somewhat difficult, and odd, to create a git repo that does not
> have a master branch. It would be a little more odd to potentially at
> some point in the future create the master branch for a package should
> it find a home within Fedora.

As you say, this practice is somewhat unusual, but it is not difficult.
It takes but a single easily-scriptable command prior to the first
commit to change the name of the initial branch. Since Fedora's repo
creation scripts already do an initial commit in every new package
repository this should not be difficult to add to that process.

Creating a master branch where none existed would primarily be a matter
of deciding which existing branch to branch the new master branch from.
This part should only be difficult to do programmatically if the
desired preexisting branch is not the initial one that the repository's
first commit was created on.

> There need not be much/any content in the master branch, but there
> should still be one for each package.

For the sake of code simplicity, I agree: every repo ought to have a
master branch. Having one omnipresent branch lets Fedora's repo
management scripts make some very useful assumptions. (Yes, this
opinion flies in the face of my previous statements.) ;-)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 05-03-2011, 03:38 AM
"Jason L Tibbitts III"
 
Default Some changes to EPEL package reviews

>>>>> "GH" == Garrett Holmstrom <gholms@fedoraproject.org> writes:

GH> How is this any different, given that process-git-requests creates a
GH> rawhide branch without regard to whether one asks for it or not?

I'm catching up with mail after the weekend and noticed this unusually
pointed bit of misinformation which bears correcting.

process-git-requests has no choice in the matter. Whatsoever. It
creates the branches requested; the master branch comes along
regardless.

I can't imagine this is remotely a big deal, but being able to
differentiate EPEL-only packages does make it possible for
process-git-requests to automatically dead.package the branch or to make
use of any potential master-branch-less functionality should it appear
in the future.

- J<
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 08:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org