Smart on Fedora and openSUSE

[Anders F Björklund]

Gustavo Niemeyer wrote:

>> Maybe the current "trunk" series should be split anyway, to allow
>> for faster integration of more experimental features while still
>> offering a completely stable main branch for legacy deployments ?
>> And there the "1.x" versus "2.x" naming split felt rather natural...
>
> Having an unstable branch for stabilizing new features as they are
> developed is nice.  That said, there's no difference in terms of
> development practices for either branch.  In other words, if it's not
> properly tested, it shouldn't go into 1.X *or* 2.X.

Yeah, that's why I used "testing" - rather than "unstable" or
"development" (or, as my own branches tend to be named, "sandbox")

I won't pretend to understand how Launchpad uses branches, but
I've tried to move towards one code branch per added feature.

> I'm pointing that out because good part of the current contention is
> related to lack of proper testing in suggested changes, or in some
> cases because the changes break backwards compatibility in an
> unnecessary way.  Whenever I go into a round of integration of
> external patches I end up writing many of these tests myself, and that
> means less integrated patches per time spent reviewing changes.

Hopefully it should have gotten better with the latest additions.
I seem to even have encouraged others to write tests first... :-)

Not all suggested changes are good, either. Some should either be
rewritten first or flat out rejected, rather than blindly applied.

>> For instance, you might want one "stable" version for servers
>> and one "testing" version for hobbyists and enthusiasts [sic] ?
>
> I'd rather see effort being put on producing one line of development
> which is updated more often.

The release goal to beat for those two targets would be "two years"
versus "six months", and rather different approach to new features.

PackageKit releases every week or two, which seems a bit too often,
but it does have a "stable" branch that doesn't break the ABI/API.

--anders