release!

[Gustavo Niemeyer]

Hey Rehan,

I'm including the Smart list in this since I believe it's of general interest.

> I hope you don't mind my impatience with getting a release out. As with
> everyone else I only have a certain amount of time I can spend for Open
> Source Projects and I want to get Smart ready for greater adoption if that
> is at all possible. This is a list I came up with a few days ago regarding a
> release.

Not only I don't mind it, but I actually appreciate your impatience.  I truly
hope you can keep up that impatience for a long time.

> Proposed Release process/procedure for Smart:
> Releases need to be regular (in the order of months, at least three/four per
> year for stable)

Sounds like a good plan.

> Two/Three release tracks:
> Beta + Released version or Alpha/Beta/Released

As we discussed, we can introduce this as needed.  Right now we don't have
good motivation for it, because we have few developers with not much available
time.  So what we can do right now is handle trunk as the unstable release, and
work in cycles of stabilization/unstabilization towards the releases.

> Released versions have these characteristics:
> 1 All major features have tests

I'd like to propose that all features and all changes have tests
instead.  For something
not to have a test, we should have some discussion regarding why the
test won't be
done in such cases.

> 2 All bugs during the beta phase have been squashed

That conflicts with time-based releases suggested earlier.  Either we
define that we will
try hard to release every N weeks, or we define that we don't release
unless we're bug
free.  I think the first option is a better approach.  We try hard to
release within a given
time frame, and only block on major issues.

> 3 Key users are happy for it to go mainstream (the beta works for them)

That's always been the case, and I agree we should keep it (just
replace "beta" with
"trunk" to keep up with current nomenclature).

> 4 Each feature has a test script (not unittest or other automated test
> script but actual user test script)

I don't know what you mean here.  Any test script is necessarily an
automated test.
Unittests should be attempted for all the changes, and integration
tests should also
be done whenever possible.

> Alpha/Beta releases:
> 1 Not everything has to have a test

That's not a good idea.  Everything has to have a test, unless there
are good reasons
not to, and if there are good reasons, these should be discussed
before integration.

> 2 Bugs acknowledged publicly

Not sure what you mean here.  All bugs have always been publicly
acknowledged.  We
do this with the bug tracker.

> 3 Key users are testing the developer output

Sure.  I hope that's the case with trunk right now.

> 4 unittests and test scripts are being developed (mentoring and
> encouragement from the core team to develop these)

That's been mentioned before in a few different forms before.
Summarizing the test
strategy is actually easy:

- No changes without tests.  If there are reasons for it, discuss it with me or
  whoever is mentoring.

> Alpha/Beta releases should be based on the last release:

I don't understand this.  Pre-final releases are based on the current
stabilizing
branch, not on the last release.

> Pre-release activities:
> List of any major functionality implementation (e.g. Arch support)
> List of minor functionality improvements (e.g. changelog for rpm/yum based
> backends)
> List of bugfixes
> Develop a list of features useful for users, distributions and developers.
> Document everything. Focus on groups: User, Developer, Distro.
> Get ready to get the message out!
> Talk to people who package Smart for distros

Looks good!

> Release Day/Week activities:
> Update labix.org wiki
> update freshmeat record
> update launchpad
> update any other public area
> make announcement (email etc)

Looks good too!

> Create Release packages
> Create beta packages
> (create alpha package?)

Releasing the source code in packaged form should be done by the people
maintaining Smart for their preferred distribution.  We can help anything on
that area, but we can't take responsibility for it.


> As you can see the there are a few guiding principles here. The motivation
> for all of these is to develop/open communication to foster a community that
> shouts loudly for everyone to use Smart. This is key for any project. The
> way I see it there are three key groups of users for Smart that need to be
> communicated to in different ways: Users, Developers, Distros

Indeed.

> Now we could talk to each of these groups when they have a question and
> answer each question individually which is very time consuming and usually
> not very constructive or we can do documentation. Smart has an uphill battle
> because software installation is considered a key area for each distro to be
> in control of for itself as it is very important differentiator (ease of
> software installation and size of software pool).

Indeed.

> This is why packagekit became so successful so quickly. It did not tread on
> the toes of the distros. (...)

Hmm.. that doesn't make much sense, though.  The reason why PackageKit,
a software tool independently developed, became so successful (is it *so*
successful?) is because each distro want to be in control of that technology?

(...)
> website (http://www.packagekit.org/). To this day I haven't used packagekit
> but I know what it is all about to the point where I can describe virtually
> exactly how it works. I have been using smart since Fedora 6 and I can't say
> I understand exactly how it does what it does.

I agree that we lack documentation, but there are some ideas of different levels
being described here.  One thing is how to use a tool, and another things is
explaining how the tool does what it does.  The initial goal behind Smart was
doing transactions in ways that other tools couldn't do, and even though Smart
is several years old now, that's still true.  It *is* my fault that
the approach behind
it isn't described in a white paper, but this has nothing to do with
the adoption
of Smart.  Package management users don't really care about "how it does
what it does".  There must be high level documentation describing "how to
*use* what it does".

> Due to the perception that Smart is not actively developed and may even be a
> dead project we need to tackle this head on and vigorously. There needs to
> be Visible activity (yes capital V). This is not just the perception of a
> few people, this is a general perception, in fact it is why I wanted to get
> involved. I thought that Smart was dead/dying. That is why I suggested a
> stable release and a beta program, the betas give Smart Visibility without
> sacrificing stability of the core functionality (See what happened to KDE4.0
> because they did not put the word 'beta' on their pre-release? They were
> murdered by the press and by their users.).

As I said several times, Smart isn't dead or dying anytime soon.  There is an
important project using it as a backend (Landscape), and I'm directly involved
in it.

That said, the only way to make Smart be widely adopted is by having people
like you involved.  I honestly don't have the time or energy to be pushing the
tool up on every other distribution, even though I'd of course
appreciate if that
happened, and can help making it the case.

> I know that this project is close to your heart and that some of the things
> I say might hurt your feelings but I don't intend them to. However I also
> have strong feelings for the project as well and some things need to be said
> and talked about openly before it is too late. Each distro is heavily
> developing their package management and one day soon they will have a
> depsolver as capable as Smart's. The package system abstraction and
> depsolver are THE key technologies in Smart. The effort required to produce
> a depsolver like this is beyond most developers (otherwise they would have
> done it by now).

That's a common misconception.  The reason I developed Smart was precisely
because there weren't (and there aren't) any other tools able to do
what it does.
But that wasn't done with world domination intentions.  I'm a software
developer/architect that really enjoy these areas.  Smart wasn't built as a form
of getting funds.  If people take the ideas from Smart and put it in their own
tools in a better way, Smart is succeeding in its purpose too.

> Ok enough about my motivations. On to the future. Communication with the

In the future, please try to split messages by topic.  This is getting
really long,
and I can't see what the focus/goal is at this point anymore.

> user : Comprehensive User Documentation, wiki and bug tracker, fast positive
> response to issues (i see a lot of negative responses on irc). Communication

Please describe what you mean here.  "negative/positive responses" doesn't
have any meaning in that context.  I always try to provide helpful answers as
time permits.

> with developers: Developer Documentation, detailed description of how Smart
> works and where they can 'hook' into it. Fast progress from early code to
> beta to release. Smart project should shout loudly about their efforts (e.g.
> ensc's chroot guard patch is very cool, afb's stuff is great as well).
> Communication with distro's: support packaging efforts, Documentation about
> why Smart is useful for them. Quickly develop or encourage development of
> Smart to follow developments in the repository technology. Make sure it
> works with packagekit 100%. Bring distro patches into the main code base
> quickly. Develop strong relationships with people who have good connections
> with distros. These are the key communication issues.

Yes, communication is good, contribution is good too.  These tasks
must necessarily
involve time slices from multiple people.  I hope you help making that
a reality.

> Of course you might lose a little bit of control of your baby but that is
> the price that you might need to pay for success :) In fact you might have
> to stand back after a while and just guide the development (code review,
> ideas, mentoring, communicating etc) and let other people do the work. Well
> that might be far in the future.

Smart isn't my baby.  I'm part of multiple development teams with multiple
developers, and some of them were (co)authored by me.  I'm not a bottleneck
on Smart on purpose.  I'm a bottleneck because there are no other qualified
developers interested enough on it right now.  A proof of that is that you,
Mauricio, and others have commit access to the trunk right now.

> All of this might sound like a lot of work and time commitment and initially
> it will be. However the long term benefits will hopefully pay off especially
> in regards to documentation.

I'm hoping so too.

(...)
> Well I hope this isn't too much for one email :) Let me know your thoughts
> and lets get some stuff out the door!

It was. :-)  Even then, thanks for the time you've been putting on Smart and
on trying to move things forward.  It's exciting to see more people on board.

-- 
Gustavo Niemeyer
http://niemeyer.net