reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 11:48:18AM -0800, Jeff Spaleta wrote:
> On Wed, Oct 15, 2008 at 10:57 AM, Patrice Dumas <pertusus at free.fr> wrote:
> > There are 2 reasons why I don't want to flesh it too much. One is
> > because I think it is an iterative process, we don't need much to start
> > and we'll see how it goes, and in the start it won't be public, only
> > something experimental.
> 
> I've no problem with interested people making an experimental stab at
> this.  if the intent is to have FESCo revisit this in like a year or
> something, try to setup the metrics or milestones now that will form
> the basis of that future progress review.

I think that it is too soon to try to set metrics before it is clear if
people should mandatorily sign off as maintainers for older branches,
whether and when there will be bug reports (and how) and so on.

> I will say however, that if the initial mission and goals for a SIG
> are too ill-defined you may have a problem harnessing manpower and
> have everyone pulling the effort forward in a common direction.  Just
> be wary of that.  As you move forward and create a SIG, I'm going to
> need something concrete enough as a statement so when I'm talking to
> people "outside" about their interests I know whether or not to point
> them to this SIG as a place to dig in and help.  The last thing I want
> to do is encourage people with dissimilar needs/interest to sit in a
> room together and have them fight with each other.

Indeed, that's a real issue for this project, as there is no consensus
on what is a good LTS project. For some it is absolute stability, for
other it is innovative as in fedora release, for other it is to bridge
the gap between RHEL releases, and so on. In my opinion saying that it
is more on the stability side, but without the same constraints than in
EPEL is a good start.

> > In fact I think that something that should be
> > discussed within the SIG is how hard we try to keep a possible
> > upgrade path toward the next RHEL/EPEL.
> 
> That statement right there, is probably simultaneously the hardest and
> potentially rewarding objective that an extended update effort could
> attempt to achieve.  And its a far different thing to state that as an
> objective to work towards over just saying maintainers can do whatever
> they want.  But to do it well, would probably require a consensual
> understanding by Red Hat and the external community that such an
> upgrade path was a valuable thing to work towards together.

I think that this is far too soon to have such target. In the short 
term leaving maintainers to do whatever they want is in my opinion a 
better option to begin with. As soon as th eSIG is established there
could be a refinement of the rules, but before I think that letting
packagers do what they want is the simplest and most general target we
can have.

--
Pat