[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: EPEL branching if Fedora maintainer does not react



On Tuesday 14 August 2007 11:57:35 am Thorsten Leemhuis wrote:
> On 06.08.2007 17:27, Thorsten Leemhuis wrote:
> > On 01.08.2007 18:59, Dennis Gilmore wrote:
> > [...]
> >
> >> If the Fedora maintainer later decides to participate in EPEL, Then both
> >> people will become co-maintainers for EPEL.  (Of course
> >> co-maintainership can be extended to Fedora)
> >
> > If I understand the last para correctly we have two maintainers one the
> > same level -- e.g. no primary per-release maintainer? That's not in line
> > with the co-maintainership policy, which makes sure there is always one
> > person as per-release primary maintainer which is responsible in the end
> > for the packages (and has the last word in case of disputes). I prefer
> > such a scheme, because two people co-maintaining a package in the end
> > could quickly lead to situation where each other thought the other one
> > will take care of the package.
> >
> > So: -1 for this. I'm all for something like that as last para:
> >
> > If the Fedora maintainer later decides to participate in EPEL, then he
> > and the EPEL maintainer should discuss which one takes care of the
> > package. One should become primary per release maintainer, which is kind
> > of responsible for the package in that release; the other should become
> > co-maintainer; how those two share the work is up to them.
>
> Ping -- I got no reactions on this.
>
> To let me rephrase: with the "Then both people will become
> co-maintainers for EPEL." it's afaics unclear who's the primary
> per-release maintainer and who's the co-maintainer in the end. That's
> not in line with the co-maintainership policy from Fedora, which
> requests there is a per-release (release=EPEL4 and EPEL5 in this case)
> maintainer.

Sorry it was not clear to you.  the Fedora maintainer will become the 
co-maintainer.  they EPEL maintainer will remain primary.  of course this can 
be switched if the maintainers agree.

Dennis


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]