I am going to propose a 2.8 release schedule. Feel free to comment on
dates and procedure below:
1) April 1st, 2014 --- From https://github.com/ossec/ossec-hids, fork
the repository to ossec-hids-2.8.
2) Start Alpha testing phase for 2 weeks. Only bug fixes will be
accepted to the ossec-hids-2.8 fork.
3) April 15th, 2014 -- Start Beta testing phase for 4 weeks. Any further
fixes SHALL be accompanied by a reproducible test case.
4) May 15th, 2014 --- Release 2.8
5) Immediately following OSSEC 2.8 release, start a rules/decoders only
repository for the purpose of more frequent updates.
This sounds reasonable enough. Is there a master changelog to look at
the current state of 2.8? Or are the git commit logs the only thing
available?
I've started the release notes, but I'm sure it's incomplete at this point.
If anyone notices anything I've missed, add it and submit a pull
request. Or heck, even email me off list and I'll take care of it. :)
And if anyone wants a different name than their github handle listed,
please let me know off list.
** I wrote some long emails about this but used my iphone and they did not
send for some reason. Here is are some suggestions of mine **
This is great let me know what I can do and if you identify any issues
during the release. I reviewed almost all the code so I can help find
the fix or the person that could help with the fixes.
I can also help to setup travis-ci generation of tarballs, rpms, etc
and have it upload betas automaticly.
# Use the Pull Requests Not the Commits ####################
To create the release notes I would use the Pull Requests themselves.
They reflect a complete idea that is merged into master. Their are also
all kinds of tools to help out with this. I started writing one in
python but I will let someone else take over. Here is the code:
https://gist.github.com/jrossi/a7934a436fef3811f97e
This has two files the python code to make the markdown release notes
from github pull requests. It's far from complete but should make
release note generation easy. If we want to control what goes into the
release notes. Just use pull request tags or milestones or what ever.
# Code management of bug fixes #############################
During alpha, beta, and RC I propose that we make sure that all fixes go
into master then are cherry picked from master to the release repo. This
will make sure that all changes are always in master and make sure that
the repos don't become divergent.
hub is the tool that make this sooooo simple hub.github.com you can
do this with git, but hub just makes cherry picking with github too
easy not to use. This is how I got everything pulled into github from
bitbucket so I know it works.
--
---
You received this message because you are subscribed to the Google Groups "ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
