The end of "validated" map
Sebastien LELONG
While preparing the release, moving things from unvalidated to validared was a
real p.i.t.a. Mostly because some files needed to be removed, added, renamed,
etc... Kind of manual and conditional sync.
Anyway, I can remember someone saying "let's just forget about validated", and
I think this would be a nice idea. Releasing shouldn't be a pain, it should
be as easy as possible, mostly automated.
The orignal matrix purpose was to store the tested files. The matrix could
also be used to populate validated, and create a release. Now it seems too
complicated, mostly because of "nasty" dependencies, which I can understand.
Still, we have a problem: we can't release by simply "pushing the button".
validated, while interesting in the beginning, is a kind of duplicate SVN
branch, the one used for the beta. While there's a lot of work to maintain
this validated map, most people, including us, don't care about it and prefer
having a look at "unvalidated". This is also a duplication of information,
regarding the matrix.
Since the ETP (Eternal Testing Problem) is still there (well, it's eternal,
isn't), and since we decided to "test as much as possible, without spending
too much time, because building a user base is more important right now and
if it doesn't work then people will report it, at least some will give
feedback, and it's better spending some time advertizing jallib, amen",
validated doesn't make sense anymore.
But... not all files in unvalidated are elligible to a release. So we still
need to store, somewhere, which files are supposed to be included in the next
release. The matrix ! No, I'm joking :)
I suggest the following:
* add a "Revision: " field in JSG: it will store the SVN revision of the
file. Don't worry, it's automatic, each time you commit a file, it's updated
by SVN (see svn:keywords property for more)
* maintain a simple file, where we can find all the elligible files. Format:
a list of filename, full path.
A new file should be added ? Put it this file. A file needs to be removed ?
Remove it from the file. Replaced ? Change the appropriate line.
As the wiki page we first had, this file could have 2 sections: libraries and
samples. Samples are sufficient, though: if a sample is elligible to a
release, by "simply" analyzing include statements, I can select the correct
libraries to be included in the release, too. This is also a way to force us
to supply at least one sample with a library.
What about "Revision:" fields ? Well, extracting them, I can automatically
populate the matrix, if we decide to. This is also a convenient way to know
which is used, when reporting problems.
Finally, using this file (which "just" matrix at a higher level), I can also
write a script and a bot, to automatically create tarballs, and release once
in a week, or every nights, or after the repository have been quiet for 1
week, etc...
Cheers,
Seb
--
Sébastien LELONG
http://www.sirloon.net
http://sirbot.org
Joep Suijs
>
> * add a "Revision: " field in JSG: it will store the SVN revision of the
> file. Don't worry, it's automatic, each time you commit a file, it's updated
> by SVN (see svn:keywords property for more)
> * maintain a simple file, where we can find all the elligible files. Format:
> a list of filename, full path.
should be in the release?
> Remove it from the file. Replaced ? Change the appropriate line.
Changed? You don't mean each revision number, do you?
> As the wiki page we first had, this file could have 2 sections: libraries and
> samples. Samples are sufficient, though: if a sample is elligible to a
> release, by "simply" analyzing include statements, I can select the correct
> libraries to be included in the release, too. This is also a way to force us
> to supply at least one sample with a library.
Sounds okay. There are quite a few blink examples though. Won't a list
of files in sample/by device do?
> What about "Revision:" fields ? Well, extracting them, I can automatically
> populate the matrix, if we decide to. This is also a convenient way to know
> which is used, when reporting problems.
What is the added value? f we know the SVN revision of a release, we
can check this version if we want to investigate a problem which can't
be duplicated with the head revision...
I do like the general idea. I think we can estimate the risk of any
change pretty well and test accordingly. The risk of introducing a
large number of bugs in code that used to work before is limited.
So we can work on the content, release often and as little as possible
effort in the 'software process'.
Joep
Sebastien LELONG
> should be in the release?
Yes, only the sample files with their libs. For instance, now.jal is not a
lib, associated sample can't be released, so they're not elligible. Sounds
ok ?
>
> > Remove it from the file. Replaced ? Change the appropriate line.
>
> Changed? You don't mean each revision number, do you?
No !... Changed == renamed
>
> > As the wiki page we first had, this file could have 2 sections: libraries
> > and samples. Samples are sufficient, though: if a sample is elligible to
> > a release, by "simply" analyzing include statements, I can select the
> > correct libraries to be included in the release, too. This is also a way
> > to force us to supply at least one sample with a library.
>
> Sounds okay. There are quite a few blink examples though. Won't a list
> of files in sample/by device do?
Sorry, can't understand what you mean about "few blink examples"
> What is the added value? f we know the SVN revision of a release, we
> can check this version if we want to investigate a problem which can't
> be duplicated with the head revision...
That's right, but if people takes file from the repos, through the web
interface, there's no way to know which one they take. At least, without
doing archeologic work... This is also a way to know the revision, without
having to use svn executable (or a svn library, like in my jallib.py script).
> I do like the general idea. I think we can estimate the risk of any
> change pretty well and test accordingly. The risk of introducing a
> large number of bugs in code that used to work before is limited.
> So we can work on the content, release often and as little as possible
> effort in the 'software process'.
Yes, this is a "worked before so should still work" approach. Sounds
appropriate since we're all very serious :)
Joep Suijs
>
>
> Sorry, can't understand what you mean about "few blink examples"
That's why I wonder if it would be possible to use all the files in
sample/by device....
Joep