3:25 p.m.
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
12:28 a.m.
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?
8:47 a.m.
On Thu, 28 Apr 2011 22:28:15 -0700
Garrett Holmstrom <gholms(a)fedoraproject.org> wrote:
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. ;)
kevin
10:54 a.m.
Kevin Fenzi (kevin(a)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
11:12 a.m.
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
10:51 p.m.
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.) ;-)
10:38 p.m.
>>>> "GH" == Garrett Holmstrom
<gholms(a)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<
4739
days inactive
4744
days old
6 comments
5 participants
participants (5)
-
Bill Nottingham -
Garrett Holmstrom -
Jason L Tibbitts III -
Jesse Keating -
Kevin Fenzi